# 2021-09-01 Authorization Panel

https://meet.jit.si/solid-authorization

## Agenda

* [Minutes 2021-08-25 #252](https://github.com/solid/authorization-panel/pull/252)
* [Ideas for access modes and corresponding operations in the Protocol
#253](https://github.com/solid/authorization-panel/issues/253)
* https://gitter.im/solid/specification?at=609265f3f7e4221825bae33d

## Present

* Sarven
* Henry
* Eric
* Pavlik
* Barath
* Justin B

## Minutes

### [Minutes 2021-08-25 #252](https://github.com/solid/authorization-panel/pull/252)

Pavlik: merging

### [Ideas for access modes and corresponding operations in the Protocol
#253](https://github.com/solid/authorization-panel/issues/253)

Henry: I implemented lenses server using Read and Write. I think Control is in the wrong place. I don't see it as type of mode, I see it as relation.

Eric: I think this is just a linguistic confusion. Control just stands for edit the access.

Sarven: Some other ACL mechanisms model control, they also use term owner. Google's ACL uses owner.

Pavlik:

Sarven: In WAC we treat ACL as data points as well. Even possibility of ACL having ACL suggests that they should be consider as data point. I agree that it can be achieved in a different way. The aspect of operations has been in the protocol for quite a while. Operations are not just atomic modes but class of operations eg. write includes create and delete. See https://github.com/solid/web-access-control-spec/issues/85 .
I talked to Kjetilk about why create the operation issue under authorization-panel - it was to create engagement. Protocol has some of those definitions of operations and WAC currently defines mapping of HTTP methods to access modes only to inform developers. Currently operations are normative whereas specific HTTP methods are non-normative. The reason is eg. PUT typically needs Write mode, but PUT + If-None-Match: * would need Write and Read.

Henry:
The Read and Write are structural. See the maths
discussed on [web-cats](https://gitlab.com/web-cats/CG/-/issues/28#note_666179055).
We can do without Control mode, which indicates that it is not a structural necessary piece at the level of Read and Wrote. https://github.com/solid/web-access-control-spec/issues/94

Sarven: PATCH can include DELETE, so in that case it will require read and write.

Pavlik: can we have Write without Read?

Pavlik: How do we see that List mode, can we separate reading container description and the list of containment triples?

Sarven: List would be limited type of Read. It seems that we are coming to consensus on listing containers. We have this understanding of what container is and what container description can be. The starting point seems to be that description includes containment. There is legitimate case to get some useful information.

Justin: having Update / Modify on container means for me that one can change the non-server managed (containement) triples. To change those one would need Created (which would result in adding) and Delete (removing)

Sarven: I'd like to see actual applications before hypothesising.

Henry: I think we should take some use cases, try to implement them as we have done in in the evaluation
section https://github.com/solid/authorization-panel/tree/main/proposals/evaluation
and see if we can use the minimal Read/Write modes, and then we can try our best using existing modes, and then see why exactly a new mode would be necessary.

Pavlik: I don't think Append on a container should imply Create, it should only allow adding new statements to the container resource.

Justin: Access Modes should provide specificity to define access exactly the way one wants.
When it comes to dogfooding it hard if current systems don't support it. We do have use cases which detail Create, Delete, Update and real world cases when current access modes lead to over permissioning. I would like to understand what else is requested besides use cases that are already included.

Henry: re append, I thought abit about this here:
call I started looking at what Append could be with regard to lenses
https://gitlab.com/web-cats/CG/-/issues/28#note_666387691

Henry: I think use cases are very good. I think we should do what we did in evaluation section, seeing how it would work with HTTP methods etc.

Sarven: GOTO 57

### https://gitter.im/solid/specification?at=609265f3f7e4221825bae33d

Sarven: Minutes should only include what was discussed, we can fix typos but don't add more information. We should do that in Issues, PRs or elsewhere. Assign scribe(s).

## Actions