– DRAFT –
LWS WG Meeting - August 3rd, 2026

Introduction and announcements

laurens: intros and announcements
… rerchartering of the WG
… working on extension to bridge end of current charter which ends 9/8. PA will be doing initial effort

<termontwouter> anyone else has a lot of static on laurens' audio ?

acoburn: current thinking will be copy/paste of charter with diff dates of deliverables
… those are things we want to make sure we are aligned as a group
… during admin extension will go through AC vote / horizontal review
… we can then begin the new charter

laurens: any questions thoughts?

<termontwouter> better!

Vote: Threat Model document PR#202

laurens: are we ready to proceed to vote

ryey: vote on whether threat model should be part of specification

<Zakim> acoburn, you wanted to note typo in agenda proposal

acoburn: if you copy paste from agenda, please note typo

laurens: any further concerns before vote?

<laurens> PROPOSAL: Adopt Threat Model document from w3c/lws-protocol#202

<gb> PR 202 WIP: Add LWS threat model document (by renyuneyun) [security-privacy]

<elf-pavlik> +1

<gibsonf1> +1

<laurens> +1

<acoburn> +1

<eBremer> +1

<termontwouter> +1

<pchampin> +1

<TallTed> +1

<ryey> +1

RESOLUTION: Adopt Threat Model document from w3c/lws-protocol#202

<Zakim> elf-pavlik, you wanted to comment on next steps

elf-pavlik: is boiler plat to get us going
… go through privacy considerations documents
… iterative process putting time in each week
… get some feedback on the way we are doing it
… Ill be trying to help to get it moving

laurens: yes, starting point.

Vote: Content Negotiation requirements PR#190

eBremer: Mostly editorial changes.

PROPOSAL: Change content negotiation requirements and description as proposed in w3c/lws-protocol#190

<gb> PR 190 Consolidate ConNeg requirements into the LWS Media Type Section (by ebremer)

<gibsonf1> +1

<eBremer> +1

<termontwouter> +1

<laurens> +1

<acoburn> +1

<elf-pavlik> +1

<pchampin> +1

<rbreitman> 0

<ryey> +1

<TallTed> +0

RESOLUTION: Change content negotiation requirements and description as proposed in w3c/lws-protocol#190

<Zakim> elf-pavlik, you wanted to mention lack of fragmens in application/json

elf-pavlik: talked about equivalence between media types and application json doesnt specify fragments

elf-pavlik: leave no issue unless something comes up

laurens: leave it until it pops up elsewhere if that is okay with you

Vote: Add Access Request terms to Vocabulary PR#199

elf-pavlik: sounds good

acoburn: additive PR is just touching the vocabulary resource just adding terms

acoburn: but this pr just additive

termontwouter: there is a domain added to most of the terms and its always LWS access policy. that seems weird
… there's a one off statement for example with the left operand
… while in the spec edits the server must support all of these

acoburn: in terms of left operand, that a little bbit of a requirement for this YAML to vocab tooling that we use to produce this
… that contains other jsonld contexts its possible to have other values there. PA you are the expert on how this works
… value of a json-ld property is treated as a string rather than a URI

pchampin: what you describe is correct aaron. wouter's comment is more about the owl description

<termontwouter> That is indeed what I meant

pchampin: its more of a tooling problem we need to solve
… but we want the owl description to be more constraining that it is

ACTION: pchampin to discuss with Yvan on the use of oneOf in yml2vocab

<gb> Created action #215

<Zakim> elf-pavlik, you wanted to ask if rules from https://www.w3.org/2016/08/namespaces/ apply

pchampin: I will talk to ivan herman who is developing the YAML tool

elf-pavlik: are those vocabs drafts that working group can freely modify?

laurens: they are not recommendation track deliverables

pchampin: they are currently published on slash NS, pavlik you are right and need to double check not breaking any rules

<Zakim> acoburn, you wanted to ask about domain defns

<pchampin> also, those 2016 guidelines may be taken with a grain of salt; the management of /ns/ has evolved, especially since its migration to github

acoburn: wouter you mentioned this question about the domain

termontwouter: concernewd hjust like with the one-offs thaty is translated to lioke rdfs domains or all restrictions this would be wrong semantically

acoburn: allows you to create a context-dependent jsonld..
… the context will have those properties at the top level and sort of global
… creates adjacency context where those properties are only available within the context of an object that is type access

termonwouter: if we fix the domains that they are pointing at the correct entity

pchampin: maybe because of side effect we are out of trouble

<Zakim> acoburn, you wanted to mention that this is because of "external: true"

pchampin: leftover brand is a foreign property borrowwed from another vocabulary. Not to say tool doesnt need to be improved but we are okay here

acoburn: because external colon true property that we have in those cases. we dont define any of these terms in the total vocabulary

acoburn: during pr creation I think produced documents we all want
… lets revist the domain issue, but because external true it isnt affected by the issue wouter brought up

termontwouter: if tool updates, we need to make sure it continues to be correct

<laurens> PROPOSAL: Add terms from Access Request feature to LWS Vocabulary as in w3c/lws-protocol#199 and subsequently review whether the generated OWL artifacts match our expectations

<gb> PR 199 Add terms used by the Access Request feature (by acoburn) [vocabulary]

<elf-pavlik> +1

<gibsonf1> +1

