Meeting minutes
TallTed: since this is not an official meeting, just to capture discussion as it goes
Discussion of authorization mechanisms (proposed by Jesse Wright)
jeswr: Current LWS: Two focuses, R/W interfaces for LWS (similar to Solid) but will separate content transformation, Authorization system for LWS should look like (prior art: ACP, WAC, interop, zerocap, etc)
… A few different layers to specifiy: Abstract datamodel https://
… ACP has combined some layers which may not be ideal. Having LLM generate paradigm profiles of these things. Does this approach make sense?
termontwouter: Looked at the architecture, in general looks like a good approach. Have questions about what falls in LWS scope. For 0 & 1 layer, looks like ODRL has been doing, do we need to redo or incorporate? Level 5: Too many to support in LWS
jeswr: LLM generated it, and haven't edited carefully yet. For scoping, need well defined layer 2, layer 1 may not need to be defined here. Will ODRL work in this context as its mainly semantic web users, and may be too complex? XHTML
… Scoping need to specify a couple at layer 4 and 5. Ideally separate specification can be used for other than only LWS, precondition for policies very similar, only postconditions are different (then for agents). Need to define layer 1 - 5 for current LWS. So what can we reuse, ACP conflates layers, WAC missing some features, are others
… available to look at?
termontwouter: Most has an equivalence in Oauth. Only lower level need to tie in semantically - no unifying semantics there.
… https://
jesswr: Does GNAP do what we need?
termontwouter: yes, the flows should work
woutslabbinck: Can be the whole enforcement mechanismn, access control framework all tied together - XACML (architecture used under the hood)
jeswr: Is this correct: XACML enables defining concepts that give an admin engine and interface, gives an Oauth flow back to come to server?
woutslabbinck: mainly refer to XACML as a Policy engine and baseline (espically in academia)
jeswr: Can we fill gaps with XACML?
woutslabbinck: For a modular approach, it makes sense. (Layers 0-3) Can add dynamic components (have seen in papers and presentations) Don't know other frameworks with same impact (Survey paper from Sabrina 2020 - with good summary - at semantic web and looks broader)
jeswr: Is XACML implementable (not just academic)?
bendm: Don't think we have theoretical things in ODRL, can we come the other way around instead of solving all problems at once, would it be more practical to start from WAC, add extensions we need and see how far we get. It might be otherwise to theoretical and non-implementable. I assume whatever we propose will be out of date in 3 years, why
… not focus on secure achievable that currently works (is deployed)
jeswr: Is a reason for WAC as a starting point?
bendm: WAC is least complexity, but don't have a preference over ACP
jeswr: an exact split in deployment between ACP and WAC in current implementations
termontwouter: Why do we need to choose between wac or acp?
jeswr: Not sure how the choice can be skipped. You have an authorization graph, and need to define semantics on how to evaluate and build up the graph.
gibsonf1: For WAC on TrinPod, we are having no issues (after a PR years ago to correct an algorithm error as well as with triple level resources)
termontwouter: For LWS, it's not the interface, it's the furthest thing in the back of the server, so choice not needed
jeswr: I think a minimum needs to be specified for interop.
termontwouter: Can define logic and not implementation specifics
woutslabbinck: It's quite important to have a choice for interop
termontwouter: Client doesn't care whats happening under the hood on an implementation
termontwouter: scope is just a string, what happens on implementation under hood no one cares
jeswr: But what about client editing permissions?
… Do you mean to say that LWS should not allow (specify) how client edits permissions? And in practice is coupled with service provider?
termontwouter: Yes. Editing permissions is not a positive. Negative as it forces client to see control policies as resource on a server
… Restrictive: couples authorization to resource server, ACP couples policies to resource on a document level.
gibsonf1: Triple level security via state as a resource, uses standard Solid ACL writing as for any resource.
jeswr: Option 1: Start with bendm's approach of starting with WAC. Option 2: Come up with layer 2 to rule them all. Option 3: Start with UMA flow of today, and what would better profiles in WAC look like. I don't know what best option is
termontwouter: We're working on UMA for sure. Actively working level 5, some on level 4, 1 and 0 moving a bit to URDL.
jeswr: anything close to paradigm profile to use for LWS?
termontwouter: No
woutslabbinck: No decision made for how to translate to reusable attributes, logical groupings of resources is what we've been working on, the others not as much. ODRL group not focused on constraints and further formalization on how to get attributes and proper roles in there or in the UMA server.
… Is on the roadmap, not clear on which priorities will dictate these matters currently
jeswr: Can do some research in the meantime on the different options, and from that see if a layer 2 can be derived for further discussions (potentially for profile in UMA to get implemented around this)