Add Solid Application Interoperability (SAI) as a mechanism for authorising access to protected resources

[michielbdejong]

The Solid CG is an incubation space where multiple experiments happen in parallel, and the Solid Protocol is a reflection of that.

For instance, there are many different notification mechanisms a server may or may not offer, and the protocol mentions two competing ACL systems (WAC and ACP), for the sole reason that experimentation with both happens within our CG.

Solid Application Interoperability (SAI) has also been an active topic of experimentation in our CG over the past years, but thus far, the Solid Protocol spec has not reflected that yet. I think the time has come to change that.

We need to be a bit careful about the layering here, and there are some connected differences at different layers, but at the heart of it, SAI Data Grants can replace WAC or ACP in the role of authorising access to protected resources.

SAI offers many additional mechanisms for data discovery (replacing type indexes), shape validation and automatic organisation of documents into containers on the pod (replacing most of what we use from LDP), but as a first step, let's start by allowing pods to offer SAI Data Grants as an alternative for WAC and ACP.

When using SAI, WAC, or ACP, there are two interactions featuring 7 components involved:

• The Resource Server (RS)
• The Policy Registry (PR)
• The Resource Owner IDP (RO-IDP)
• The Resource Owner Client (RO-Client)
• The Authorization server (AS)
• The Requesting Party IDP (RqP-IDP)
• The Requesting Party Client (RqP-Client)

Policy Setting

The RO-IDP enables the RO-Client to prove it represents the Resource Owner, to edit the rules in the policy registry. Note that for WAC and ACP the Policy Registry MAY be integrated into the Resource Server (with actual .acl files), but in this discussion it's clearer to treat the Policy Registry as separate from the Resource Server.

I think for this policy setting step we should allow not only WAC and ACP, but also SAI data grants, ODRL-based policy registries like in this recent experiment, as well as Inrupt Access Grants, the Policy Registry used by Digita Distri, and maybe even others too, so that this specification reflects more accurately how existing Solid servers and their Policy Registries work in practice.

Resource Access

The RqP-IDP enables the RqP-Client to prove it represents the RqP, to access the target resource. This interaction is the same, regardless of which mechanism was used during policy setting, as long as the RS/AS is able to interpret and apply the policy correctly.

What these mechanisms all still seem to have in common, is that claims gathering between the UMA AS and the RqP-Client seems to be restricted to "prove that you own, or act on behalf of the owner of, a certain WebID", hence the explicit role for the IDP.

Experiments with more flexible types of claims using verifiable credentials also exist within the CG, but in this proposal I'm not proposing we move away from the strict role of WebID's and IDP's.

[elf-pavlik]

The Policy Registry (PR)

I think we should also have here the distinction between:

• The Resource Owner Policy Registry (RO-PR)
• The Requesting Party Policy Registry (RqP-PR)

As well as, keep in mind that both RS and AS are associated with RO, not the RqP.

The RqP-IDP enables the RqP-Client to prove it represents the RqP, to access the target resource.

The key is in this detail, and I find it very helpful to think about it in terms of delegation:

• RO delegates some access to RqP - it gets reflected in RO-PR
• RqP delegates some of that received access further to RqP-Client - it gets reflected in RqP-PR

The RS + AS must decide whether RqP-Client requests should be allowed. For that, they need to consider the entire delegation chain; in this case, both delegations RO -> RqP and RqP -> RqP-Client

UMA claims pushing mechanism is one of the few ways for the RqP-Client to present the RqP -> RqP-Client delegation to the AS.

---

While drafting and implementing SAI, we have found a few additional advantages.

• RqP can set policies that delegate their access to data from an unbound number of agents, e.g. all the Calendars that RqP can access while only delegating read-only access; once another person shares the calendar with RqP, the RqP-Client will automatically get access to it, and detect it see demo
• Artifacts derived directly from the access policy make a natural entry point for discovery. Since RqP-Client can only access (even further know of existence) data it was authorized to access, projecting access matrix on the agent results in easy to "follow your nose" starting point. This approach can be easily composed over many ROs, each with multiple RSs
• This approach seems promising for scaling to longer delegation chains; while we first focused on RO -> RqP -> RqP-Client, in some scenarios, additional Intermediate Parties can be added: RO -> IP1 >>> IPn -> RqP -> RqP-Client

[elf-pavlik]

We need to be a bit careful about the layering here, and there are some connected differences at different layers, but at the heart of it, SAI Data Grants can replace WAC or ACP in the role of authorising access to protected resources.

I see it as more nuanced. The main difference between the data model used in WAC / ACP and SAI Data Grants is the direction used to project the access matrix, on resources vs on agents. Still, it should be possible that the underlying access matrix will be the same across all three approaches. Since SAI aims at smooth interactions across the Social Graph and focuses on access delegation, projecting the access matrix on the agent has many advantages. At the same time, the Authorization Server could project the access matrix on resources only in the context of AS <-> RS interop. This has the potential to improve performance, which can only be verified by implementing both approaches and running benchmarks.

In other words, I see potential for using SAI Data Grants and ACP (or 'WAC+') together. The Authorization Server would recreate the access matrix using all applicable Data Grants and project it on the resources for the RS. The important part here is that the AS would be the exclusive ACP client (no other client would have acl:Control permission) for the RS.

Preferably, we will have parallel implementation efforts, allowing us to verify the assumptions we make about those approaches. Meanwhile, we can still focus on a common set of Use Cases and Requirements, where we can initially evaluate all the proposals based on snippets and sequence diagrams (see prior attempt) and later provide working demos based on those snippets and sequences. This would also allow for running benchmarks and answering questions about performance.

Last but not least, all the approaches seem to agree that we need comment set of access modes / storage operations

• https://github.com/solid/authorization-panel/issues/194
• https://github.com/solid/authorization-panel/issues/253

No matter how we project the access matrix, we start with the same access modes in its cells.