Towards an authorization framework for the Solid ecosystem #121
Comments
csarven
added
documentation
|
That table is a very good idea.
If RelBAC maps directly to WAC then the interesting question is what is the difference between ACL and ABAC? Well it may just be that RelBAC without OWL reasoning gives one ACL. With OWL reasoning and depending on how much one may get the rest? (something to verify). |
|
Authorization Capabilities for Linked Data (An object capability framework for linked data systems): https://w3c-ccg.github.io/zcap-spec/ Fetch coffee: https://lists.w3.org/Archives/Public/public-credentials/2020Dec/0028.html |
|
I don't know Sabrina Kirrane personally (I only talked to her once a few years back), and I'm not intimately familiar with her work, but it does seem like it could be highly relevant here, in particular a 2017 Survey of Access Control in RDF. Perhaps also her PhD thesis from 2015 Linked Data with Access Control, or her other Access Control-specific research: http://sabrinakirrane.com/ |
Edits:
To follow DRY, I'd like to share some considerations and possible directions for authorization in the Solid ecosystem that I've found myself bringing up in the repos and meetings.
The following is not intended to be a concrete proposal to change course, a deep study of access control and security models, or even evaluating existing and upcoming mechanisms. One overarching goal is to better situate authorization in context of the Solid "ecosystem", and possibly establishing a framework or understanding that can accommodate different types or aspects of access control models as well as capability-based security models.
This is not an invitation to do everything and all from scratch. If anything, it should help to keep focus and be mindful of the scope of the work.
A global axiom:
The "Ethical Web Principles" must (continue to) drive our work given that the implications are immense. We can't lose sight of this while in pursuit of spec/engineering perfectionism. Among many factors that come into play, we should carefully consider what may be good for the end user (~short term) as well as the public (~long term).
Brief background:
Some questions to keep in mind (not necessarily to answer):
A basic example to illustrate different needs:
What are the requirements to know whether something - a resource or a statement- exists or not eg. think of containment listing or checking for query patterns? For example, when using WAC, if one is granted to read a resource, they can get its complete description. But what if that resource is a container, and it refers to other things that the agent doesn't have access to. What are the ethical and technical consequences of this design? This is where we may need to consider if/how (for instance WAC) can be extended or used alongside another mechanism (eg. ABAC?) that's better suited to address these concerns. Or who knows, maybe the consensus will be that it is a non-issue/wontfix.
There are many ways to approach this (and I have more questions than answers). If it helps, we should consider categorising the requirements from use cases in terms of control models that's likely needed - multiple models can certainly meet a need. This can also drive how existing or upcoming mechanisms may be extended or loosely coupled. Using the current /authorization-ucr/ , here is one way to go at this (Expect errors! I blindly jotted the models from the URLs.. will need to re-read the UCs and update):
Towards a framework:
Perhaps a bit early to tell what that might be or look like but we are not working from scratch either. I've come across some work which is arguably pretty close to what it can be - that is not to say that we need to take these things as is. We can adjust them to our needs or take it as inspiration towards what we want. (Small world: @owensacco did this work around same time, if not earlier, I got into Solid but we somehow missed each others work). Have a look at:
There are loads more we should have a closer look. Will update this space...
The text was updated successfully, but these errors were encountered: