Thoughts on capabilities/identity based access control

[jaxoncreed]

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:parent predicate 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:

• Only depends on the client
• It might be more customizable for users
• No concern over resource servers knowing too much about the granted capabilities
• No need to involve the identity provider in creating rules

Cons:

• Does not work for offline/bot use cases
• Requires a launcher app implementation for every possible platform

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:

• Implementable for any kind of client
• Can resolve shape restrictions locally

Cons:

• Requires complicated rule parsing to ensure data isn't leaked to unwanted resource servers
• Requires more round trips to the IDP
• There is no technical way to make a resource server enforce these rules

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:

• Works when a user isn't present and could be deployed on local networks
• No concern over resource servers knowing too much about the granted capabilities

Cons:

• Might be too overwhelming for the IDP to serve as a proxy

[elf-pavlik]

Thank you for this write up @jaxoncreed I find you diagram really good as starting point. I would see few possible improvements:

1. Change it from Implicit Flow to Access Code Grant + PKCE
2. Add refresh_tokens or Client Credentials Grant so that any client can easily get fresh access_tokens for each RS
3. 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]

I also wouldn't yet commit to having OP and AS as one party.

Yeah I think it makes sense to split them up for the user proxy use case.

[zenomt]

in the diagram, AUTHORIZATION step 11 requires that Alice's OP can dereference the app's WebID, which will eliminate the class of apps that are local, or where there's a NAT/firewall between the app's origin and the OP, or where there's different trusted Certificate Authority lists between the user's browser and the OP.

at step 13 "Gets Alice's Consent", would Alice be consenting to whatever ACL the app had proposed from step 9? how complex do you imagine an app's capability ACL to be? do you imagine apps requesting different access for different resource origins, access to different shapes and tags, etc? presumably during consent Alice would be able to accept, reject, or limit individual access items requested by the app.

i think this proposal represents a significant expansion of scope and complexity for an OP, including what must happen during the consent phase as well as for obtaining new tokens for each RS to be accessed. it ties access control tightly to OIDC (today OIDC just provides identity), which could complicate replacing OIDC as the authentication/identity mechanism in the future. as i mentioned during one of our meetings, one thing i always ask myself (to make sure i've factored the problem appropriately) is "how would this work with WebID-TLS?"

---

@elf-pavlik

3. Allow passing proposed capability acls by reference (eg. Capability IRI) in the access_token ...

note that this is substantially the same mechanism i proposed in #48, but with the URI authenticated differently.

... since token gets sent with every request we should only include bare necessary minimum in the token itself.

the every-request overhead of all kinds of large information (like access capabilities) being explicitly encoded in a bearer-type access token can potentially be eliminated if the resource server (or its designated authorization server) issues its own access tokens. the RS issuing its own access token is also a good opportunity for expensive parsing, processing, validation, etc. of identity, capability ACLs, etc. to be done once and then represented in an internally-optimal way for that RS to interpret per-request.

[elf-pavlik]

at step 13 "Gets Alice's Consent", would Alice be consenting to whatever ACL the app had proposed from step 9? how complex do you imagine an app's capability ACL to be?

In solid/data-interoperability-panel#25 (comment) I suggest possibility where user's rely on trusted repository of shapes which apps would reference.

"how would this work with WebID-TLS?"

As we discussed during one of recent calls, https://github.com/solid/authentication-panel/blob/master/meetings/2019-11-18.md#authenticating-users-27 (last bullet point) WebID-TLS never tried to enable user having possibility to delegate specific access to a client, any client always had full access. wac:origin also didn't really address it since it would only give some options to users with wac:control access to the resource.

the RS issuing its own access token is also a good opportunity for expensive parsing, processing, validation, etc. of identity, capability ACLs, etc. to be done once and then represented in an internally-optimal way for that RS to interpret per-request.

Makes sense, I still need to take another look at https://oauth.xyz/ and how it uses construct of transaction.

I think passing authorization in a token by reference may suffice since RS can rely on caching, I think having tokens from user associated OP+AS and tokens from RS (or another RS associated AS) may add unnecessary complexity of refreshing all of them etc.