Meeting minutes
Introductions & Announcements
laurens: the holiday season is around the corner
… our proposal is to cancel the last two meetings of December (22nd and 29th)
<AZ> +1 to cancel 22nd Dec. 2025 meeting
laurens: unless someone has an objection?
<gibsonf1> +1
<ericP> +1
laurens: 15 Dec would be our last meeting of the year.
<acoburn> +1
<eBremer> +1 to cancel
<pchampin> +1
laurens: hearing no objection, we will update the calendar accordingly.
… 2nd item is an upcoming F2F meeting.
jeswr: I have reserved rooms in London for the last week of April,
… the Solid Symposium is on the end of that same week, so I expect many people will be around anyway
… also a Solid hackathon in the same week
laurens: let us know if you have issues with this schedule, but it seemed to make sense
<eBremer> w3c/
<gb> Pull Request 37 Initial CRUD with proposed metadata handling (by ebremer)
eBremer: I made a PR (link above). I would appreciate feedback.
acoburn: eBremer, it would be good to give people a rough timeframe for the feedback.
<Zakim> acoburn, you wanted to ask about timeframe
eBremer: I'd like to be done with it in the next two weeks
pchampin: There was some discussion in the past meetings on json-ld and framing
… I attended a French conference last week with a demo of a static web page generated from an RDF knowledge graph
… this was using framing to generate JSON-LD.
… That could be one example of the use of framing.
ericP: interesting, links to the use-case about generating a website from a LWS storage
Resource containment: Next steps
laurens: we had productive discussions on that topic in the last weeks
… it would be time to draft a PR based on these discussions
… I will try to set up an initial draft text this week, welcoming other people
… I would like to shift focus on other PRs that we have about AuthN and AuthZ
… Feel free to raise any issue you have on resource containment, now or on the upcoming PR
gibsonf1: on containers, I don't think we should have a media-type, only a type
… following the Linked Data approach
laurens: yes, I have noted that we need to have this conversation
… let's continue it on the PR
<laurens> w3c/
<gb> Pull Request 43 LWS Authentication (by acoburn)
<Zakim> gibsonf, you wanted to ask containment
<gibsonf1> no question here
LWS Authentication ( PR #43 )
acoburn: this is a collaborative effort with jeswr
… regarding the timeframe of this PR and the next one.
… jeswr mentioned a planned F2F in April.
… Ideally we can move into CR by that time.
… Working backward from that, we have a lot of work, and AuthN and AuthZ are a large part of it.
… AuthN/AuthZ exist in the input documents that we have (Solid, Fedora).
… The goal is to try and have this PR approved by the group by the 15th.
… Let's talk through the details, identify sticky points.
… A number of folks have already read through the PR, thanks to them.
… Currently, Solid has Solid OIDC which is great if you are using a web browser, not so much if you are not.
… AuthN is a moving target on the Web. Depends a lot of the context (app? pod? agent?)
… Having one single way of authenticating is not realistic.
… The basic approach that we have laid out here is an abstract notion of the kinds of claims made in AuthN,
… and what needs to happen for validating those claims.
… That way we can have a set of authn suites; one could be OIDC-based, another could be DID-based, another SAML-based...
… What Solid does could be done here, but other things currently harder in Solid could also be done.
… SAML is a very different technology stack, we want to make sure it is possible to use it.
… The claims have to do with a subject ID, an issuer ID and a client ID.
… Those IDs are required to be URIs (a SHOULD, re. the client ID).
… Otherwise, the actual mechanics will be defined in individual suites.
pchampin: elf-pavlik asks on IRC how this pluralism will be handled by the test suite
acoburn: fair question
… a user knows how which system they want to authenticate
… or a client will direct the user into using a certain system
… that's how it works today in Solid, and how it will continue to work.
… Re. the testuite, it will need a mechanism by which it says "use this authn mechanism in order to bootstrap yourself into testing your app"
… I suspect it will use OIDC or client credential.
… To move beyond CR, we will need 2 independent implementations anyway.
… We will need some coordination btw implementation, test suite and spec. They will have to move together.
acoburn: another point: Solid currently makes heavy use of WebID.
… WebID does not appear in the PR, because WebID is only a draft from a CG that does not exist anymore.
… It is not moving forward.
… Our choices are to adopt WebID and move it forward ourselves (but we already have a lot to do),
… or to adopt existing standard technologies which we can reference.
… Where Solid used WebID profile documents, the PR uses CID documents.
https://
… basically, CID document provide the same kind of information.
… Also, another group could theoretically write an authentication suite independent of the WG, one that would use WebID.
… We don't use WebID but the approach is very much inspired by WebID.
ryey: I'm not familiar with CID; I assume that it is similar to OIDC @@. Is it a JSON document?
<laurens> https://
acoburn: it is a JSON-LD document, with media-type application/cid
… It uses a particular frame.
… One thing that a CID document is often used for is authentication.
… So it fits very well with this PR.
ryey: good to know. Are there any compulsory field that we would be force to use?
acoburn: nothing beyond the id field, which we need anyway.
ryey: I assume we can use our own vocabulary, as it is JSON-LD.
acoburn: there is a notion of "service endpoint", for which we would need to define a type.
<gibsonf1> +1 on CID
pchampin: (more context on the genealogy of CID documents, and the minimization of information to avoid linkability of different identities)
<gb> Pull Request 43 LWS Authentication (by acoburn)
<gibsonf1> agent credential?
acoburn: about terminology, we used "end-user credential"
… it is defined in OIDC
… I don't like that for a couple of reasons
… it implies that we are talking about a human users, which does not fit all our use-cases
… there is also the question of capability credentials vs. identity credentials
… I would prefer something like "agent credential" or simply "credential"; looking for guidance about that
<gibsonf1> +1 agent credential
acoburn: another goal that we had (in this PR and the AuthZ one) was to minimize the amount of things we invent
… AuthN and AuthZ are large topics, security-related
… boths PRs are mostly an alignment with existing protocols and mechanisms
… btw our charter says we should not reinvent the wheel in that space.
<pchampin> +1 to minimize what we invent
Roadmap discussion
laurens: as we have discussed before, we have a little less than one year ahead of us
… we have done quite a bit of work on use-cases and requirements
… the F2F meeting in Gent was productive in moving forward with the protocol
… we need people to take ownership of the different topics to make proposals that can be merged and discussed by the group
… Aside from the specification-oriented work, we will eventually need independent implementations of the protocol,
… so feedback from implementers on the feasibility of the spec is also important.
… Finally, we need a test-suite, and a threat model.
… The test-suite will be an important tool for demonstrating interoperability,
… it would be good to have someone responsible for it.
… The threat model is a requirement from our charter, this is how other WGs also address security considerations.
… Anyone craving to take the lead on a particular aspect?
<Zakim> acoburn, you wanted to ask about specific deliverables
acoburn: in Gent, we listed a number of deliverables
… authn/authz are in progress, see the open PRs
… core operations / basic CRUD is also in PR form by eBremer
… other things we discussed still don't have any PR: resource metadata, containment and storage metadata
… we talked about containment earlier today; those might be ready for an initial PR
… laurens mentioned he would make a proposal about containment metadata;
… resource metadata will be included in eBremer's PR;
… we still need someone for storage metadata.
… In Gent we also mentioned access request, there is a lot of discussion to be had on this.
… Laurens and myself volunteered to discuss this in January.
… Finally, notification and type index would need volunnteers.
… We don't need them today, but it would be good to have them by 15 Dec.
… Two names per item would be good, and a rough timeline.
laurens: it would make sense.
<Zakim> gibsonf, you wanted to ask about implementation vs testing
laurens: I would also like to have ideally two names for the test suite.
gibsonf1: on the implementation side, we are definitely interested.
… We'd be happy to cooperate with whoever takes the test suite, to be the 1st implementation to test against it.
laurens: to wrap up, we would like volunteers for storage metadata, notification, type indexes
… please step forward by next week or the week after
<Zakim> gibsonf, you wanted to ask about type index
gibsonf1: for type index, is that the same thing as type query? What is a type index?
<ericP> gibsonf1, give me a shout on Signal to see if we can hack up a strawman test suite
laurens: historically, in the Solid context, type indexes can be thought as a dictionary that lives in your pod,
… referencing resource that comply with a given type.
<ericP> (but after new years)
laurens: We discussed this briefly in the F2F in Gent.
… We described it as a source for resource discoverability, but would not necessarily match the current Solid type index.
acoburn: the key difference being: in Solid, the type index is currently client-managed.
… for the server, it is just like any other resource.
… Malicious application can corrupt that data.
… What we discussed is a server-managed type index, with very limited capabilities.
… Could not be corrupted by a single client, server could manage access control.
gibsonf1: is it possible to make a list of the minimal requirements?
… I agree about server-based, but that's not enough.
laurens: we are actually expecting someone to propose those minimal requirements.
gibsonf1: I'd like to do it.
laurens: great, having a 2nd name would still be good.
… action to the group: consider volunteering to one of these topics.
… Next week we will be discussing authorization.
<acoburn> w3c/
<ryey> Would be interested to cooperate with gibsonf1 for the minimal requirements
<gb> Pull Request 45 LWS Authorization (by acoburn)
laurens: AOB?