Specification: Attenuated app authorization

[michielbdejong]

See https://github.com/solid/specification/issues/38#issuecomment-533620828

[michielbdejong]

@Mitzi-Laszlo can you add this to https://github.com/solid/specification/milestone/1?

[michielbdejong]

We also discussed this in the community call just now and there seemed to be unanimous consensus that this is something we want and need to be in scope.

[michielbdejong]

Copying over from https://github.com/solid/specification/issues/38#issuecomment-533580324:

basically it's https://forum.solidproject.org/t/read-only-or-sub-folder-oidc-scopes/767 and https://github.com/solid/authorization-and-access-control-panel - in a sentence, and at the minimal level:

If Alice gives Bob read-access to (a part of) her pod, then how can Bob give a document-viewer app "attenuated" access to only one resource on there, but not the others.
So the goal is a situation where Alice has control-access to her entire pod, Bob has read-access to some part of it, and the document-viewer app has read-access to only one single document, so a strict subset of the access that Bob himself has.

In theory this is already possible: Bob emails Alice the origin of the app and which doc it should be allowed to open, and Alice goes and edits the ACL with an acl:origin entry, then emails Bob back. But in practice we (obviously) want a better system for this.

[RubenVerborgh]

It's up to the editors of the spec to assign issues to milestones. My concern with assigning it to https://github.com/solid/specification/milestone/1 is that there are too many dependencies that need to be worked out first. I don't see how we will get there on time.

Let's map out the dependencies and make explicit issues for them; that will bring clarity.

[dmitrizagidulin]

We'd need to spec several pre-requisites to make this happen. (And I'm happy to break these out into individual issues, where appropriate, if people agree on the general list.) Most, if not all, of this spec work will probably need to happen in the Authorization and Access Control Panel.

1. App identification/authentication. If we're going to restrict access to applications and services, we need a way to identify them (and have them authenticate to those identifiers).
   
   
   
   1. services: Some software (termed _services_ for the purpose of this comment) will be able to have its own WebIDs and WebID Profiles. These are often server-side apps (although some native apps also have access to secure storage for the secrets (passwords/certificates/keys) required to support a WebID).
   
   
   2. apps: Some software (termed _apps_ for this comment) will not be able to have its own WebIDs in the classical sense, for both practical and structural reasons. For example, in-browser Javascript apps do not have access to secure storage to keep secrets in (IndexDB does not qualify). More importantly, these apps don't run unattended, they only interact with Solid pods when "piloted" by a user that _does_ have a WebID. Nevertheless, we still need ways to _identify_ these apps (as distinct entity from their users), even if we can't use app WebIDs.
   
   
   3. app WebIDs vs other app identifiers: Services can have their own WebIDs, so that's the easy case - those interact with our ACL system in the usual fashion. Apps, on the other hand, need some way to identify them. Currently we use the HTTP Origin header to identify some apps (in-browser JS apps only). There has also been discussions about using other identifiers (such as client_ids for some native apps, and redirect_uris for some in-browser apps, etc).
   
   
   4. levels of app identity: Speaking of identifying apps, we need to be careful and specify what exactly we're identifying - the app "source", a particular installation/deployment of an app, or a particular ephemeral in-browser JS app session. See https://github.com/solid/authorization-and-access-control-panel/issues/30#issuecomment-531984949 for explanation.
   
   
2. Per-app Access Control. Once we have mechanisms to identify apps, how does this interact with our WAC mechanism?
   
   
   
   • ACLs for services and other WebIDs - this part is easy, same as ACLs for users.
   
   
   • Which WAC terms to use to restrict access for a _combination_ of User (WebID) and App (other identifier)? We currently have acl:origin that's used for this purpose. Will that predicate be sufficient, or do we need more?
   
   
   • We need to solve the UI/UX issues of "How do we let users restrict access for an individual app?". They _could_ edit each individual .acl involved and insert the app's acl:origin (or whatever other predicate we end up using). This is a UX nightmare though, which is why a global white list of Trusted Apps has been developed. Can we develop other mechanisms, in addition to a global trusted list or individual .acl statements? Such as:
   
   
   • App permissions/scopes. We need to develop a mechanism for apps to be able to _request_ permissions from a user's pod (request access to individual containers, resources, or even _shapes_ or RDF types). And where would these granted permissions live? In individual relevant .acls, or somewhere like an App Registry?
   
   
