– DRAFT –
Linked Web Storage

Introductions and announcements

Storage Description as CID PR#183

acoburn: it's been open for a few weeks, we worked on some revisions
… it takes current storge description resource and makes it represented as CID
… main advantage is that it allows us to use other W3C specs, rather then reinventing things

<acoburn> PROPOSAL: Define the Storage Description Resource as a specialization of CID-1.0 as described in w3c/lws-protocol#183

<gb> PR 183 Define Storage Description Resources as a specialization of CID-1.0 (by acoburn) [storage-description]

<elf-pavlik> +1

<gibsonf1> +1

<acoburn> +1

<pchampin> +1

<ericP> +1

<jeremycaine> +1

<AZ> +0 (I have not followed enough the recent discussions to decide)

<TallTed> +0

RESOLUTION: Define the Storage Description Resource as a specialization of CID-1.0 as described in w3c/lws-protocol#183

LWS Protocol Introduction PR#158

jeremycaine: introduction section hasn't changed much in last weeks
… just few final edits
… something about apostrophes which i need to understand
… can we merge on assumption that I'll fixt it?

ericP: we can merge but it may be easier for you to fix it fixt it first

TallTed: I think it should be merged before vote is taken

ericP: PR is doing IPR check
… I will propose that we merge #158 after jeremycaine lets use know it's ready

<gb> PR 158 Add introduction section (by jeremycaine)

jeswr: looks like a bug in a CI

acoburn: are we going to vote on it?

ericP: i think we should vote

<acoburn> https://www.w3.org/events/meetings/a19ab7dc-1753-433d-bac5-64e3ad8c0a43/20260727T100000/

<elf-pavlik> +1

<ericP> PROPOSAL: Adopt introduction text from w3c/lws-protocol#158

<ericP> +1

<jeremycaine> +1

<TallTed> +1

<acoburn> +1

<gibsonf1> +1

<ericP> APPROVED: Adopt introduction text from w3c/lws-protocol#158

<gb> PR 158 Add introduction section (by jeremycaine)

Vote: LWS Diagrams PR#159

jeremycaine: there were some issues with git push, not all images are correct
… TallTed has some comments on styles

TallTed: sorry I couldn't get to it sooner
… there are bunch of comments on the style
… is there an intent to change pngs to svg?
… partly because that we will need to figure out textual description to satisfy accessibility

jeremycaine: I didn't add any of that just used default rendering
… do we want to merge it and fix styles later

<Zakim> acoburn, you wanted to talk about merge mechanics

<ericP> elf-pavlik: suggest merging. we need to model to base other PRs. we can address alt text etc later.

<ericP> ... re SVG, I don't think there's an easy way to get SVGs;

<ericP> jeremycaine: is there a simple list for accessibility?

jeremycaine: are there accessiblity guidelines?

TallTed: there aren't great guides, we should have some textual descriptions
… they are usually manually constructed
… starting from SVG is easier

<ericP> TallTed: they rules are complex. generally manually produced from SVG to allow for cut and paste

TallTed: this way one doesn't have to retype

jeremycaine: I think we can merge and come back, not to block threat model

TallTed: I would like to open issues sooner than later

jeremycaine: i can merge it today tomorrow

<ericP> elf-pavlik: we should ask "is this an improvement"?

<ericP> ... we can convert PR comments to issues.

<TallTed> (How did we arrive at creating these in c4? I know other tools are being used in other WGs, often to produce far more complex graphics. This might be worth some exploration.)

<ericP> ... i would like to merge this C4 file

<ericP> PROPOSAL: Adopt diagrams included in w3c/lws-protocol#159

<gb> PR 159 Add scope diagrams section with C4 Level 1 and Level 2 diagrams (by jeremycaine)

<elf-pavlik> +1

<gibsonf1> +1

<jeremycaine> +1

<ericP> +1

<TallTed> +1

<acoburn> +1

<pchampin> +1

<AZ> +1

RESOLUTION: Adopt diagrams included in w3c/lws-protocol#159

<ryey> +1

Discussion: Add Threat Model document PR#202

<ericP> elf-pavlik: since we want to model on top of 159, we're not ready to merge 202

