# Access modes and corresponding operations in the Protocol

* [Ideas for access modes and corresponding operations in the Protocol](https://github.com/solid/authorization-panel/issues/253)
* [Universal Access Modes API](https://github.com/solid/authorization-panel/issues/194)
* [WIP table with operations in the protocol](https://github.com/solid/web-access-control-spec/issues/85#issuecomment-913456115)
* also https://github.com/solid/specification/issues/14#issuecomment-683480525
* [WAC Access Modes](https://solid.github.io/web-access-control-spec/#access-modes)
* [https://solid.github.io/web-access-control-spec/#reading-writing-resources](https://solid.github.io/web-access-control-spec/#reading-writing-resources)
* [Use Cases and Requirements for Authorization in Solid](https://solid.github.io/authorization-panel/authorization-ucr/)
* Solid PREP
* [Triggers](https://cxres.github.io/solid-prep/protocol/#triggers)
* [Activity Mapping](https://cxres.github.io/solid-prep/protocol/#activity-mapping)

# Notes

* eP: suggesting to leave Control out for today
* SC: Sort of related beyond just access modes stuff: https://github.com/solid/authorization-panel/issues/121
* eP: auxiliary resources access
* SC: pagination, index, complexity of additional access modes to the user / UI.
* eP: audiences - resource server/storage, authoirzation server, client/app
* eP: app only understands modes, never changes them
* eP: table missing `PATCH /C/`
* SC: https://github.com/solid/specification/issues/14#issuecomment-683480525
* SC: How distinguishable are PUT, PATCH, POST targeting C/
* SC: PATCH with empty payload?
* eP: it could possibly have payload which does nothing
* SC: Curious on what some implementations do with PATCH and payload only:`_:foo a solid:InsertDeletePatch.`
* SC: Considerations on whether disabling PATCH C/ to INSERT (with Append). POST C/ will not let you update C/ (irrespective to modes). PUT requires Write to replace an empty C/.

---

## Read

* GET
* HEAD
* OPTIONS - leave unspecified?

### Container

Currently container description includes containment statements. Some use cases may require reading the container description but not the containmen statements. To keep access control resource level, containment statements could be separated into a distinct resource.

## Update

* PUT
* PATCH - only specified for RDF
* POST - leave unspecified?

### Resource

Is there a need for INSERT only updates? (aka. append)

## Create

* PUT
* PATCH - only specified for RDF
* POST - on the parent container

Should we require `If-None-Match: *` for PUT and PATCH?

### Access Control

Parent container is updated by the server, not the client. The client shouldn't need priviledges for updating the parent container, only creating resources in it.

### Notifications

Triggers `as:Add` on the parent container since non-existing resource can't be a topic of a chanel.

## Delete

* DELETE

### Access Control

Parent container is updated by the server, not the client. The client shouldn't need priviledges for updating the parent container, only deleting the resource itself.

### Notifications

Triggers `as:Delete` on channels where the resource itself is the topic.
Triggers `as:Remove` on channels where the parent container is the topic.