Meeting minutes
acoburn: introductions & announcements
<RazaN> +1
Beau: work at technical institutes on social innovations
… background in system integration
Introductions and announcements
Beau: familiar with linked data
… had work on the Solid spec
… worked on the YYY project
acoburn: this experience will be useful for the group
Monsecom: background as a data scientist
<Beau> Will do
RazaN: I'm a postdoc recently joined AZ's group
… will be using Solid in my research
… Semantic Web background
acoburn: we talked about a possible face to face meeting
… we are working on something maybe in the USA in October or November
<gibsonf1> I think its UK or EU (not USA)
<ericP> i'm available
<Monsecom> Beau and I work as developers at VITO (vito.be) , mainly in the We Are (https://
acoburn: there will be a holiday soon in the US and we might skip the meeting
<pchampin> I will be available
<Monsecom> I have a background in computer science
<gibsonf1> available
acoburn: memorial holiday in the US and spring holiday in the UK
<Monsecom> available
acoburn: nobody seems to complain, so we can keep the meeting
<gibsonf1> @AZ on earlier note about meetup, not USA but UK or EU
Action Items
acoburn: Hadrian is away today
Use Cases status summary
acoburn: let us jump to next agendum
… there're 2 PRs open by Pierre Antoine
… I think we should merge that
… this is preventing us from publishing as a working draft
<acoburn> UC title
<gb> Pull Request 155 Add a "real" title to the document (by pchampin)
pchampin: I overlooked the fact that the title was wrong
… which is what hold the publication back
acoburn: seeing no objection I'm going to merge
… another PR open by Hadrian
… it introduces new use cases with serialisation formats
… BTW, this is a introductory list of UCs, no guarantee they will be in the final report
… there are specific UCs
… that were merged or closed
… because they were part of consolidated UCs
… in the published document, we want to have pointers to the GH issues and a trace where they come from
… issue ucs #30 was closed
<gb> Issue 30 not found
acoburn: issue #35 was closed too
<gb> Issue 35 not found
acoburn: reminder: we can find the doc that we want to publish in Github and there is a loink to the final W3C location
… issue #95, #111 were also closed
<gb> Issue 95 not found
<gb> Issue 111 not found
<gb> MERGED Pull Request 123 Updated glossary (by hzbarcea)
acoburn: w3c/lws-ucs#112, w3c/lws-ucs#134 were closed/merged too
<gb> CLOSED Issue 134 [REQ-F] Adding, updating, deleting Resources in Storage (by hzbarcea) [review]
<gb> CLOSED Issue 112 [UC] Storage portability from a provider to another (by hzbarcea) [duplicate] [usecase]
acoburn: questions about these?
<Beau> My GitHub account: https://
Discussion: Authorization
acoburn: we started the conversation about authorization last week
… we can talk high level what we want
… not going into specific solution
… there are several issues related to authorization
… for instance w3c/lws-ucs#70
<gb> Issue 70 [UC] Discoverable Authorization Requirements <DRAFT> (by termontwouter) [triage] [usecase]
acoburn: another is w3c/lws-ucs#67
<gb> Issue 67 [UC] Processing-based Access and Usage Control (by termontwouter) [triage] [usecase]
acoburn: this one is more about what was discussed last week
… another is w3c/lws-ucs#66
<gb> Issue 66 [UC] Purpose-based Access and Usage Control (by termontwouter) [triage] [usecase]
acoburn: and w3c/lws-ucs#65
<gb> Issue 65 [UC] Context-based Access and Usage Control (by termontwouter) [triage] [usecase]
acoburn: and w3c/lws-ucs#63
<gb> Issue 63 [UC] Policy Management for Derived Resources (by termontwouter) [triage] [usecase]
acoburn: and w3c/lws-ucs#61
<gb> Issue 61 [UC] Intuitive (Data Type-Based) Policy Management (by termontwouter) [triage] [usecase]
<Zakim> gibsonf, you wanted to ask what is a derived resource
<gibsonf1> gibsonf1
acoburn: the way I understand derived resource (63) is
… say you have a set of fixed resources, and then a set of resources that derive from that
gibsonf1: if you had a request to ???
<gibsonf1> a derived resource = derived resource
acoburn: it depend a lot on how resources are defined in some
<gibsonf1> question was: Wouldn't request to a derived resource be no different than a request to any resource with respect to authoriazation?
acoburn: other issue that's related is w3c/lws-ucs#60
<gb> Issue 60 [UC] Freedom of policy modelling language/mechanism (by termontwouter) [triage] [usecase]
acoburn: the UC also introduces more complexity
… yet another is w3c/lws-ucs#89
<gb> Issue 89 [UC] Share data with a (potentially large) community/group of people (by mrkvon) [triage] [usecase]
acoburn: finally w3c/lws-ucs#64
<gb> Issue 64 [UC] Fine-Grained Control Over Resource Access (by termontwouter) [triage] [usecase]
acoburn: Last thing I want to mention
<dmitriz> what I find fascinating about these issues, is that they highlight the central tension in this WG.
acoburn: 1 approach that is in Solid is that access control is internal
… it's fairly constrained bu it's sinternal to the sercer
<dmitriz> is our goal comprehensive documentation of use cases? (in which case, this is pretty great). Is our goal shipping a first iteration spec that we can build upon? In that case, most of these are _way_ too advanced / ambitious
acoburn: 1 approach would be to handling this externally to the server
… e.g. defining what an access token would look like
<Zakim> pchampin, you wanted to ask about what 'external to the server' means
acoburn: that would allow other kind of abilities
pchampin: not sure what you mean by external to the server
… it could be that the server relies on an external server for access control mechanism
… it may be an implementation detail not in scope for this group
… could you clarify exactly what you mean, acoburn
acoburn: this has impact on what we do for the protocol
… is the LWS protocol going to define what's in an identity token
… one approach would be to define a format of an access token
… separately, you could define how you get access to the token
… using a binding for lots of implementations
… that what I ment by external
<Zakim> gibsonf, you wanted to weigh in on implentation effects
gibsonf1: wtith RDF on the server we cash things
… we use the authorisation with cashing mechanisms
… it may be very difficult to handle this at scale
uvdsl: can you be more specific wrt the scope of the protocol
acoburn: authorization is very much in scope of the protocol
… but how we scope it?
… are we going to scope it to a particular way of getting authorization?
<ericP> i think "auth out of scope" means "auth *control* is out of scope", i.e. the mechanism for setting authorizations won't be portable between systems
acoburn: if we define one thing, how we compare to another way
uvdsl: there are 2 questions, do we choose a specific policy solution?
… and if the authorization server and the resource server are distinct, what alternative to them being coupled ?
… I am thinking at how it work with Solid and how this is handled in different ways
acoburn: the 2 entities could coexist may do not necesssarily have to
<Zakim> gibsonf, you wanted to ask what are the things WAC just cant do?
gibsonf1: you may want to couple the 2 if in your pod some data is used for authorization
… if decoupled, it would be more difficult to understand what's going on in the pod
… what WAC cannot do that other protocols can do?
acoburn: one answer is WAC can do anything you want
… but maybe undermining interoperability
… it cannot do time based access control
… on its own
… so you need something on top that's not interoperable
… or you can't do consent based access by itself
… also with 1000000 of users,
… things start to slow down much
… from the top of my head, and then more things
gibsonf1: you could have something like one emply puts the WebId and that works for the whole company employees
acoburn: imagine you need the doctor to access one's health data
… the doctor could delegate access
… but the others cannot delegate again
Beau: we talked about WAC and access control policy
… WAC can define groups and user agents but cannot define fine grained policies
… you can do it with a policy language
<Beau> https://
Beau: Solid can use ACP instead of WAC
acoburn: and there are things ACP can't do and WAC can
uvdsl: these conversations about WAC can and can't do happened already in the Solid CG
… in fact some things re. ACP are not done by ACP per se but by Inrupt's implementation
acoburn: having a particular policy language is one appraoch
… there are other appraoches
… what are the tradeoffs of all the appraoches
<uvdsl> To add what I wanted to raise for the protocol: If we acknowledge that WAC is incomplete, why are we not considering to extend/modfiy WAC?