<ericP> ... i will rebase on top of 159

<ericP> PROPOSED: Add Threat Model document PR#202

<gb> Issue 202 not found

ericP: anyone thinks they will vote agains?

TallTed: given it wasn't on agenda as a vote I'll rather push that

ericP: anything more to dicuss on it today?

<ericP> elf-pavlik: nope, just everyone take a look (before monday morning)

Discussion: Consolidate ConNeg requirements PR#190

acoburn: i'll give it some context, sharing screen...
… there are two things, the first is fixing some media types e.g., going from ld+json to lws+json
… some duplicate statements about conneg and media types, now in single section
… more about media type equivalence than content negotiation
… ld+json, lws+json gives the same representation
… conneg which is not specified would be converting it to turtle or xml
… it reflects more closely what this spec defines

TallTed: in my universe is more about conneg but i ok with using both in a title
… server MUST honor request and set content type, that is explicitly content type negotiation
… using both in the title may communicate things better if someone searches

acoburn: that would be a great clarification

<Zakim> ericP, you wanted to ask if there was a discussion of lws+jd+json?

ericP: do you know if that was discussed?

<pchampin> +1 TallTed, we are talking about "Accept" and "Content-type", so that *is* content negotiation, though I understand the distinction between "conneg for equivalent mediatypes" vs. "conneg for different representations"

acoburn: I don't think if it was, I've never seen media type like that, not sure if that's common

ericP: it has been discussed before in other scenarios

TallTed: I was involved in many discussed, at this point they are explicitly disallowed
… i'll try to find a reference

ericP: do you know why?
… I think it is something useful

TallTed: I was co-editing RFC that defines such behavior
… we were strongly opposed

<TallTed> and then I found it -- https://www.ietf.org/archive/id/draft-ietf-mediaman-suffixes-07.html

TallTed can you please drop link here if you find it? w3c/lws-protocol#188

<gb> Issue 188 Create reference explaining consistent use of HTTP content-type, profile, prefer etc. (by elf-pavlik)

ericP: asking about details of that IETF discussions

TallTed: msporny may recall more details

Discussion: JSON-LD Context & Vocabulary PR#187 and PR#199

acoburn: both relate to json-ld section
… #199 only makes adjustments to the vocab, we use YAML as the cannonical source

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

acoburn: spec already uses them, we just add missing definitions in the vocab

acoburn: #187 reworks json-ld section

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

acoburn: at present there is a verbatum context, generally specs don't do it
… now it follows more modern approach how VC spec and CID spec are doing it
… just URL and the SHA2-256 digest
… it helps people with supply chain validation etc.
… we are also advising not to fetch context a runtime

acoburn: please review them

acoburn: in #187 I took bigbluehat's suggestions and I joined json-ld wg meeting to discuss it in more detail

<Zakim> elf-pavlik, you wanted to mention w3c rate limits

Discussion: Privacy Considerations PR#206

ericP: there were specific firewall rules to avoid getting beaten by requests to namespaces

acoburn: this one adds privacy considerations to authn suites
… now they have empty sections with todo and tracking issue
… this pr resolves that pending todo
… please take a look at and review

ericP: i see 4 files that were edited
… : where do they differ

acoburn: at high level they mention that tokens contain PII
… implementation should minimise disclosure
… in openid we have JWT, saml has XML etc. so they differ slightly
… at high level they are very similar

acoburn: to respond to limitations of PR preview
… it only renders the protocol
… we can find workaround

elf-pavlik: use githack please

<acoburn> +1 link in description and as a comment

TallTed: please add comment with link and insert to the top comment

pchampin: would this content make sense in the threat model
… : we can factorise everything rather than have duplicate
… : thosese sections can refer the threat model

<ericP> elf-pavlik: once we have merged the base threat model, we can go through all of the privacy/security/mitigations

<pchampin> perfect, thanks

<ericP> ... these should all cross-link

acoburn: right now we publish authn suites as wg drafts, we don't publish the threat model yet

<elf-pavlik> +1

<pchampin> +1, I was not suggesting to *not* merge them, just keep this in mind for the future

<ryey> +1

ericP: any closing remarks?

<gibsonf1> +1

<TallTed> [ adjourned ]