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