Access Mode Extensions

[csarven]

The ACL ontology ( http://www.w3.org/ns/auth/acl ) defines acl:Read, acl:Write, acl:Append, and acl:Control access modes.

This is a general issue, a study, to document common operations and new access modes (based on use cases).

[csarven]

Documentation of operations and access modes from discussions.

• Write (class of write operations - acl:Write)

  • Append (to add information to resource state - acl:Append)
  • Create (to create resource)
  • Delete (to delete resource)
  • Replace (to replace resource state)
  • Update (to modify resource state)

• Read (class of read operations - acl:Read)

  • List (to read an index or pagination)
  • Query (to read processed information)

• Control (class of control operations - acl:Control)

  • ControlRead (to read an access control resource)

[csarven]

The WIP table here can be used to get a deeper understanding of operations and access modes. Operations may be determined by the nature of an HTTP request but they are not strictly limited to HTTP requests.

For the time being, the table uses CRUD terms for simplicity and the purpose of this discussion - do not bother to nitpick on this. Happy to switch to use a different variation, RFC terms, or introduce 50 very specific terms. WAC ED loosely uses CRUD terms for common operations but it is not fixed to that.

• Important to not conflate resource-level e.g. create or delete resource, and content-level operations, e.g. add or remove information.
• A request may entail one or more operations, including a processing operation depending on target resource that breaks down to specific operations on one or more resources.

I'm not sure what to do with this table yet / where to put it but we can figure something out alongside solid/specification#14 (comment) (even if it just serves to catch bugs or our assumptions).

Request	Operation	Access Modes	Level
GET /C/R	Read	acl:Read	Resource
HEAD /C/R	Read	acl:Read	Resource
OPTIONS /C/R	Read	acl:Read	Resource
POST /C/	Create + Update	acl:Append [1]	Resource, Content
PUT /C/R + If-None-Match	Create, Read	acl:Write, acl:Read [2]	Resource
PATCH /C/R + If-None-Match + INSERT	Create, Read	acl:Write, acl:Read [2]	Resource, Content
POST /C/R	Update	acl:Append (or acl:Write)	Content
PUT /C/R	Create?, Update	acl:Write [2][3]	Resource
PATCH /C/R + INSERT	Create?, Update	acl:Write [2][3]	Resource?, Content
PATCH /C/R + DELETE + INSERT	Create?, Read, Update	acl:Write, acl:Read [2][3]	Resource?, Content [4]
PATCH /C/R + DELETE	Update, Read	acl:Write, acl:Read	Content
DELETE /C/	Delete	acl:Write, acl:Read	Resource
DELETE /C/R	Delete	acl:Write [5]	Resource

[1] POST /C/ is to "perform resource-specific processing on the request payload" (RFC 7231). The semantics in Solid Protocol: server-assigned name for resource to be created as member of container, and to update containment statements. So, Create operation of /C/R and an Update operation on /C/.

[2] Requires Append (or Write) on /C/ and Write on /C/R to Create.

[3] Requires Write on /C/R to Update.

[4] PATCH /C/R + DELETE + INSERT could be interpreted as a specific content-level update (or modify) operation where DELETE s1p1o1 and INSERT s1p1o2 - I don't know what the practice/terminology is out there for this. We can come back to this later.

[5] Requires Write on /C/ and /C/R.

[bblfish]

Very helpful. Just a reminder that there is simple easy to understand argument to remove the Control Mode, with more logical/mathematical arguments to support that in Specification issue #303.

Also, it should be possible to model your table using mathematical work on Lenses, to get at precisely why the different modes exist, and how they interact with the HTTP methods.

[gibsonf1]

From the Solid Practioners meeting 2/6/2025 and health care use case by Marc Haddle, I think an additional WAC mode is needed that allows control access but only for read such that, for example, an xray provider has full control of xray data for a patient (the data owner), but gives the patient control-read of that data such that patient can share it with anyone they choose, but is not able to edit/delete it.

I'm thinking as simple as possible here, that medical provider gives patient permanent control-read of their medical data, and that patient is then able to create read authorization for that medical data (and delete those authorizations) as much as they like. Just using WAC as is now, except one more mode, control-read. For anyone with whom access is shared, they can trust the validity of the data as it uses the url of the provider/author directly.

From a Server implementer perspective, the current WAC is integrated and cached at the DNA level of all operations, so adding one more mode within that framework is a very simple thing and scales to billions etc. Adding a whole new delegation functionality could be quite involved, but we are not necessarily opposed. Because we are able to control permission at the triple level, we can effectively also support any other approach like ACP where its a higher level abstraction that ultimately controls the WAC at the bottom scaled level. (For example, a permission that expires would simply be a process on server to delete the permission at a certain time, where the permission is standard WAC, etc)

So from a systems engineering perspective, the simplest possible base level that scales is ideal for building abstractions on top of. (Our LDH lower ontology is very simple and is the form in which all data is saved)
From a user intention use-case perspective, control-read is something that applies in so many cases from cars, to houses, to companies, etc. So a very useful base control that solves many use-case intentions.