Endpoint to see with whom a resource has already been shared

[srosset81]

When we give others the right to share a resource (through delegation), it's very annoying if they can't know with whom the resource has already been shared. They may want to select all their contacts, thinking none of them can see the resource... while in reality all their contacts can already see the resource. The AA will mostly likely ignore these Delegated Data Grants, but it's still a very bad user experience.

So it would be very useful if there could be some endpoint that shares the authorizations that have already been granted. And maybe the resource owner could give it only to people who received the right to share (delegation).

In WAC, there has been a proposal to create a ControlRead ACL mode: the right to see the permissions, but not to change them. We would be something similar for SAI grants.

This cannot be something specific to the Authorization Agent (that would be implementation-specific) because, if Bob receive the right to share a resource from Alice, it is Alice's AuthorizationAgent that can tell to Bob with whom this resource has already been shared. So the endpoint needs to be published somewhere.

In ActivityPods, we currently use an ActivityStreams collection, linked from every shared resources, that simply list the WebID of users. This collection is private by default, but users who receive the right to share a resource also get the right to read that collection. It works, but we would prefer to have something that better integrate into SAI.

[srosset81]

We could also imagine giving some kind of ACL permissions on the authorizations:

• acl:Read: the agent can see all authorizations granted to this resources
• acl:Append: the agent can add new authorizations to the resource
• acl:Write: the agent can add and remove authorizations to the resource

These permissions could also be given to applications. This would allow them to see and grant permissions without needing to redirect the user to the authorization agent, or as a side effect of other actions (the ActivityPods framework allow apps to do that, see this page)

[TallTed]

Implementation of this "feature" might also lead to or be considered a privacy vulnerability, as the owner of the resource may not want all those with whom it's been shared to be able to see the list of others. Various other exposures seem likely to me. This leads to a need for other permission grants and/or restrictions.

In simple terms, I think it is not a simple decision whether to implement as a feature, nor whether to make available if implemented.

[elf-pavlik]

When we give others the right to share a resource (through delegation), it's very annoying if they can't know with whom the resource has already been shared.

With principle of the least privilege (disclosure). This is the default case which has to be handled gracefully even if in some cases an additional feature (as proposed) is used to escalate someone's privilege and in consequence disclosure.

They may want to select all their contacts, thinking none of them can see the resource... while in reality all their contacts can already see the resource. The AA will mostly likely ignore these Delegated Data Grants, but it's still a very bad user experience.

Since agents can act in an autonomous manner. We can have following situation

1. ACME grants access to resource X to Alice and Bob, allowing both to delegate
2. Alice delegates to Charlie
3. Bob delegates to Charlie
4. Alice revokes her delegation to Charlie

Given above Charlie still has access via delegation from Bob. If Bob decided not to delegate to Charlie, based on knowledge that Alice has already delegated. Charlie would loose access after Alice revoked it even though Bob still intended Charlie to have access.

There can be more variants in this relatively simple scenario. ACME revokes Alice's access and invalidates all access delegated by Alice. Again if Bob wants Charlie to have access, he can't rely on someone else delegating it.

I'm not saying that we can't or shouldn't make it possible to know who has access, based on what delegation chain. I'm only saying that while we are considering it, we need to keep in mind privacy implications, added complexity of controlling access to information about access and delegation chains, and the dynamics in open ecosystem where autonomous agents collaborate as the scenario above.

[srosset81]

Thanks for pointing out this case.

In the way we currently do it with ActivityPods, we don't have this situation because, when Alice shares ACME's resource X to Craig, she will ask ACME to add a permission to Craig. So ACME's Pod is the single source of truth regarding with whom the resource has been shared.

If we used some kind of ACL permissions on authorizations as suggested here, we could imagine that users are given only the right to add new authorizations, but not revoke them (ie. acl:Append).

But I don't know if that would make sense with delegations... They are a completely different concept. 🤔