Meeting minutes
<gb> Issue 16 Agenda: 2026-03-10 (by simoneonofri)
<pchampin> yes, 2 more weeks; back to "normal" on 30 March (at least for us in Europe)
Introduction and announcements
acoburn: Any announcements? Or changes in affiliation?
jeswr: We have a face-to-face meeting taking place on April 27th and 28th at the ODI Offices near Kings Place in London.
… We also have the Solid symposium on April 30th and May 1st.
… Finally, there is also a Solid hackathon that week.
acoburn: Jesse is encouraging everyone in the community to block out April 27th through May 1st.
Issue triage
acoburn: There is one new issue to discuss.
… Issue #95 in the lws-protocol repository.
<gb> Issue 95 Specify Container representation to be compound representation (by damooo)
acoburn: It asks a container to be specified as both a sever-managed and user-managed resource.
… I believe from the F2F that containers would be server managed data.
… I don't think we were going to specify it as being compound.
… Is #95 out of-scope for LWS or not?
gibsonf1: If a client makes an RDF request on a container would they receive everything?
acoburn: Right now containers are defined as including information on all contained resources.
<jeswr> LWS in-person meeting (Location ODI Offices, Kings Place, Kings Cross, London): April 27 - April 28
<jeswr> ODI Hackathon (pre-registration at https://
<jeswr> Solid Symposium (https://
acoburn: Let's say in addition you want to add a name and other data to the container.
… At present that would not go into the container resource itself but into an auxiliary resource.
gibsonf1: So a standard GET on a container will not return basics about that resource?
acoburn: Think of a container like a folder in a filesystem.
… When you perform a GET you receive a list in the body of the resources contained in that container.
… That is what we define today as part of the representation.
gibsonf1: That is a real problem.
… If I perform a GET on a container, that returns a JSON with the content of the container.
acoburn: Currently you get a JSON response with the container contents and minimal metadata.
… Additionally there is a linkset resource associated with the container.
… Which can contain user defined and server defined link relations.
… To e.g. auxiliary resources. So the linkset allows for arbitrary (with some constraints) links to other resources.
gibsonf1: This breaks the Solid approach to getting RDF on a resource GET.
… In our case a container could be a system that contains other systems.
acoburn: Currently we are only triaging this issue. So we should probably assign a "needs-discussion" label here.
gibsonf1: There is an Accept that you send on the GET request.
acoburn: That is part of HTTP.
… We require that a server support a specific mediatype (application/lws+json).
… A server may do content negotiation on that resource.
Timeframe for FPWD
acoburn: Typically specifications start with an editor's draft.
… And after some time you move into a first public working draft.
… It is a signal that (while still being a draft) it is a publication which begins a process
… of patent exclusion
… If there is IP in the draft exclusion requests can be made. This starts at the FPWD.
… This process takes a couple of months.
… Our charter expires in September, so we want to finish this patent exclusion process before that.
… We are probably going to need an extension anyway, but it would be good to move along to FPWD.
pchampin: A first public working draft is still a draft.
… We shouldn't be shy or wait for the content of the specification to be more mature.
… Some groups publish an empty FPWD.
… Just to have a stake in the ground.
… We still need to improve a lot in the spec, but we should release early and often.
… It does not yet represent consensus of the WG other than consensus that we should put something out there.
… Our editor's draft is already visible today.
… But it does start this patent exclusion call.
acoburn: I have two resolutions ready, one on the core specification and one on the authentication suites.
<acoburn> PROPOSED: The LWS WG shall publish the FPWD of the core LWS specification
<laurens> +1
<Luke> +1
<pchampin> +1
<eBremer> +1
<acoburn> +1
<TallTed> +1
<dmitriz> +1
<ryey> +1
<gibsonf1> +1 (with small change to pagination pr)
<gibsonf1> Ahh, sorry +1
acoburn: It looks like we have solid consensus
RESOLUTION: The LWS WG shall publish the FPWD of the core LWS specification
<gb> Issue 16 Agenda: 2026-03-10 (by simoneonofri)
<acoburn> PROPOSED: The LWS WG shall publish the various authentication suites as FPWD documents
<gibsonf1> +1
<laurens> +1
<Luke> +1
<acoburn> +1
<pchampin> +1
<TallTed> +1
<bendm> +1
<acoburn> Core specification: https://
<acoburn> OpenID: https://
<acoburn> SAML: https://
<acoburn> SSI-CID: https://
<acoburn> SSI-DID-KEY: https://
<ryey> +1 (after fixing some seeming editorial issues?)
acoburn: We also have consensus for the authentication suites.
<eBremer> +!
<eBremer> +1
<acoburn> PROPOSED: The LWS WG shall publish the various authentication suites as FPWD documents: https://
RESOLUTION: The LWS WG shall publish the various authentication suites as FPWD documents: https://
Remaining priorities for WG: test suite, access requests, notifications, type index
acoburn: We have about 6 months left in the charter.
… We are very much interested in renewing the charter.
… We need to set priorities for both the next six months and think about what comes after.
… Probably after those six months the focus will be on implementation.
… But by September the contents of LWS should be mostly complete.
… We have a couple of things that haven't been taken up: test suite, access requests & grants, notifications, server-managed type index.
… Some other issues still need attention like pagination, multiple containment, ...
… But the foundation is already there for containment.
… However on these topics we haven't started working yet.
… Are these still the right priorities? Are we missing anything?
<gibsonf1> +1 on type search (and I can write a proposal up for it)
ryey: For test suites, do we test the server implementation? Or also the client?
acoburn: We are primarily specifying a protocol.
… Any entity for which we're specifying behaviour we would want to test.
<dmitriz> do we have a use case defined for type index?
acoburn: We're primarily focusing on server behaviour.
… So that will be our focus in testing. And will give the greatest benefit.
… But we could also have tests for client behaviour. But that might be more complicated.
<TallTed> "conformant by assertion"
acoburn: That's the test suite.
… I see gibsonf1 giving a +1 on type index.
… The main use case is data discovery.
… I don't have a specific reference, but we do have cases for that.
<Zakim> bendm, you wanted to state access request & grant is authorization server, and may be too far for the timeline, notifications seems manageable in the timeline, for server-managed type index I would suggest an extensible system (and happy to read gibsonf1's suggestion)
bendm: Test suite is something we must do.
… Access request & grant is related to authz service so farther from storage and thus less of a priority.
… Notifications seems manageable in the timeline.
… A server-managed type index will be hard to agree upon.
… So an extensible system will be needed.
gibsonf1: On the type index, I'm not thinking of it as a way of indexing things
… but as a search on types.
… A request would be one or more types which can be intersected.
acoburn: That would be great. As soon as we have a proposal we can discuss further.
… We will have to define the scope and requirements as a group.
… Please let one of the chairs know as soon as you have something ready.
… With respect to access requests & grants Inrupt is very interested.
… I could probably bring something to the group by next week.
<Zakim> ryey, you wanted to ask about "type" in type index and lack of RDF-native support
laurens: Access Requests & grants is very important still and resolves a severe lack of the solid protoocl.
ryey: I would agree on the access requests & grants.
… We are talking about type indexes, but as we've dropped the RDF support
… What do we mean by the type of a resource?
acoburn: This would probably be part of the scope of type indexes.
… In an LWS storage there will be both RDF and non-RDF resources.
How can we support as broad a category as possible.
… Types could be represented as part of the linkset.
<Zakim> bendm, you wanted to say we're also very interested in access request and grants, we can also bring something to collaborate on, I'm just wondering how large of a specification that will add to v1.0
bendm: Access requests & grants are super important.
… But it will be a new and big thing to add to the specification.
… So the question is how far we want to go.
… I might be wrong and it might be more straightforward.
… I just wonder if it wouldn't be better to scope ourselves.
acoburn: I have tried to keep this as minimal as possible.
… So the goal for access requests & grants would be to be as lightweight as we can.
bendm: I do think notifications are very important, as it allows for extensibility.
luke: The access requests & grants seems to be one of the most user unfriendly things that is in place right now.
… So it is important in terms of adoption to add this.
acoburn: I'm not hearing anything new.
… Only concerns on access requests & grants and their complexity.
… We need to make sure there are individuals in the WG actively working on these items.
<uvdsl> (sorry for joining just before the end :) )
acoburn: If anyone else wants to collaborate on access requests, let me know.
… gibsonf1 has indicated interest in working on type indexes. If anyone else is interested, get in touch.
… That leaves test suite and notifications.
<Zakim> dmitriz, you wanted to comment on test suite
acoburn: I am happy to contribute to notifications, but would be happy to have some assistance.
dmitriz: The test suite is a special case
… The W3C policy tends to strongly encourage multiple interoperable implementations.
… So it is an existential item to get anything out of the door.
jeswr: There is a grant from NLNet
… That has been granted to ODI for a test suite.
… That will be worked on.
acoburn: It would be wonderful if we have some collaboration on writing that test suite.
gibsonf1: There is a solid test suite group currently active
… Wouldn't it make sense to bring them in.
acoburn: They have a test suite written using Karate
… We could build on there work, so that would be great.
Web-CID Authentication Suite
acoburn: This PR proposes another authentication suite.
… uvdsl could you provide an introduction to this PR.
… So that we can discuss and vote on it next week.
uvdsl: This proposal is currently on agent identification, not authentication.
… As identification is a fundamental component of authentication.
<uvdsl> w3c/
<gb> https://github.com/w3c/lws-protocol/issues/57
uvdsl: Following #57 I was tasked to define a conformance profile on agent identification.
<gb> Issue 57 Agent Identification (by uvdsl) [ready-for-pr]
<uvdsl> https://
uvdsl: My approach is to define the mechanism for dereferencing a CID by a client.
… The specification should be implementable and lean.
… Such that it can be used in the existing authentication suites.
acoburn: I encourage everyone to look at this PR.
… With that we are out of time.
… Any last thoughts?