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.

[damooo]

The case of 6. Delegate-able Attenuated Access Control for Apps is natural case, when one want to use particular apps to access resources that they have access to. And it is most deployed case of oauth systems for most production apis like google-(drive/sheets/...), twitter, fb apps. The case allows to use what ever app one want to use, and limit their capabilities to certain 'scopes'. Say, if one want to just analyse a google sheet, they authorizes an app with gsheets:read scope. Then the access token can only be used for that purpose by app. This type of functionality is the one most users are accustomed to.

But in above cases, the resource servers are tied to particular client-authorization-endpoint, and both shares meaning of scopes.

The solution can be to specify certain syntax for attenuated primitive scopes, Which solid storages and oauth-authorization-endpints share.

Say, An access token bound to a scope string of https://example.com/pod1/l1/l2/::read may mean "allow an app to access resources in hierarchy https://example.com/pod1/l1/l2/ on behalf of me within readonly scope". Thus at the time of authorizing an app, authorization-endpoint-server can show scope description, and optionally allow to edit scope.

[damooo]

It may be clear and fruitful to separate the authorization issue into two orthogonal axes.

1. Authorization to access (to any agent)
2. Authorization to act-on-behalf-of / delegation (to third party oauth-clients)

And most of cases discussed will be permutations and combinations along these two axes. And this distinction is natural.

1. Authorization for access (to any agent)

This only deals with which web-ids have access to which operations on which resources. WAC, and ACP, etc are mechanisms to specify those policies. Typically resource-owner manually sets those policies on resources they owns.

2. Authorization for delegation (to oauth-clients)

Without delegation, In normal case, agents should be able to directly access resources they have access to without need of any client. This is possible by mechanism of Personal access tokens, like supported by github/gitlab/vimeo/etc. Those access tokens doesn't bound to any third party client. Solid idp oauth provider supporting this case will be useful, for quick scripting.

But when one want to access resources through custom clients, then this mechanism of authorizing-to-act-on-behalf-of a.k.a delegation comes into play. In this case an access-token represents the complete delegation contract between user, ouath-provider, third-party-app with all it's nuances of delegation-scope limiting, contract-validity-periiod, etc. . And resource servers have to acknowledge the contract.

As OAuth providers and pod-servers have no prior mutual knowledge, the scope strings cannot be constant strings, but string in solid-specified-syntax, to limit to certain resources, to certain operations. This is natural, allowed from oauth spec.

[elf-pavlik]

@damooo have you taken a look at https://solid.github.io/data-interoperability-panel/specification/#delegated-data-grant

We also have an open issue for generalized delegation https://github.com/solid/data-interoperability-panel/issues/222