– DRAFT –
Linked Web Storage

Introduction and announcements

Vote: Publish FPWD of Webhooks Notification Suite

acoburn: we have a number of votes; two docs not yet published: webhooks and lws search services.
… Lawrence moved the webhooks part into its own seprate document

<acoburn> https://w3c.github.io/lws-protocol/lws10-notifications-webhook/

acoburn: this allows for extension points
… this webhooks portion is currently unpublished

<acoburn> PROPOSAL: Publish the FPWD of the Webhooks Notification Suite based on the editor's draft at https://w3c.github.io/lws-protocol/lws10-notifications-webhook/

<elf-pavlik> +1

<ericP> +1

<pchampin> +1

<acoburn> +1

<eBremer> +1

<gibsonf1> +1

<TallTed> +1

RESOLUTION: Publish the FPWD of the Webhooks Notification Suite based on the editor's draft at https://w3c.github.io/lws-protocol/lws10-notifications-webhook/

Vote: Publish FPWD of LWS Index Services

acoburn: search and type index services has not been published
… vote is to go to FPWD

<acoburn> PROPOSAL: Publish the FPWD of the Search and Type Index Services based on the editor's draft at https://w3c.github.io/lws-protocol/lws10-searchindex/

acoburn: for both this and the previous, we can decided whether to go on the REC track or stay in permanent CR

<gibsonf1> +1

<elf-pavlik> +1

<eBremer> +1

<ericP> +1

<acoburn> +1

<pchampin> +1

<TallTed> +1

RESOLUTION: Publish the FPWD of the Search and Type Index Services based on the editor's draft at https://w3c.github.io/lws-protocol/lws10-searchindex/

Vote: Integrate access request terminology PR#218

<acoburn> PROPOSAL: Merge the access request terminology PR at w3c/lws-protocol#218

<gb> PR 218 Integrate access request terminology with main terminology section (by acoburn) [editorial] [access-request]

<elf-pavlik> +1

acoburn: this PR noves terms to Terminology. (these terms were left inline to minimize diffs when the lower section was added)

<eBremer> +1

<ryey> +1

<acoburn> +1

<ericP> +1

<gibsonf1> +1

<pchampin> +1

<TallTed> +1

RESOLUTION: Merge the access request terminology PR at w3c/lws-protocol#218

Vote: Replace AS terms with DCTerms/LWS equivalents PR#219

acoburn: we were using ActivityStreams for Containers even though they aren't ActivityStreams
… moving to dcterms vocabulary

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

elf-pavlik: can we freely re-define in the future or is there some process?

acoburn: before CR, we're free to re-defined. It gets more complicated after PR

<elf-pavlik> this is less relevant to this PR since we swap external vocabs

pchampin: gut feeling: as long as we're backward-compatible, it shouldn't be a problem

<Zakim> ericP, you wanted to say the Q post-CR is "would it change an implementation"

pchampin: for now, until we have a CR, we have no constraints

ericP: would it change an implementation is the rule post CR

ryey: dcterms format has several interpretations, as stated in its own definition.
… mime-type is the preferred interpretation but would those other interpretations be a problem?

acoburn: we should be restricting the value to be a mime-type
… while dcterms:format is broader, we narrow it here

ryey: do we have to say "mime-type" vs. "media-type"

TallTed: media-type is the appropriate term; can expand it to "mime media-type"

ryey: agreed

<acoburn> PROPOSAL: Merge the PR replacing AS terms with DCTerms/LWS equivalents at w3c/lws-protocol#219

<gb> PR 219 Replace Activity Streams vocabulary terms with dcterms and LWS equivalents (by acoburn) [vocabulary] [container]

<elf-pavlik> +1

<ericP> +1

<TallTed> +1

<acoburn> +1

<eBremer> +1

<pchampin> +1

<ryey> +1

<gibsonf1> +1

RESOLUTION: Merge the PR replacing AS terms with DCTerms/LWS equivalents at w3c/lws-protocol#219

Vote: Remove the Slug Header requirements PR#224

acoburn: this is about the `slug:` header

<Zakim> elf-pavlik, you wanted to mention related issues from Samu in https://github.com/lws-contrib/lws-test-suite/issues

acoburn: we were referencing the slug header text in RFC9110 but we weren't changing it at all

elf-pavlik: samu noticed that the test suite makes some assumptions about the slug:
… we'll have to update the test suite

acoburn: a server may ignore the slug. the Location: header is the authoritative response

<acoburn> PROPOSAL: Merge the PR removing Slug header requirements at w3c/lws-protocol#224

<ericP> +1

<gb> PR 224 fix: remove Slug header mentions from LWS protocol text (by laurensdeb)

<elf-pavlik> +1

<gibsonf1> +1

<acoburn> +1

<eBremer> +1

<TallTed> +1

<pchampin> +0

<ryey> +1

RESOLUTION: Merge the PR removing Slug header requirements at w3c/lws-protocol#224

Vote: Add subject_uri_schemes_supported to AS metadata PR#227

acoburn: when a client is interacting with the auth server, the client doesn't know if a particular schema is supported for subject URIs
… in auth server metadata, we have supported types (e.g. SAML SIDS), but it doesn't tell you how to deref those URIs\
… so e.g. a URI might not deref DIDs
… this is optional because you might have pre-existing trust relationships, such as the common case in SAML tokens

