Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What does a Write operation imply #126

Open
kjetilk opened this issue Dec 3, 2019 · 7 comments
Open

What does a Write operation imply #126

kjetilk opened this issue Dec 3, 2019 · 7 comments

Comments

@kjetilk
Copy link
Member

kjetilk commented Dec 3, 2019

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.

@kjetilk kjetilk added this to the December 19th milestone Dec 3, 2019
@csarven
Copy link
Member

csarven commented Dec 4, 2019

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
Copy link
Member Author

kjetilk commented Dec 4, 2019

@kjetilk

This comment has been minimized.

@kjetilk

This comment has been minimized.

@kjetilk
Copy link
Member Author

kjetilk commented Dec 16, 2019

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
Copy link
Member

csarven commented Dec 31, 2019

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
Copy link
Member Author

kjetilk commented Jan 2, 2020

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Drafting Phase
Development

No branches or pull requests

3 participants