Should access grants edit ACLs?
michielbdejong opened this issue · 5 comments
If desired, the ACL system on a Solid storage server (either WAC or ACP), can keep track of all information that is necessary for access decisions. The request made by the client only needs to carry generic identity information (WebID, VC, Client ID, Origin). The ACL document(s) on the storage server act as a guest list.
On the other hand, proposed systems like SAI and Inrupt Access Grants allow moving the access decision away from these on-storage ACL systems and into a separate authorization server.
This authorization server can then either give out a token that contains its decision, or edit the on-storage ACLs to reflect its decision.
IMHO this is a fundamental discussion about how (fine grained) access control works in Solid. Let's have a special topic meeting about it! :)
We had some discussions around Access Matrix
I find it helpful to see that the same Matrix can be collapsed based on resources as well as based on agents. Both ways come useful in different scenarios.
Just as WAC allows use of agent classes in SAI we have somehow comparable way of using resource classes (often based on shapetrees). This way an access policy can be set on the high level which covers:
- resources which don't exist yet, even if they will be created in solid storage yet also not existing at the time
- delegation for resources which haven't been shared yet (possibly also don't even exist yet)
I would also note ACP Server distinct from ACP Resource Server which already introduces useful separation.
Last but not least is the delegation, the most basic documented use case I believe is addressed by both SAI and Inrupt Access Grants. We should also make sure that Solid can support longer delegation chains. Based on work with the basic case, dedicated Authorization Server/Agent/Service provides a good place to burden with all the relevant responsibilities.
EDIT: I have forgotten something that we already discussed on various occasions. Having user doing all there access management in one place also helps with guiding the architecture and clarifying expectations and level of burden that can be assigned to this specialized dedicated party (Authorization Agent / Authorization Service / Launcher App / Solid OS permission UI etc.)
For the time being, I've suggested to have that meeting on 2023-11-14 because there is the potential of having a joint meeting with the Social CG on 2023-11-21 (or 2023-11-24 or another...). See poll here: #594 .
It is possible to have both meetings on 2023-11-21 but then the STM would start on 14:00UTC and joint meeting on 16:00UTC. Figured some people may not want to have a 4h meeting as they'd likely want to join both meetings. I'm open to suggestions. Let's continue discussing in solid/specification chat.
We discussed this and didn't really find a good answer I think. We'll work on this as part of #615
We discussed this some more in today's UX/DX Improvements meeting.
I'll create a follow-up issue proposing to add SAI as a third option in section 11.