Table connecting verbs and modes

[michielbdejong]

See https://github.com/michielbdejong/web-access-control-spec/blob/verbs-modes-table/README.md#relation-between-http-verbs-and-modes-of-access

[TallTed]

ties things closely to HTTP

@RubenVerborgh - Perhaps you might be less against the idea if surrounding phrasing described the HTTP verbs as clarifying examples, rather than implying (if only by not mentioning any other verbs/systems) that they're the only possible methods?

[michielbdejong]

@RubenVerborgh and @timbl, let's discuss this in person on Monday!

[michielbdejong]

Sure, we can move this to a note, or even a wiki page, or part of the readme of the testsuite, as long as it's written down somewhere exactly what modes are required for exactly which actions.

[michielbdejong]

@RubenVerborgh @acoburn changes applied, please re-review?

[michielbdejong]

The data browser Sharing pane offers 5 useful defaults:

• 'owners' is read+write+control, "can read, write, and control sharing."
• 'editors' is read+write, "can read and change information"
• 'posters' is read+append, "can add new information, and read but not change existing information"
• 'submitters' is append, "can add new information but not read any"
• 'viewers' is read, "can read but not change information"

This is then to be interpreted differently for a container than for a non-container. For a container, read permissions means you can read its ldp:contains triples. For a non-container resource, it means you can read its contents as it was last written or updated through POST, PUT or PATCH (and optionally make the server do some RDF operations on it).

For creating a new resource, I confirmed empirically against NSS that if you choose the URL with PUT, then write on the container is not enough, you also need write on the resulting resource. Append on the resulting resource is also not enough then.

But what's funny is that if you append to a container with POST, then append on the container is enough and no rights at all at the resulting resource are needed.

For DELETE, write on the container seems to be enough. You don't need to have any write permissions on the resource. This is weird because it means that there can be resources which you can DELETE but not PUT or PATCH.

[michielbdejong]

As mentioned in https://github.com/solid/solid-spec/pull/193#issuecomment-574554383 the success/failure of a DELETE can expose existence, and therefore it should require that read access. It's a diversion from POSIX but it makes sense and it's how NSS currently implemented it for PATCH. That discusssion is only in the context of deleting triples from an RDF source, but we could equally apply it to containers; to delete a resource you should probably have access to read the container it's in. However, that's not what NSS does (I just tried:

curl -X DELETE https://michielbdejong.inrupt.net/public/public-write/test.ttl

and that succeeded without read access to https://michielbdejong.inrupt.net/public/public-write/) so I guess the reasoning for deleting triples inside a file is slightly different from the one applied for deleting files from a folder. So this table is correct in stating that DELETE does not require container read, but PATCH containing deletions does require Read in addition to Write.