elf-pavlik
commented
4 years ago Thank you for this write up @jaxoncreed I find you diagram really good as starting point. I would see few possible improvements:
- Change it from Implicit Flow to Access Code Grant + PKCE
- Add refresh_tokens or Client Credentials Grant so that any client can easily get fresh access_tokens for each RS
- Allow passing proposed capability acls by reference (eg. Capability IRI) in the access_token, since token gets sent with every request we should only include bare necessary minimum in the token itself.
I also wouldn't yet commit to having OP and AS as one party. I think we should still evaluate possibility of having them decoupled and independently discoverable from User's WebID Profile. Still for now I see no problem to think of it as User's OP+AS.
jaxoncreed
zenomt
I wanted to flesh out a few thoughts around capabilities/identity-based access control that we've been discussing.
The concept
Conceptually, we would be using both capabilities based and identity-based access control.
Identity-based access control is the kind that we're all used to in Solid. A user has an identity and the resource owner can grant access to various identities or identity groups.
Capabilities based access control would be employed to allow a user using an app to control what that app can access across all possible resource servers. This is different from the way we currently control apps which is dictated by the resource owner, not the user using the app. Thus, it is the responsibility of the identity server to keep track of the capabilities a user has granted an app.
Modifications to acls
It would be fantastic to have as much overlap as possible between the rule system for both the identity-based access control. So, I propose using the .acl system for both.
Under the capabilities based access control model, all acls would have the app's WebID as the agent.
There would also be additions to ACL capabilities that would allow them to function holistically across the Solidverse. Acls would include shape and tag systems that wouldn't constrain it to talking about a specific resource. They could also depend less on the container hierarchy by including a
ACL:parentpredicate that would allow an ACL file to point to its parent acl that could be located anywhere.How it works
Below is a sequence diagram detailing how capabilities and identity can work together via the Resource Server Enforcement technique (discussed below). This is not the only way it could work, but it serves as an example:
Launcher App vs Resource Server Enforcement vs User Proxy
There are three competing ideas on what entity would enforce the capabilities based rules.
Launcher App
Under the Launcher App technique, all requests from a solid-compatible application would need to go through a special launcher app to get to a Pod. Instead of Solid apps authenticating with a server, they authenticate with the launcher app and the launcher app has god access to represent a user's identity throughout the Solidverse.
The app will communicate the kind of data to which it desires access to the launcher app, and when performing a request, the launcher app will check to ensure that the request is only for data to which it has been granted.
Alternatively, instead of ensuring that the request is valid before making it, it could filter out any data from a result to which the app does not have access before returning it to the user.
Pros:
Cons:
Resource Server Enforcement
Under the resource server enforcement technique, the resource server is responsible for enforcing the capabilities.
When a resource server receives a request it would first authorize a request based on its local identity-based access control rules, then authorize a request based on the capabilities-based access control rules it received in the token. Only if both authorizations pass will it return the requested data.
In order to avoid data leakage by sharing capabilities that might not concern a specific resource server, the identity provider would issue a new token for each resource server with only the rules that apply to it.
Pros:
Cons:
User Proxy
Under the user proxy technique, all requests for a solid app would be routed through the user's identity provider which acts as a proxy to the Solidverse.
Similar to the launcher app technique, each solid app would register its rules with the IDP proxy. The proxy itself has god access to the user's identity and would reject or filter any requests from the app that don't fall in line with its predefined rules.
Pros:
Cons: