solid / web-access-control-spec

Web Access Control (WAC)
https://solid.github.io/web-access-control-spec/
MIT License
121 stars 25 forks source link

Is N3 patch allowed for Append access? #104

Closed Otto-AA closed 5 months ago

Otto-AA commented 2 years ago

For a project, we're currently trying to use an Append-only functionality. In the scenario, everyone has Append access to a file, but no read and write access. For us the question arises, how we should make the PATCH request.

From my current understanding, there seem to be 2 standards for PATCH requests: SPARQL and N3.

Regarding to the solid protocol¹, "Servers MUST accept a PATCH request with an N3 Patch [...]". I couldn't find anything about SPARQL inside this document, except for a reference (where I honestly don't understand why it's there).

Regarding to the WAC specification², N3 is not mentioned, and SPARQL seems to be used only as an example for appending.

So my understanding is:

1) N3 has to be supported by a solid server [solid protocol] 2) A solid server has to allow appending to files, if the user has acl:Append and the operation (semantically) only appends to the file [WAC] 3) Thus, a solid server has to allow a N3 patch which only contains solid:inserts statements

Is this observation correct? If yes, I would suggest to include the N3 patch scenario as an example in the WAC specification, in favor of the SPARQL scenario.

(1) https://solidproject.org/TR/protocol (2) https://solid.github.io/web-access-control-spec/#acl-resource-discovery

Otto-AA commented 2 years ago

Looking more at the spec (here), I've found this paragraph:

When ?conditions is non-empty, servers MUST treat the request as a Read operation. When ?insertions is non-empty, servers MUST (also) treat the request as an Append operation. When ?deletions is non-empty, servers MUST treat the request as a Read and Write operation.

This is close to what I'm asking. However, it does not make it mandatory to only require Append access if only ?insertions is non-empty. (ie a sentence like "The server MUST treat the request as an Append operation if only ?insertions is non-empty"). But I'm not very familiar with specification documents, so maybe this is implicit? Or, as described above, it's already covered by the WAC specification?

acoburn commented 2 years ago

The important subtlety is that WAC and the Solid Protocol are separate, orthogonal specifications. The Solid Protocol requires WAC, but WAC does not require Solid. In fact, there are other, non-Solid specifications, such as Fedora that also build on WAC.

Insofar as a WAC resource is hosted by a Solid Server and is governed by the Solid Protocol, then yes, it would need to support N3 Patches to conform to Section 5.3.1 of the Solid Protocol.

I would suggest to include the N3 patch scenario as an example in the WAC specification, in favor of the SPARQL scenario.

However, adding a specific requirement in the WAC spec (or even an example) of N3 makes the WAC spec dependent on the Solid Protocol, which would tightly couple WAC and Solid. Doing so would make using WAC outside of Solid more complicated for non-Solid specifications, such as Fedora.

By keeping the baseline for updates of WAC resources at SPARQL-Update (which is an independent specification), WAC can remain a more general access control mechanism.

The important thing to note is that, given the current text of WAC and the Solid Protocol, there is no problem for a Solid Server supporting WAC to support N3 patch updates. And a client can already discover what a given server supports via the Accept-Patch response header.

csarven commented 2 years ago

Aaron's review/explanation is correct and as intended.

I'd add that WAC currently does not require SPARQL Query or Update - they're used non-normatively. "Mechanisms that can be used to find [or update] required RDF statements of Authorizations is deliberately unspecified to allow for a wide variety of use."

It may be helpful to update the following statement in Note https://solid.github.io/web-access-control-spec/#http-method-access-mode-mapping to be more generic / remove mention of SPARQL to remove any confusion:

As the processing of HTTP PATCH method requests depends on the request semantics and content, acl:Append can allow requests using SPARQL 1.1 Update’s [SPARQL11-UPDATE] INSERT DATA operation but not DELETE DATA, whereas acl:Write would allow both operations.

Any thoughts/opinions?

csarven commented 5 months ago

Resolved based on https://solid.github.io/web-access-control-spec/#http-patch (via https://github.com/solid/web-access-control-spec/pull/128#discussion_r1425157693 )