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

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.

Start with the issue's Policy Setting and Resource Access sections, then compare how WAC and ACP are represented in the Solid Protocol specification. Done means the specification clearly incorporates SAI Data Grants as an alternative policy mechanism, including the relevant layering, components, and interactions.