https//meet.jit.si/solid-authorization
- Minutes 2021-08-25 #252
- Ideas for access modes and corresponding operations in the Protocol #253
- https://gitter.im/solid/specification?at=609265f3f7e4221825bae33d
- Sarven
- Henry
- Eric
- Pavlik
- Barath
- Justin B
Pavlik: merging
Henry: I like the image on issue 253 issue a lot. It has three main modes: Read, Write, and Control.
The top level of Read and Write are for sure very solid. Indeed, I have implemented a Web Server using a very simple data structure for containers, together with a concept from Functional Programming called Lenses (see An Introduction to Lenses in JS). Lenses are essentially built out of two types of operations: getter and setters; or Read and Write operations. With those operations, one can build up all an LDP web server. Having said that about Read/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 control resource.
Sarven Some other ACL mechanisms model control, they also use term owner. Google's ACL uses owner.
Sarven In WAC we treat ACL as data points as well. Even the possibility of an ACL (just as any resource) having an ACL suggests that they should be considered as data points.
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 classes of operations; for instance, write includes create and delete. See: solid/web-access-control-spec#85.
I talked to Kjetilk about why create the operation issue under authorization-panel - it was to create engagement / get feedback from the panel. 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.
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.
solid/web-access-control-spec#85 (comment)
e.g., PUT typically needs only Write mode, but PUT + If-None-Match: * would need both Write and Read.
Henry To Eric's point above: the reason I am reaching out to Category Theory, is that
it is the mathematics of structures. What it tells us is that Dynamic Systems can be
modelled using essentially just these Read and Write operations. See the maths
discussed on web-cats.
Since we can also do without Control mode,
that indicates that it is not a structural necessary piece at the level of Read and Write.
It should be modelled differently (via the Link header).
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 a legitimate case to get some useful information.
Justin Having Update / Modify on containers means for me that one can change the non-server managed (containment) triples. To change those one would need Create (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
the evaluation section
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's hard if current systems don't support it. We do have use cases which detail Create, Delete, Update, and real world cases where 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 a bit about it here with regard to lenses. I think use cases are very good. I think we should do what we did in the evaluation section, seeing how it would work with HTTP methods etc.
Sarven Minutes should only include what was discussed in the meeting. We can fix typos but don't add more information. We should do that in Issues, PRs, or elsewhere. See my comment on Gitter on May 05 11:31 in Solid/Specification. Assign scribe(s).
Henry: Fine, but it happens a lot that the scribe misses out what is said during the meeting - it is difficult to listen and type. And I would argue that there is also the context during the meeting that can be filled in to help make the minutes readable. That is also why we have the process of putting the minutes in PR, so that everyone can fix up what they felt was not clear.
Justin: To select a use case specialised on modes and present it in the form of an evaluation as discussed above.