13:56:41 <RRSAgent> RRSAgent has joined #lws
13:56:45 <RRSAgent> logging to https://www.w3.org/2026/08/31-lws-irc
13:56:45 <Zakim> inviting RRSAgent
13:56:45 <Zakim> RRSAgent, make logs Public
13:56:46 <Zakim> please title this meeting ("meeting: ..."), laurens
13:56:48 <agendabot> agenda+ Discussion: Moving resources between containers -> issue#148 https://github.com/w3c/lws-protocol/issues/148
13:56:49 <agendabot> agenda+ Discussion: Test suite task force -> action#232 https://github.com/w3c/lws-protocol/issues/232
13:56:52 <agendabot> agenda+ Discussion: Implementation feedback and implementation report
13:56:54 <laurens> meeting: LWS WG Meeting - August 31st, 2026
13:57:46 <TallTed> TallTed has joined #lws
13:58:52 <eBremer> eBremer has joined #lws
14:00:04 <laurens> chair: laurens
14:02:17 <elf-pavlik> elf-pavlik has joined #lws
14:04:30 <termontwouter> termontwouter has joined #lws
14:04:50 <pchampin> scribe+
14:04:59 <elf-pavlik> present+
14:05:14 <laurens> present+
14:05:31 <AZ> AZ has joined #lws
14:05:33 <eBremer> present+
14:05:35 <AZ> present+
14:05:49 <TallTed> present+
14:06:10 <laurens> zakim, take up agendum 1
14:06:10 <Zakim> agendum 1 -- Introduction and announcements -- taken up [from agendabot]
14:06:12 <RRSAgent> I have made the request to generate https://www.w3.org/2026/08/31-lws-minutes.html TallTed
14:06:24 <pchampin> present+
14:06:32 <ericP> ericP has joined #lws
14:06:38 <ericP> present+
14:06:47 <pchampin> laurens: September 7 is labor day in the US, so we decided to cancel the meeting.
14:06:48 <jeswr> jeswr has joined #lws
14:07:12 <pchampin> ... Note that today is a public holiday on the UK, but we seem to have a quorum though.
14:07:38 <ryey> ryey has joined #lws
14:07:44 <ryey> present+
14:08:01 <pchampin> pchampin: no green light for the charter extension yet, should come soon
14:08:10 <termontwouter> present+
14:08:20 <laurens> zakim, take up agendum 2
14:08:20 <Zakim> agendum 2 -- Vote: Add subject_identifier_types_supported to AS metadata -> PR#227 https://github.com/w3c/lws-protocol/pull/227 -- taken up [from agendabot]
14:08:20 <pchampin> laurens: the meeting recurrence stops after this meeting, but expect it to resume on the same slot from September 14
14:08:57 <pchampin> laurens: this PR extends the authorization server metadat with 2 properties
14:09:20 <pchampin> ... subject_token_type_supported specifies which kind of tokens the server supports
14:09:23 <termontwouter> q+ to ask about reuse
14:10:05 <pchampin> ... subject_identifier_types_supported has changed names a couple of times, and is about the schemes or other kinds of subject identifiers supported by the server
14:10:54 <pchampin> ... did can have different methods, e.g. did:key: or did:web: ; this allows an authorization server to specify which methods they support,
14:11:01 <pchampin> ... as well as other URI schemes (e.g. https:)
14:11:19 <elf-pavlik> q+ to  propose merge, new issue and followup pr
14:11:21 <pchampin> ... we discussed this PR before; any outstanding concerns?
14:11:35 <elf-pavlik> q?
14:11:36 <laurens> q?
14:11:39 <laurens> ack termontwouter
14:11:39 <Zakim> termontwouter, you wanted to ask about reuse
14:12:11 <pchampin> termontwouter: I agree with the need to include this kind of metadata
14:12:25 <pchampin> ... but it occurred to me this morning that other approaches exist for that. Why don't we reuse those?
14:12:49 <pchampin> laurens: indeed, other mechanisms exist to advertise subject identifiers types or schemes,
14:13:21 <pchampin> ... but I'm not sure they apply here.
14:13:42 <pchampin> ...  For example, OpenID connect's approach would imply the use of other part of OpenID connect which we do not use.
14:14:07 <pchampin> ... Similar concerns apply to GNAP.
14:14:39 <pchampin> ... I agree that some parts of the Authorization section are somewhat orthogonal to our specification, see issue w3c/lws-protocol#178 .
14:14:39 <gb> https://github.com/w3c/lws-protocol/issues/178 -> Issue 178 Orthogonality of specifications (by namedgraph)
14:15:16 <laurens> ack elf-pavlik
14:15:16 <Zakim> elf-pavlik, you wanted to propose merge, new issue and followup pr
14:15:43 <pchampin> elf-pavlik: the issue was open in April, I believe, and we have rough consensus,
14:15:45 <termontwouter> q+
14:15:55 <pchampin> ... so I suggest we merge this and open an issue to adjust it.
14:16:01 <ericP> +1 to merge this one
14:16:14 <laurens> ack termontwouter
14:16:15 <pchampin> ... better than trying to get perfection in the first PR.
14:16:25 <pchampin> termontwouter: I totally agree with this approach.
14:16:49 <pchampin> ... But I don't agree that none of the supplied references are usable in our context.
14:17:20 <pchampin> ... I think that RFC9493 defines token types.
14:17:30 <elf-pavlik> i'm happy to participate in the followup to identify better reuse
14:17:53 <pchampin> laurens: and we are using it for subject_token_types_supported. This is different from subject_identifier_types_supported
14:18:04 <laurens> q?
14:18:28 <laurens> PROPOSAL: Merge the PR adding the subject_identifier_types_supported property to the Authorization Server Metadata at https://github.com/w3c/lws-protocol/pull/227
14:18:29 <ericP> +1
14:18:29 <gb> https://github.com/w3c/lws-protocol/pull/227 -> PR 227 Add subject_identifier_types_supported property to AS Metadata (by acoburn) [authorization] [authentication]
14:18:32 <pchampin> +1
14:18:36 <elf-pavlik> +1
14:18:36 <laurens> +1
14:18:37 <termontwouter> 0
14:18:37 <eBremer> +1
14:18:39 <TallTed> +1
14:18:57 <laurens> RESOLVED: Merge the PR adding the subject_identifier_types_supported property to the Authorization Server Metadata at https://github.com/w3c/lws-protocol/pull/227
14:19:08 <elf-pavlik> q+ to ask about changelog in the spec
14:19:14 <laurens> ack elf-pavlik
14:19:14 <Zakim> elf-pavlik, you wanted to ask about changelog in the spec
14:19:36 <pchampin> elf-pavlik: people are already implementing things, so having something is better than nothing
14:19:54 <termontwouter> +1 for listing merged changes
14:20:10 <elf-pavlik> ai written :)
14:20:11 <pchampin> ... understanding that this is workding draft, so subject to change, so having some kind of change log would be useful
14:20:20 <pchampin> q+
14:20:25 <laurens> ack pchampin
14:20:57 <laurens> scribe+
14:21:15 <laurens> pchampin: I might have a solution
14:21:47 <laurens> ... You might be familiar with the history link in the specification documents.
14:22:18 <laurens> ... Another tool like htmldiff could help you create diffs but that is tedious.
14:23:07 <laurens> ... I have set up a user script which actually adds the htmldiff links to the history page for the specification as published by Echidna.
14:23:11 <elf-pavlik> q+ to ask taking advantage of https://www.w3.org/policies/process/#correction-classes
14:23:33 <laurens> ... I will share the user script via Gist for those interested.
14:23:36 <laurens> scribe-
14:23:38 <laurens> ack elf-pavlik
14:23:38 <Zakim> elf-pavlik, you wanted to ask taking advantage of https://www.w3.org/policies/process/#correction-classes
14:25:09 <pchampin> pchampin: my userscript adding diffs in the W3C history: https://gist.github.com/pchampin/5e69dacbc2018398fb6a593140e1d8c7#file-htmldiff_doc_links-user-js
14:25:22 <laurens> ACTION: laurensdeb to follow up on changelogs for the specification
14:25:25 <gb> Created -> action #239 https://github.com/w3c/lws-protocol/issues/239
14:25:39 <laurens> zakim, take up agendum 3
14:25:39 <Zakim> agendum 3 -- Vote: Clarify the ETag requirements and align with RFC 9110 -> PR#228 https://github.com/w3c/lws-protocol/pull/228 -- taken up [from agendabot]
14:26:12 <pchampin> laurens: we also discussed this PR a couple of times already
14:26:35 <pchampin> ... first the WG wanted to remove ETag requirements completely, but then we agreed that some form of concurrency control was needed as a baseline
14:26:48 <pchampin> ... this PR reflects that rough consensus, using ETags as this baseline concurrency control
14:27:08 <termontwouter> q+ to ask for summary of rationale
14:27:26 <pchampin> ... there are still a couple of consideration regarding containers that I believe are still insufficiently addressed
14:28:12 <pchampin> ... but this can be discussed later; such a baseline is needed to continue the conversation
14:28:16 <laurens> ack termontwouter
14:28:16 <Zakim> termontwouter, you wanted to ask for summary of rationale
14:28:44 <pchampin> termontwouter: I don't have strong opinion on whether this should or should not be included,
14:29:05 <pchampin> ... but the change of direction seems sudden to me.
14:29:44 <pchampin> laurens: the change did not just happen in the PR itself; the shift of consensus occurrend during a couple of previous meetings
14:30:21 <pchampin> ... it was raised that without such a mechanism, interoperability for some use-cases was not assured
14:30:43 <elf-pavlik> q+ to mention demand for 'deep' last modified in Solid CG
14:30:49 <pchampin> ... I don't know if others that were on the previous calls want to add something?
14:30:52 <laurens> ack elf-pavlik
14:30:52 <Zakim> elf-pavlik, you wanted to mention demand for 'deep' last modified in Solid CG
14:30:59 <pchampin> termontwouter: that summary is good enough for me
14:31:08 <ericP> ericP has joined #lws
14:31:50 <pchampin> elf-pavlik: I'm favourable to merge this PR,
14:31:57 <laurens> q?
14:32:09 <pchampin> ... but there seem to be a demand, including from the CG, to be able to keep track of changes of a whole subtree of the container hierarchy
14:32:29 <pchampin> laurens: I'll open an action to record this requirement
14:32:33 <laurens> q?
14:32:46 <laurens> PROPOSAL: Merge the PR establishing a baseline ETag requirement (MUST) for LWS resource types at https://github.com/w3c/lws-protocol/pull/228
14:32:46 <gb> https://github.com/w3c/lws-protocol/pull/228 -> PR 228 Clarify specific ETag requirements and align with RFC 9110 (by acoburn)
14:32:47 <elf-pavlik> +1
14:32:48 <termontwouter> +1
14:32:53 <pchampin> +1
14:32:56 <laurens> +1
14:32:56 <eBremer> +1
14:33:01 <ericP> +1
14:33:19 <laurens> RESOLVED: Merge the PR establishing a baseline ETag requirement (MUST) for LWS resource types at https://github.com/w3c/lws-protocol/pull/228
14:33:29 <TallTed> +1
14:33:46 <ryey> +1
14:33:57 <laurens> ACTION: @laurensdeb to clarify ETag requirements for Containers (recursively)
14:33:59 <gb> Created -> action #240 https://github.com/w3c/lws-protocol/issues/240
14:34:25 <laurens> zakim, take up agendum 4
14:34:25 <Zakim> agendum 4 -- Discussion: Clarify DID support in the SSI-CID authentication suite -> PR#233 https://github.com/w3c/lws-protocol/pull/233 -- taken up [from agendabot]
14:34:43 <pchampin> laurens: some context for this PR:
14:35:14 <elf-pavlik> q+ to mention https://www.w3.org/TR/did-resolution/#conformance
14:35:56 <pchampin> ... in PR w3c/lws-protocol#229 we decided to discontinue the authn suite on did:key
14:35:57 <gb> https://github.com/w3c/lws-protocol/pull/229 -> PR 229 Discontinue authn-ssi-did-key (by pchampin)
14:36:32 <pchampin> ... because the authn suite on CID can supercede all DIDs (every DID document is also a CID document)
14:36:56 <pchampin> ... the consensus was to adjust the CID authn suite to clarify how it also applies to DIDs
14:37:20 <pchampin> ... Please review that PR.
14:37:45 <laurens> ack elf-pavlik
14:37:45 <Zakim> elf-pavlik, you wanted to mention https://www.w3.org/TR/did-resolution/#conformance
14:38:40 <pchampin> elf-pavlik: I suggest to copy over the snippet from the DID:key authn suite into the CID authn suite
14:39:13 <pchampin> ... as a non-normative example
14:39:24 <pchampin> laurens: I think we can include it
14:39:57 <pchampin> ... It would be good if we could vote on this in our next WG call.
14:41:08 <pchampin> elf-pavlik: see link above to the "DID Resolution" spec, which is updating the terminology on DIDs.
14:41:16 <pchampin> ... we need a DID expert to chime in on that spec.
14:41:27 <pchampin> q+
14:41:44 <pchampin> ... More generally, we could use CODEOWNERS on the different parts of the spec.
14:41:46 <laurens> ack pchampin
14:41:52 <laurens> scribe+
14:42:03 <laurens> pchampin: I'm staff contact on the DID WG.
14:42:08 <laurens> ... Not a DID expert though.
14:42:33 <laurens> ... Resolution is the process of converting a DID into a DID document.
14:42:57 <termontwouter> That's also my understanding of those terms
14:43:09 <laurens> scribe-
14:43:22 <laurens> q?
14:43:31 <pchampin> s/converting a DID into/getting from a DID
14:43:46 <laurens> zakim, take up agendum 5
14:43:46 <Zakim> agendum 5 -- Discussion: Add lws:StorageResource to the vocabulary -> PR#234 https://github.com/w3c/lws-protocol/pull/234 -- taken up [from agendabot]
14:43:53 <pchampin> ... Dereferencing is getting "something" from a DID URL (which is DID + path, query string, fragment)
14:44:59 <pchampin> ericP: this is a change of vocabulary about how we call resources
14:45:05 <pchampin> ... still a draft PR
14:45:11 <laurens> q?
14:45:22 <pchampin> s/ericP:/eBremer:
14:45:38 <laurens> zakim, take up agendum 6
14:45:38 <Zakim> agendum 6 -- Discussion: Moving resources between containers -> issue#148 https://github.com/w3c/lws-protocol/issues/148 -- taken up [from agendabot]
14:45:40 <pchampin> laurens: please review, we will bring it up in the agenda of the next WG meeting
14:46:35 <pchampin> laurens: we haved discussed for a while the notion of multiple containment, then decided to drop this from the spec
14:46:37 <laurens> https://github.com/w3c/lws-protocol/pull/237
14:46:37 <gb> https://github.com/w3c/lws-protocol/pull/237 -> PR 237 Define how resources move between containers (by laurensdeb)
14:46:47 <pchampin> ... this draft PR saves one feature of the "multi-containment" proposal,
14:47:11 <pchampin> ... which is the ability to move a resource from one container to another in one operation (PATCH to the linkset of the resource to be moved)
14:47:23 <pchampin> ... by modifying the 'up' relation of the resource
14:47:42 <elf-pavlik> q+ to clarify the need for "server MUST do what it advertises in the related capability"
14:48:05 <pchampin> ... There are a couple of aspects: the 'up' is server-managed, so a way to advertise the capability to update it is required.
14:48:52 <pchampin> ... There might be a better way of advertising it than what is in the PR.
14:49:25 <pchampin> ... Other consideration include the impact on totalItems, ETag, and the need to check whether cycles are created
14:49:50 <pchampin> ... I'm not sure how we should reflect that in the Security & Privacy Considerations sections, given this is an optional feature.
14:50:19 <pchampin> ... Implementers should chose whether this operation is available only on simple resources, or also on containers.
14:51:13 <pchampin> ... Most changes are in the 'Storage Capabilities'.
14:52:46 <pchampin> ... a 'MetadataUpdate' capability has attributes 'modifiable' (which metadata relation are concerned), 'appliesTo' (all resources, only data resources...)
14:53:09 <pchampin> ... 'preservesIdentifier' seems required, but I would like to discuss this with the WG.
14:53:43 <laurens> q?
14:53:48 <laurens> ack elf-pavlik
14:53:48 <Zakim> elf-pavlik, you wanted to clarify the need for "server MUST do what it advertises in the related capability"
14:54:02 <pchampin> ... See also section ç;- 'Moving resources between containers'
14:54:04 <jeswr> jeswr has joined #lws
14:54:09 <jeswr> q+
14:54:16 <pchampin> elf-pavlik: thanks for this PR, I was looking forward to them.
14:54:29 <pchampin> ... I think we need a clear map between capabilities and normative text.
14:54:41 <pchampin> ... If you advertise that, then you MUST do this.
14:55:05 <termontwouter> +1 to explicitly tie capabilities to conformance
14:55:16 <laurens> ack jeswr
14:55:17 <pchampin> ... This goes beyond this PR, that should be a consistent pattern in the spec.
14:55:19 <pchampin> jeswr
14:55:35 <termontwouter> q+ to point out https://github.com/w3c/lws-protocol/issues/238 and agree on preserveIdentifier
14:55:52 <pchampin> s/jeswr/jeswr: possibly a naive question (I have not had time to review it in details);
14:56:13 <pchampin> ... for an implementation using slash-semantics, is there a way to specify the URL of the new location?
14:56:16 <elf-pavlik> q+ to request addressing issue about slashes in examples (by jeswr) before landing this PR
14:56:42 <pchampin> laurens: the examples show how the server conveys the new identifier;
14:57:03 <pchampin> ... I would expect the 'preservedIdentifier' flag to be false for an implementation with slash-semantics,
14:57:26 <pchampin> ... but again, I would like to discuss this flag with the froup
14:57:29 <pchampin> s/froup/group
14:57:48 <pchampin> jeswr: ok, so the server dictates whether the identifier changes or not
14:58:45 <pchampin> s/the new identifier/the new up relation
14:58:57 <laurens> ack termontwouter
14:58:57 <Zakim> termontwouter, you wanted to point out https://github.com/w3c/lws-protocol/issues/238 and agree on preserveIdentifier
14:58:59 <pchampin> ... but how can the client know the new identifier?
14:59:14 <pchampin> laurens: this is a good point, probably a Location header in the response would be needed
14:59:37 <laurens> ack elf-pavlik
14:59:37 <Zakim> elf-pavlik, you wanted to request addressing issue about slashes in examples (by jeswr) before landing this PR
14:59:59 <pchampin> termontwouter: there may be a link between the preservesIdentifier flag and w3c/lws-protocol#238
14:59:59 <gb> https://github.com/w3c/lws-protocol/issues/238 -> Issue 238 Extensibility of metadata categories (by termontwouter)
15:00:50 <pchampin> elf-pavlik: examples based on slash-semantics are confusing; we need to rebase this PR, then fix the examples
15:01:09 <pchampin> laurens: we are at the top of the hour; recall that next week's meeting is cancelled
15:01:26 <pchampin> ... we reconvene on September 14 same time, you should see this appear in the W3C calendar soon
15:01:34 <pchampin> RRSAgent, make minutes
15:01:36 <RRSAgent> I have made the request to generate https://www.w3.org/2026/08/31-lws-minutes.html pchampin