<termontwouter> +1

<eBremer> +1

<pchampin> +1

<acoburn> +1

<laurens> +1

<TallTed> +1

RESOLUTION: Add terms from Access Request feature to LWS Vocabulary as in w3c/lws-protocol#199 and subsequently review whether the generated OWL artifacts match our expectations

Vote: Adjust JSON-LD Context section PR#187

acoburn: changed how context inlined so resemble sid or vc data model
… in order to address any kind of supply chain issues
… given context is in-flight, adding any value there it will become out-dated
… note at bottom suggested how production systems should treat json ld contexts

<laurens> PROPOSAL: Adjust JSON-LD Context section as in w3c/lws-protocol#187

<gb> PR 187 Rework JSON-LD context section (by acoburn) [editorial] [vocabulary]

<elf-pavlik> +1

<laurens> +1

<eBremer> +1

<acoburn> +1

<termontwouter> +1

<gibsonf1> +1

<TallTed> +1

<pchampin> +1

RESOLUTION: Adjust JSON-LD Context section as in w3c/lws-protocol#187

Vote: Privacy Considerations in Authentication Suites PR#206

ACTION: acoburn to create issue to add a content digest to the JSON-LD section

<gb> Created action #216

acoburn: privacy considerations sections were empty
… respec encountering failures because there were empty
… this is non-normative
… signed tokens such as id tokens or saml assertions are generally not encrypted
… ted you were finding your browser not rendering something properly...seems to be artifact of the preview system rather that w3c site

<Zakim> elf-pavlik, you wanted to ask if respec has some transclusion option, i recall two considerations in two suites were identical

tallted: correct. I have only seen in preview

elf-pavlik: two paragraphs identical in two documents, some how keep them in-sync
… idp tracking IPs of requests and verifiers

acoburn: documents all self-contain for simplicity. respec can load additional files but no longer self-contained
… would add a different level of complexity. not sure if it is worth it
… i agree. if we have in future it may be worth considering

laurens: i agree

<laurens> PROPOSAL: Add privacy considerations to authentication suites per w3c/lws-protocol#206

<gb> PR 206 Add privacy considerations to the authentication suites (by acoburn) [security-privacy]

<elf-pavlik> +1

<laurens> +1

<acoburn> +1

<gibsonf1> +1

<termontwouter> +1

<eBremer> +1

<ryey> +1

<TallTed> +1

<pchampin> +1

RESOLUTION: Add privacy considerations to authentication suites per w3c/lws-protocol#206

Vote: Remove ACL references PR#203

<termontwouter> +100

<laurens> PROPOSAL: Remove acl link header examples as in w3c/lws-protocol#203

<gb> PR 203 remove acl references (by ebremer)

<elf-pavlik> +1

<termontwouter> +1

<eBremer> +1

<acoburn> +1

<gibsonf1> +1

<laurens> +1

<ryey> +1

<pchampin> +1

<TallTed> +1

RESOLUTION: Remove acl link header examples as in w3c/lws-protocol#203

Discussion: Clarify Slug header references in protocol Issue#94

<Zakim> elf-pavlik, you wanted to support not mentioning it and focusing on use cases from people who ask for it

laurens: I would also support not mentioning it in the text

<termontwouter> +1 from me as well for not mentioning it

elf-pavlik: I also support this
… clarify what they try to accomplish using it
… focus use-case first

pchampin: playing devil-advocate, not belong in sspec but best practices. If server supports it that we describe in storage description

<gibsonf1> +1

<elf-pavlik> w3c/lws-protocol#207

<gb> Issue 207 Define capabilties affecting Resource Identification (URI allocation) (by elf-pavlik)

laurens: fits into discovery mechanism of lws but not require us to specify the slug header

<Zakim> termontwouter, you wanted to suggest adding it as an optional capability

laurens: we have some work there

<pchampin> +1

laurens: some of us supporting not mentioning it in the specification text

<Zakim> acoburn, you wanted to ask about next steps

<elf-pavlik> +1 PR to remove current text

acoburn: if folks agree, step 1 remove current inclusion of slug headers, but separately, as we look into the capability definitions, we add it there

ACTION: laurens to remove mentions of the Slug header from the LWS protocol text

<gb> Created action #217

Discussion: Clarify ETag header references in protocol Issue#62

acoburn: in current text, we discuss and encourage use, etags are only one concurrency control
… i want to generalize what we define for concurrency control

<gibsonf1> +1 to picking eTag as winner

<Zakim> elf-pavlik, you wanted to mention state property in solid notifications

<Zakim> acoburn, you wanted to mention weak/strong ETag requirements and complexity

elf-pavlik: keep general concurrency control or synct to keep notification in mind

acoburn: fedora invented their own cause they were not able to use strong identifiers for etags
… so it didnt work properly
… there are CRDTs and other mechanisms that might be available

<Zakim> termontwouter, you wanted to suggest a capabilities approach here as well

<acoburn> +1 to approach with capabilities

termontwouter: approach from capability discovery.
… suggest other concurrency mechanisms in the same way

gibsonf1: on etag issue, outside of PUT, which means when you create not necc declaring any representation
… we solved it as its supported by all browsers

acoburn: thats great. were extensive convo back in the day to do with the combo of conneg

gibsonf1: we include rep in the etag as part of that solution