Meeting minutes
Introductions & Announcements
acoburn: Any announcements or introductions?
… Thanks to anyone who participated in the face-to-face meeting.
… We made a lot of progress.
Follow-up from Face-to-Face meeting
<acoburn> Project Task Tracking
acoburn: We've added some dates in which we hope to get these things done.
… Review will be ongoing, but we aim to get the last things done around september.
… I'd like to make sure we know what we're talking about it, an that the responsible persons are still okay with the division.
… We want to be realistic and not overcommit.
… Let start on containers. I was hoping we could get this done in the next two months, but Laurens is not present. Let's skip it for now.
… Rui, are you still able to look into virtual resources?
ryey: yes, but only after two weeks
ryey: I'd aim from May to June.
termontwouter: willing to update issue #116 in May
<gb> Issue 116 Abstract 'containers' as Link Set representations of arbitrary relational metadata (by termontwouter)
termontwouter: start in May, ready in June is doable
acoburn: Storage description capabilities is cancelled, so we skip that.
… About the inconsistencies, Laurens is named there, but anyone can of course flag them.
acoburn: For updating the editor section, pchampin, might this also be done in June?
pchampin: Yes
acoburn: Jeremy is not present. Does anyone have a preference for when to tackle the introduction?
pchampin: I don't see this as blocking, so by July would be okay.
acoburn: Ready for review in June.
… For the other editorial tasks, let's say the same timeframe.
… Threat modelling. I don't know what the timeframe is. Rui?
ryey: Depends on how much time we have. It can be done in parallel. I'm happy to start after June.
acoburn: So we say June to July?
ryey: A rough version perhaps.
acoburn: Let's say ready for review in July.
… Then there's reaching out to IETF.
pchampin: I can do that this month, so let's say by June.
<ryey> Great to hear that, elf-pavlik :) Does the timeframe sound reasonable to you?
<elf-pavlik> 👍
acoburn: Super
… These are all topics Laurens captured.
… There's of course the big finishing up of notifications, type indexes, and access grants, which are not listed here.
… For notifications, the target is June, since it has not have much review.
… For the others, the end of May.
… Except for the integration of notifications in access grants, which I've set for end of June.
… Any other thoughts on this?
… Dmitri, would you want further info, since you were not present last week?
… One of the points I want to emphasize is the decisions on containers.
… In LDP/Solid today, a resource is either a Container or a DataResource.
… There's been significant interest in modelling this slightly different.
… We have decided on defining those as affordances (capabilities).
… It is then possible, though not required, to have a particular resource be both a Container and a DataResource at the same time.
… As an example of how this could work, you could have a Data Resource that with content negotiation gives you back whatever its type is
… but if you ask for application/lws+json, it will give you the container representation.
… It is up to the server if and how these can be combined; that is not specified.
pchampin: Another important point is the progress on access control to be standardized on the high level of requests and grants, and not on the level of ACLs.
… I think that is also a milestone, since it tackles a difficult point in Solid.
acoburn: Agreed. LWS defines a high-level API of access control, while a server would then translate that down to the technical level, whatever the language.
… This is defined by profiles. We provide an ODRL profile.
… A client can discover what profiles a server supports. This gives us a lot of flexibility.
dmitriz: I want to ask the group how they feel about using capabilities for access control.
termontwouter: there is room for zcap support in terms of how we define a high level and low level
… the question is whether this group would define a profile for zcaps or whether it is left to external specs
acoburn: I'm really keen on seeing how ZCAPs could work.
… There are two places in the current proposal where they could fit in.
… OAuth is our basis for how our authorization works, but since we use WWW-Authenticate headers, we could easily switch that up.
… Secondly, the high-level layer can provide a hook into the integration with ZCAPs through the profile mechanism.
… I think the challenge is more logistical than technical.
… There is a lot of new interest in defining ZCAPs, so it is hard to target something still in flight.
… We could potentially address that in a WG Note.
dmitriz: Speaking of OAuth, does the group define a specific set of scopes, or does it offer support for RAR etc.?
acoburn: We talked a lot about Rich Authorization Requests (RAR) in the fall.
… When we looked into them for LWS, we dropped it because all authorization would work without requiring it.
… An implementation could support it on top of what we define.
dmitriz: So we do not define string scopes? How do I give access to a resource then?
acoburn: That's where the high-level access request API comes in.
… Basically each server supports requests and grants of a certain profile.
… These could be defined with specific rights.
dmitriz: So we're extracting Rich Authorization Requests into a higher level structure?
acoburn: Exactly; and that will then be translated into the technical layer and access token for enforcement.
… For example, if you'd layer Rich Authorization Requests on top of it, one could imagine it encodes a certain purpose, which is then encoded into an access token.
acoburn: Any other thoughts?
… Let's end early then. Thanks again for attending last week.