<Zakim> elf-pavlik, you wanted to ask about scheme+method nuance in DIDs

acoburn: if omitted, the default value is an array that includes HTTPS:

elf-pavlik: in addition to scheme, do we need a method?

<pchampin> good point

acoburn: yeah, these examples include both scheme and method
… that would be a good follow-up
… amend the PR or will we deal with it later?

elf-pavlik: up to you

TallTed: not a blocker, but both of those definitions should have a dfn class.
… added to PR this AM

acoburn: I can add that to this PR or we can come back to it.

<acoburn> PROPOSAL: Merge the subject_uri_schemes_supported PR at w3c/lws-protocol#227, with the inclusion of dfn tags and, for DID URIs, include scheme+method

<gb> PR 227 Add subject_uri_schemes_supported property to AS Metadata (by acoburn) [authorization] [authentication]

<elf-pavlik> +1

acoburn: amending the proposed vote with the changes from TallTed and elf-pavlik

<gibsonf1> +1

<ericP> +1

<eBremer> +1

<acoburn> +1

<TallTed> +1

<ryey> +1

<pchampin> +1

RESOLUTION: Merge the subject_uri_schemes_supported PR at w3c/lws-protocol#227, with the inclusion of dfn tags and, for DID URIs, include scheme+method

Vote: Clarify OAuth best practices PR#225

acoburn: adding a line to clarify that "this is part of oauth so it uses oauth security section"

<acoburn> PROPOSAL: Merge the PR clarifying OAuth best practices at w3c/lws-protocol#225

<gb> PR 225 Clarify why OAuth best practices are applicable to lws10-authn-ssi-cid (by uvdsl)

<elf-pavlik> +1

<acoburn> +1

<gibsonf1> +1

<TallTed> +1

<ryey> +1

<eBremer> +1

<pchampin> +1

<ericP> +1

RESOLUTION: Merge the PR clarifying OAuth best practices at w3c/lws-protocol#225

Vote (maybe): Remove the ETag requirements PR#228

TallTed: looking at the RFC, ETag was not mention as part of concurrency

acoburn: RFC9110

<acoburn> https://datatracker.ietf.org/doc/html/rfc9110#name-etag

TallTed: yes, ETag isn't mentioned in Concurrency and visa versa

acoburn: after i opened this PR, there was some pushback from a person working on a js framework that does local-first

<gibsonf1> +1 to eTag as a MUST

acoburn: they wanted ETag as a baseline for concurrency control
… this PR softed this to a SHOULD
… I'm not asking the group: "should we keep ETags as a must?"

gibsonf1: +1 to MUST. fine if people want more

TallTed: it's fine if ETags didn't meet someone's use case but ETags aren't a heavy lift
… the Q is "what are we blocking by requiring ETag?"

pchampin: big fan of ETags
… would be sad if we didn't make it a MUST but acknowledge that they interact strangely with e.g. conneg
… saw similar issues in Community Solid Server
… we could provide some guidelines to help implementors avoid traps
… so I sympathize with not requiring them

acoburn: (as inrupt). we'll implement ETags and support a MUST
… i've also encountered those screw cases but like an implementors note doc
… so support ETags as a MUST
… (having worked around them)

<pchampin> TallTed you are right, but it is easy to get that wrong for implementers

TallTed: I'm surprised that there are bad interactions with conneg
… +1 to impl guide. not married to where it happens

gibsonf1: authn is trickier than conneg. needed to embed auth level in the ETag

acoburn: i gather we should not vote on this ETag PR because it would be voted down
… I'd like to make sure that the ETag requirements are consistent and open another PR to manage editorial changes

<gibsonf1> +1

<Zakim> elf-pavlik, you wanted to suggest test cases besides prose in some WG NOTE

elf-pavlik: +1 to ETags, but we can already start a WG note with a section for ETags and capture edge cases in the test suite
… perhaps optional tests, but at least something devs can take advantage of

Discussion: Decide on resolution for StorageResource definition issue#220

acoburn: [github is still spewing unicorns]
… we have terms like `lws:Resource`. Q is what to include in the JSON-LD @context
… option1: keep StorageResource and change the the description to say it's an lws:Resoufce
… option2: keep StorageResource and change Resource->StorageResource in terminology
… option3: change this to Resource in the JSON-LD
… inline with how we define Container
… option4: change the JSON-LD @context to be "LWSResource"

<gibsonf1> +1 option 4

pchampin: prefer option 3
… if Resource is too generic, propose: spell it "LWSResouce" in the JSON-LD but have it resolve to lws:Resource

<Zakim> elf-pavlik, you wanted to mention LWS context being @protected

pchampin: lws:LWSResource would be a bit strange

elf-pavlik: are we taking into account the fact that the @context is protected?

acoburn: JSON-LD 1.1 allows one to map terms within the context of a scope.
… we already do that in the scope of access policies

<elf-pavlik> I assume https://www.w3.org/TR/json-ld11/#scoped-contexts

<elf-pavlik> #226

<gb> #226

acoburn: there's a PR to remove the SSI/DID document. can we un-publish something in TR?

pchampin: can't remove from the Web but there are processes to e.g. mark it rescinded