Access Control Policy authorization mechanism, version 0.9

[acoburn]

This is a proposal to include the Access Control Policy (ACP) specification in the Solid Project technical reports.

ACP defines an authorization data model in RDF, consistent with Solid and Linked Data principles. This specification has been incubated in the Solid Authorization panel since 2020. It has now reached a level of maturity such that we wish to propose it for publication in the Solid technical reports.

This proposal uses the version number 0.9.0, which is consistent with the draft recommendations in #407. If a different version numbering is preferred, we can adjust this document.

Please note the non-normative visual illustration of the ACP data model contains an error that needs to be fixed before merging this PR: it includes the acp:access predicate that has been since removed. This will need to be fixed before merging this submission.

[RubenVerborgh]

LGTM, good to have this in.

[matthieubosquet]

I pushed the fully reviewed version 0.9 dated 2022-05-18.

It is in sync with the version hosted as an editor's draft on the authorization panel.

[justinwb]

Thank you @acoburn and @matthieubosquet for this comprehensive submission. This proposal is composed extremely well. I find the normative text clear and intuitive, and the examples (and pseudocode) informative and easy to interpret. It provides good coverage of the Use Cases and Requirements specified by the authorization panel, and the ability to expand that coverage through matcher extension. I have proposed one such (non-blocking) extension that I would like to explore in solid/authorization-panel#306, and I'm sure there will be others, but those can and should happen in separate, parallel threads. Excellent work!! ✅

[kjetilk]

I have read the proposal in detail, and I'll concur, it is a well written description, well supported with appropriate examples that makes the ideas easy to follow.

If there is something in the text that don't understand, it is in Section 7.2 and the use of a Link header, it seems to cover many of the same uses as the WAC-Allow header, doesn't it?

My concern over ACP has been twofold, where the most important concern is the overall impact on the ecosystem, both 1) the relationship to WAC and what it means for the ecosystem to have two competing proposals rather than one that could have several conformance levels and 2) whether is reasonable to have a rather complex system as this one, given that too much power could confuse end-users to the extent that they will fail to create access controls that serves their interest. I would rather have liked to have had these discussions first rather than discussing this in purely technical terms.

I must admit that I am also concerned with the performance impact on Solid, as this seems to require parsing three small graphs and evaluating some somewhat elaborate algorithms, as well as sending a few HTTP requests back and forth before the end user sees first byte. I'm sure this will have to be optimized for practical use.

Nevertheless, I recognize that these discussions can be had after we have a TR to discuss, so I'm alright with publishing this document.

[RubenVerborgh]

the use of a Link header, it seems to cover many of the same uses as the WAC-Allow header, doesn't it?

Note that WAC-Allow was intended as a temporary measure. I wonder whether ACP introduces a more sustainable mechanism (and whether that mechanism can/should be extracted out).

[acoburn]

If there is something in the text that don't understand, it is in Section 7.2 and the use of a Link header, it seems to cover many of the same uses as the WAC-Allow header, doesn't it?

The use of link headers in section 7.2 refer to response headers from an OPTIONS request to an ACR resource.

WAC-Allow, on the other hand, is a response header from a GET/HEAD request to a Solid resource, per the Solid Protocol.

These two headers do very different things: the first indicates to ACP-aware clients what capabilities/features are available server-wide. The second (WAC-Allow) indicates to Solid clients what permissions are available on the resource in question.

These two mechanisms can work together fine.

I wonder whether ACP introduces a more sustainable mechanism (and whether that mechanism can/should be extracted out).

An early version of ACP had its own Link header approach in place of WAC-Allow, but it was decided to align with WAC on this point for better ecosystem interoperability. This proposal does not attempt to change anything regarding how WAC-Allow works. But to @RubenVerborgh's point, yes, a Link header approach has been shown to work.

This proposal does not mention WAC-Allow because that is defined and required through an orthogonal specification, and it is generally best to keep specs independent. I would be supportive of re-evaluating the use of WAC-Allow, but I would really prefer that it be done in a separate issue.

[RubenVerborgh]

Ack; I'd be interested to discuss the rationale for OPTIONS, but we can do that in a separate issue.

[justinwb]

Merging given that we've got the requisite approvals and no objections raised. Thanks @acoburn, @matthieubosquet, the authorization panel, and all contributors!