Universal Access Modes API
matthieubosquet opened this issue · 8 comments
Currently, the Solid protocol specification https://solidproject.org/TR/protocol is tightly coupled to the WAC spec or more specifically the ACL specification https://www.w3.org/2001/04/20-ACLs and its ontology https://www.w3.org/ns/auth/acl#.
It would be good to have an easily reusable abstraction layer that directly maps an Access Mode to a behaviour of the Solid Protocol and could be reused by all authorization systems, it being WAC, ACP or any future endeavour in that matter.
We might also in that process simplify understanding and straightforwardness of the Solid Protocol. If for example a Delete and Create Solid access mode become evident as abstractions we could benefit from.
I would propose having a comprehensive review of the Solid authorization UCRs https://solid.github.io/authorization-panel/authorization-ucr/, agreeing on a list of required Access Modes and potentially adding them to the Solid namespace.
A couple of things:
If you (and others) have concerns about Protocol's requirements/wording, can you raise it in solid/specification? I've tried my best to express "When using Web Access Control" whenever it seemed appropriate to literally allow loose coupling all meanwhile WAC is core to the Protocol. Certainly other parts of the spec can be improved / less "tightly coupled" - can you please raise specific issues on this in solid/specification?
If create, delete, replace, update, append.. can be seen as subclasses of write, the obvious thing to do considering Linked Data best practices is to extend what's already available. So, we can indeed subclass acl:Access.. just like acl:Append is a subClassOf acl:Write (which is a sub class of acl:Access. The ACL Ontology is flexible enough for ACL-based access control systems. WAC is not the only thing that's out there using http://www.w3.org/ns/auth/acl or even all of it. Alternatively, have new vocabs sub class ACL's stuff. Right..
Having said that, see also my comment in solid/specification#210 (comment) .
But before going too far out, may I suggest to perhaps see how far WAC(+extension) gets us, and then decide based on actual needs, implementations, agreed/mature specs...
Notice how "Control" access was in the UCR but then was taken out / "reframed". Take a wild guess as to why ;) So, while I'm generally okay with listing potentially atomic access modes of the Requirements of a UC, I don't believe that the underlying assumptions in the UCR are correct. UCR needs a review and rewrite, besides quite a bit of the UCs are completely convoluted / unreadable right now - and not swing based on the needs of specific solutions (whatever happens to be favoured by people at a given time).
By the way, that W3C's ACL you've linked to is still in use by W3C and running for ~two decades now. Its ontology is actually http://www.w3.org/2001/04/ACLS/Schema not http://www.w3.org/ns/auth/acl (as in WAC... ) even though they share the same history / latter with takeaways from the former. Seems like a such a simple/extensible mode system went a long way for an organisation like W3C.
Part of the issue here seems to overlap with what's discussed in #121 . After all, ACL-based systems are most likely not the only ones for the Solid ecosystem in a long enough timeline, and we've already seen the potential use of capability-based security models in Solid. As well as those being worked on by other CGs. Perhaps the panel needs to tackle this issue properly as the underlying content is evidently brought up in different ways eg. Evaluation table..
Would you like to create a similar issue for authentication so we don't "tightly couple" Solid OIDC to the Protocol?
Seeing your comment solid/specification#210 (comment), I would suppose we agree to some extent on the need.
Sorry for the lack of clarity, but the reason why I am raising the issue here is because I'd like to start with the needs as expressed in the UCRs and addressed through WAC/ACP/WAC+ implementations to have a clear idea of what might work.
UCR needs a review and rewrite
That sounds like a good start. :)
I don't believe that the underlying assumptions in the UCR are correct
It would be good to understand which assumptions are incorrect. Could you help me here? I'm happy to review the UCRs, but it would be good to have pre-identified problems in mind.
ACL-based systems are most likely not the only ones for the Solid ecosystem
There is definitely some overlap with #121, but I think 121 raises broader questions that I can't quite encompass at the moment.
Would you like to create a similar issue for authentication so we don't "tightly couple" Solid OIDC to the Protocol?
I'm not sure what you mean or how I would formulate that.
I agree that it'd be useful to have a list of access modes needed by some requirements. However, I'm not agreeing on where or how to apply that information (yet) :)
I very much agree that we need language in the protocol spec that details access modes. I don't know that I would call it an API, but we need to detail what we understand by different access modes (and more than we have access modes for in WAC, for example, File Scan is a read operation on a container), and what the responses should be in different situations, and so on. Then, WAC, ACP (and etc) could reference that normatively.
LDP: 7.2 Preferences on the Prefer Request Header defines ldp:PreferMinimalContainer which excludes containment triples. Example from the spec:
GET /netWorth/nw1/assets/ HTTP/1.1
Host: example.org
Accept: text/turtle
Prefer: return=representation; include="http://www.w3.org/ns/ldp#PreferMinimalContainer"I think it will be very useful to allow Read of minimal container without listing all the containment triples. This would come in play for example with Data Reigistrations (possibly will be renamed) in app interop spec. Related issue: solid/data-interoperability-panel#120
Implementation I work on currently assumes that it can get some information from Data Registration even if it doesn't have access to all LDP contained Data Instances. Preferebly it shouldn't even know about existence of those which it can't access.
EDIT: using user managed and server managed terminology I think about something like ReadUserManaged
Important not to conflate document- and content-level access control!
Thus far, WAC's use of ACL's access modes is for resources as opposed to their description.
Prefer is a client hint, like Slug. Server can ignore without an error signal.
Client is requesting a slice of the resource description with Prefer and ldp:PreferMinimalContainer. When a server supports that, it can check if there is any Authorization rule with Read for the target resource.
Server dictates the requirements for a given operation, e.g., server can require Read and Write for PATCH with DELETE DATA; server can require Write and Read for PUT with If-None-Match: *
It may not be worthwhile/sensible to come up with new access modes for arbitrary HTTP request dimensions.
Important not to conflate document- and content-level access control!
True, with something like ReadUserManaged we would get more granular than resource-level.
Not to sidetrack in this issue, I'll create issue (unless relevant one already exists) in specification repo to consider having separate dedicated resource for server-managed containment triples.