What does a Write operation imply

[kjetilk]

From several discussions, we are starting to rely on side effects to update certain resources, especially containment triples.

This opens the question: What is really a write operation?

It is pretty clear that when you write to a resource, that's a write operation. It gets more unclear when there are updates done by the server as a side effect.

We could adopt the interpretation that if the state of a resource Q is altered by an operation on a different resource R, that operation requires write privileges on that resource Q, even if it R is the resource identified by the request-URI.

One implication of this idea is for example that deleting a resource R requires write privilege on the container C, since it requires updating the containment triples.

[csarven]

There are somewhat similar considerations to Read eg. #116 (comment) discuses privacy as per containment listing in that the observability of a resource is uniform.

[Aside (oh you may like this analogy): while a resource may not be observable, attempting to delete a container and failing in the absence of Read access may partly hint at the possibility that something exists. Just like a blackhole and how it bends light passing by :)]

[kjetilk]

Ref: https://github.com/solid/solid-spec/issues/195

[kjetilk]

In the absense of further discussion, and since we have more or less gravitated towards the interpretation that write on container is required for delete, I would like to propose my formulation as a consensus item, i.e. that

If the state of a resource Q is altered by an operation on a different resource R, that operation requires write privileges on that resource Q, even if R is the resource identified by the request-URI.

[kjetilk]

Actually, come to think of it, altering the state of a resource Q may be an append operation too: If creating a new resource R in a container is an append operation, it alters the state of the container since a containment triple will need to exist for that resource. So, we need to address #118 first.

[kjetilk]

So, I'm trying to think in terms of sufficient conditions and recursive definitions. Don't know if I'm succeeding. :-) But how about something like

acl:Write is sufficient to alter the state of a RDF resource R if the resource can be altered

1. without reading it,
2. without side-effects changing the state of any other resource Q, except when acl:Write also applies to the resource Q.

The append case should then be covered by the similar but stricter conditions in #118.

[csarven]

We should take care to not introduce a new definition in this issue but okay that if it can help to articulate the notion. Clarifying the relationship between HTTP and WAC would be pragmatic as in https://www.w3.org/wiki/WebAccessControl#WAC_relation_to_HTTP_Verbs

Write is an update in that information can be created or removed, and categorically excludes operations to "read", as well as unintended exposure or side-effects within that.

A write operation affects a set resources atomically and recursively. For example:

• adding a new resource to a container entails: i) create resource, ii) add containment statement about the created resource, iii) create parent or ancestor containers, and their containment statements as necessary.

• updating an existing resource entails: "overwrite the contents (including deleting it, or modifying part of it)"

With respect to HTTP verbs that are intended for writing, POST, PATCH, PUT and DELETE can be used for the purpose of write. In the case of PATCH, acl:Write would not allow the WHERE clause (re "unintended exposure or side-effects").

[kjetilk]

Ibid, #118 , I'd say :-) So, we need to write the normative text, but we have pretty much the same understanding. Rough consensus?