3. Restricting your _own_ apps vs restricting other people's apps.
   
   
   
   • This is actually a crucial question point that we as a community need to decide. The benefit of a user restricting _their own_ app's access is clear -- without it, the App has the same access as the user, and so typically has full access to their storage space, and is vulnerable to the Confused Deputy problem. On the other hand, when sharing a resource with other users, restricting what app's _they'll_ be able to use, is a lot more problematic. First, it's awkward socially and informationally. More importantly, it's not possible to actually _enforce_. You can authenticate your own WebID, the WebIDs of other users, you can authenticate the identity of _your own apps that you're using_, but - and this is key - you cannot authenticate the identity of apps other people are using. (We can get into why this is in the individual issue's discussion.) And lastly, the benefits of restricting other people's apps (even if it was possible) do not make sense, since when sharing resources with other users, you typically don't give them full access to your storage space, and so the Confused Deputy problem is a lot more limited.
   
   
4. Delegate-able Access Control
   
   
   
   • A separate but related question is, how do you _delegate_ access to other agents (WebIDs)? This is different from just sharing resources with those WebIDs. This is where mechanisms such as WebID Delegation and Authorization Capabilities come into play.
   
   
5. Delegate-able Attenuated Access Control
   
   
   
   • As a more advanced technique of delegating access control, how do you restrict the _kind_ of sub-delegation that a secretary can perform? If you delegate access to Alice, how do you make sure that Alice can only delegate Read-only access to _her_ Secretary?
   
   
6. Delegate-able Attenuated Access Control for Apps
   
   
   
   • Lastly, if we address all of the previous items, we can address this feature.
   
   
   • _If_ we decide, for item 3, that you can restrict not only your own apps, but other people's as well, _only then_ do we need to create a mechanism for delegating attenuated access control for other people's apps (but not services -- delegating to services works the same as delegating access to other people, which is item 5.)
   
   

Hopefully this can help shape the discussion of this spec feature request.

[dmitrizagidulin]

Just to be clear, though, that while I agree with @RubenVerborgh that we may not have time to address all dependencies 1-6, in time for the a 1.0 spec,

I personally think that it's crucial that we address items 1 through 3 for the 1.0 spec.

[michielbdejong]

Great! I'll leave this task in your (plural) capable hands. :)

[csarven]

I agree that this issue wouldn't quite make it into milestone 1 (~FPWD). I've bumped it down for later. If all dependencies in the earlier milestones are addressed, we can do it - which may end up getting done for ~PR/REC or major release ("1.0") any way.

[csarven]

@dmitrizagidulin

I personally think that it's crucial that we address items 1 through 3 for the 1.0 spec.

If any issue pertaining to items 1-3 are not logged, can you mind adding them?

[michielbdejong]

Also discussed this issue with @jaxoncreed just now. Our conclusion is that regardless of where the dialog GUI lives where Bob specifies his choice of attenuation, there are basically two places where the attenuation decision can go: on Bob's profile/pod, or inside the bearer token.

Another interesting question is: Does Bob trust Alice's storage server to properly apply Bob's attenuation decision? If not, then I think the only other option would be if Bob makes the app go through a proxy that he controls.

[jaxoncreed]

Some more discussion on this https://github.com/solid/authorization-and-access-control-panel/issues/43

[michielbdejong]

So https://github.com/solid/authorization-and-access-control-panel/blob/master/privilege-request-protocol.md doesn't solve the Alice+Bob scenarios I described in this issue, because it just sort of assumes that Bob is somehow able to tell Alice's server what his attenuation decision is, and we don't currently have a way to do that, other than sending an email to Alice and she editing the ACL doc at the RDF level.

[elf-pavlik]

If not, then I think the only other option would be if Bob makes the app go through a proxy that he controls.

I've created issue for something like that a month ago: https://github.com/solid/authorization-and-access-control-panel/issues/35

Another interesting question is: Does Bob trust Alice's storage server to properly apply Bob's attenuation decision?

Why in that case Bob would trust Alice's storage server to even properly apply user related WAC rules?

[michielbdejong]

Why in that case Bob would trust Alice's storage server to even properly apply user related WAC rules?

Good question, and I don't know the answer! :)

I did see that this is now planned for 19 June 2020. Later than I had hoped, but glad to see it's on your roadmap!

[jaxoncreed]

Another interesting question is: Does Bob trust Alice's storage server to properly apply Bob's attenuation decision?

I think that Bob trusting Alice's storage server to enforce the constraints he's applied on his token is fine.

• Alice has no motivation to leak more than Bob says because that would be exposing information Alice already has. If Alice wanted to be malicious and share the data with an application against Bob's will, she could just do that via a backchannel
• If Alice shares less information than Bob allows on the access token, that should be allowed too. There are many use cases where the resource server own might want to restrict the applications that can access that data, even if Bob would have access to the data himself. This paradigm should not be common, but it should be allowed.

[zenomt]

... there are basically two places where the attenuation decision can go: on Bob's profile/pod, or inside the bearer token.

since the decision of whether to grant access to any request ultimately belongs to, and is enforced by, Alice's server, such an "attenuation decision" could also be stored in Alice's server.

I think that Bob trusting Alice's storage server to enforce the constraints he's applied on his token is fine.

expecting Alice's (or anyone else's) storage server to enforce Bob's constraint preferences is, in the best case, "overly optimistic". Bob can hope unassociated servers he accesses will honor his preferences, but he should only expect it from servers he controls or otherwise knowingly trusts to do so.