Meeting minutes
Introductions & Announcements
laurens: We start with introductions and announcement
… one announcement coming from Aaron on TPAC
acoburn: TPAC is the annual W3C event for WGs and CGs
… great opportunity for meeting in person
… This year in Dublin, Ireland from October 26th to October 30th
<acoburn> TPAC
<acoburn> Scholarship fund
acoburn: At the location in chat, invited experts can apply for funding
… There will be a joint meeting with the CG
… There will be a survey/workshop about identity on the Web
<Zakim> elf-pavlik, you wanted to clarify IE fund requirements
<jeswr> note that joint sessions will be on the Friday in times booked by the CG
elf-pavlik: One has to be invited expert for half a year AND be an editor to apply
bigbluehat: Pavlik please go ahead and submit; it never hurts, it's worth a shot
… Also, the JSON-LD WG is not meeting at TPAC this year, but if we want a short joint session, we can make something work
acoburn: We do have some questions regarding equivalence with JSON/JSON-LD, so there are definitely areas where some feedback would be handy
<Zakim> elf-pavlik, you wanted to make a comment on JSON-LD
elf-pavlik: It would be good to have a reference for when compaction is enough, and when we should start framing
bigbluehat: The line is not always clear, but we can try to sketch something up
Vote: Integrate core notification data model into lws10-core (PR #185 - https://github.com/w3c/lws-protocol/pull/185 )
bigbluehat: we meet at Wednesday at noon Eastern Standard Time
laurens: Next up is a PR discussed last week to integrate core notification model into the core document
… There are some vocabulary items that still need a fix; I'll do that in a separate PR
… This would align with how authentication is currently integrated in core with references to each suite
… I propose we move this to a vote today
<Zakim> elf-pavlik, you wanted to ask about normative references / dependencies strategy for subscription types
elf-pavlik: Looks good to me; just want to clarify that every suite now has to have toe core LWS spec as normative reference
laurens: that is correct
<laurens> PROPOSAL: to accept the pull request #185 as proposed
<gb> Pull Request 185 Integrate core notification data model into lws10-core (by laurensdeb)
<elf-pavlik> +1
<termontwouter> +1
<laurens> +1
<jeremycaine> +1
<gibsonf1> +1
<ryey> +1
<acoburn> +1 (with the expectation that the vocab refs will be fixed)
<eBremer> +1
RESOLUTION: to accept the pull request #185 as proposed
laurens: I will merge this later today and open a second PR for the vocabulary
Discuss: Define Storage Description Resources as a specialization of CID-1.0 (PR #183 - https://github.com/w3c/lws-protocol/pull/183 )
laurens: Next agenda item is the storage descriptions as CIDs
acoburn: Pavlik asked a good question about the id field last week
… I looked into it and it is indeed complicated
… I urge everyone to look at the discussion on github
… First option is to simply not use a CID, but then we would basically reinvent a lot of vocabulary
… In december, we concluded that the subject of this document should be the storage, not the storage description
… so if it is a CID, and the ID is that of the storage, then the CID needs to be served from the URI of the storage
… This entails that we probably won't be able to use the storage as a storage root without problems
Second option is therefore to split the root from the storage
Third option is to let the storage description describe itself, going against our conclusion of December
gibsonf1: Can content negotiation be a solution?
acoburn: I looked into it, and won't outright reject it, but it gets messy
… because there would be different access control for different sets of triples
<Zakim> gibsonf, you wanted to ask about option 2
gibsonf1: So in option 2, we would use the CID accept header?
acoburn: Indeed, we would use it, but it does not say anything about content negotiation
… we can discuss this further offline
<Zakim> elf-pavlik, you wanted to ask besides compatibility with prior work in Solid, what is the main use case for having storage and root container conflated?
elf-pavlik: If we say that storage and root need to be different, this would be a breaking change w.r.t. Solid
… What are the main use cases that would break specifically?
acoburn: Within LWS nothing in particular
… Compared to Solid, where the storage IS the root container, the storage would now serve the CID document, from which the roots would be referenced
elf-pavlik: Would it be an option to have the storage URI be within the namespace of the root?
acoburn: Then resources in that storage would no longer necessarily be within the namespace of the storage
… unless you wold put all resources inside the namespace of the storage (description), never next to it
elf-pavlik: I think there are more options to consider, but will add some snippets to the discussion
Discuss: Add introduction section (#158 - https://github.com/w3c/lws-protocol/pull/158 )
laurens: Let's move to the next item, which is about the introduction PR
jeremycaine: I added new terms, and diagrams, and edited them a few times based on feedback
… so it is probably ready for a vote by next meeting, especially since we can iterate on it
gibsonf1: I feel like the "interface to the resource manager" does not need the 'interface' part
… why not call it storage manager?
jeremycaine: I'm not married to any names, but I felt that it is about more than just the data resource?
<Zakim> acoburn, you wanted to mention certain terminology
acoburn: We want to keep this pretty high-level in the introduction
… You mention users a number of times instead of agents, but this might be too specific given the state of the web
… We should also avoid nuances about how an implementation might work
… The important part is about the use cases, who might be using this etc. on which you did a great job.
jeremycaine: So we cannot assume that the entity interacting with LWS is a human?
acoburn: No, I would not specify it, but leave it open
<elf-pavlik> see https://
jeremycaine: We need to discuss this, since I don't think we have the same opinion about this
laurens: I think we indeed need to reiterate on the terminology a bit
<Zakim> elf-pavlik, you wanted to mention user/agent != resource owner
laurens: for example, a user could also be a group or organization
elf-pavlik: When talking about users, we often mean the end-user, but sometimes also the resource owner ...
… and there is the question of whether an AI agent can bear any legal responsibility towards its interactions
… so I think we need to add some more nuance to the conformance section
jeremycaine: So far we got the LWS client defined, but it would be simpler if the scope was merely the LWS server, and the client could be simply anything interacting with it.
… So shall we have a bit more debate in the PR?
laurens: yes
<Zakim> elf-pavlik, you wanted to dive into conformance classes
laurens: everyone is encouraged to provide feedback, so hopefully we can vote on it next week
elf-pavlik: It does not have to be perfect and complete in this PR
… We need to work on the component classes (for example the IDP as well) in the conformance section more explicitly
… LWS server and LWS client might be too generic
jeremycaine: I feel like LWS client stays, then the user has to be human
jeswr: I think we need agent in that section
… Apart from traditional scenarios with a human users, there also will be interaction with LWS servers by agentic AI systems
… In this context, the user can be a human but also some other software-based agent operating on behalf of a human
… Which I would not consider a client, but rather think of it as a secretary acting on my behalf
jeremycaine: I understand, but the LWS specifies requests and responses
jeswr: About users, in a typical interaction the browser is the client
… but in an agentic session the client might be an AI agent instead
jeremycaine: Do we need any specific terminology for this?
jeswr: yes
laurens: yes, the distinction might be about an MCP client interacting as LWS client
<elf-pavlik> +1 to separate
<acoburn> https://
acoburn: We already have agent terminology in the current published draft
<Zakim> elf-pavlik, you wanted to ask jeswr which normative statements would have that Agent as subject
laurens: I think we need to merge main to this PR first
elf-pavlik: I would suggest not to aim for perfection
… the PR already makes several improvements
… if anything changes later, we can still update the diagrams later
… @jeswr, would there be specific tests for AI agents?
jeswr: We don't have tests for users, so no; we only have tests for clients
… We should take into account in the test that the user's ID can either be the same or different from that of the client
elf-pavlik: There are possible cases where the server can act as a client
<elf-pavlik> e.g., to access protected group listing when enforcing access based on that list
laurens: In the interest of time, I would encourage everyone to add feedback to this PR, once it is up to date with the main branch
Discuss: Consolidate ConNeg requirements into the LWS Media Type Section (#190 - https://github.com/w3c/lws-protocol/pull/190 )
laurens: Let's jump to the next agenda item about conneg consolidation
eBremer: @acoburn made the comment that this is not really about content negotiation
… Can people chime in on that?
laurens: Let's do that by next week
… Given the time, let's close off
Github Issue Triage
acoburn: Thank you everyone for attending the Friday triage meetings
… For those issues with the 'proposed-close' label, please make a comment on them by the end of the week
<TallTed> https://