– DRAFT –
Linked Web Storage

Introduction and announcements

Charter timeline proposal at PR#10

we are in a charter refinement period, until Oct 5th

acoburn: we are in a charter refinement period, until Oct 5th
… effectively 2 more weeks

one specific item is the proposed timeline
… one specific item is the proposed timeline
… we don't effectily need a on month delay for the first teleconference
… hope is to move to CR for most deliverables in aaaaaa months
… CR 2 months for most things; then a little bit further for LWS Index in 6 months; then 12 months for Primer and Threat Model doc

TallTed: I threw a comment
… the sooner we know, the better

TallTed: using a different model doesn't help

acoburn: I would love to have something when the next charter begin (e.g. in January). We may set some tentative dates for that.

TallTed: tentative dates sounds good
… it's easier to have a block of time, and put it to a calendar, to be easier to see

acoburn: we can group things in a more coherent way
… maybe also a Gantt chart or something

<Zakim> elf-pavlik, you wanted to ask why 2 months given lack of impl feedback until now

acoburn: anyway, I hope we as a group to agreen on a timeframe

elf-pavlik: the comment of having CR and then candidate is quite outdated
… I suggest, by the end of the year, by par, have TM as a draft
… charter + 2 month as the latest for draft; then the next 1-2 months for hearing feedback
… easier to have things and gather information. We can go earlier than schedule, which is good

acoburn: I feel there are groups implementing now. We are getting feedback, but just in a different form

<TallTed> CR is like "broad*er* review"

<elf-pavlik> how about aiming for +4 and if we are ready +2 than great!

acoburn: important thing about going for CR is that it's a public announcement. it says we have something, and ready to get feedback
… I would be concerned about moving that out, in that sense
… another thing about CR -- yes, it's harder to get changes

<Zakim> elf-pavlik, you wanted to ask about making major change to existing feature after CR

acoburn: something easily gets removed now. once in CR, it's more about adding new features.

elf-pavlik: I'm not so concerned about adding new features. I'm more concerned about getting feedback, and find something need a better design, and would like to make a big turn to the feature

TallTed: it's not necessarily easy to remove either
… if we mark thing as at risk, it's easier to get removed; so is the other way around
… note implementation detail and spec are different
… we may put some algorithms in the spec, but that's just illustrative. As long as something works in the same way for inputs and outputs, that's fine

pchampin: I understand elf-pavlik's comment is not about implementation details
… note we have 12 months

<elf-pavlik> thanks pchampin

pchampin: sometimes feedback comes and we change things. that's why we don't set it as 28 days

TallTed: I would suggest to put min and max period for the time plan

Vote: Clarify DID support in SSI-CID authentication suite PR#233

acoburn:

acoburn: we want to clarify authentication suit and DID
… we discussed last week. it turned out it's non-normative notes

<acoburn> PROPOSAL: Merge DID support clarification w3c/lws-protocol#233

<gb> PR 233 Clarify DID support in the SSI-CID authentication suite (by acoburn)

<gibsonf1> +1

<acoburn> +1

<elf-pavlik> +1

<eBremer> +1

<pchampin> +1

<TallTed> +0.5

acoburn: it effectively only relates to DID URIs

RESOLUTION: Merge DID support clarification w3c/lws-protocol#233

Vote: Add lws:StorageResource to vocabulary PR#234

<ryey> +0.5 (not an expert in the granules; generally looks fine)

acoburn: this one adds a lws:StorageResource class to the vocab

eBremer: makes a separate of StorageResource, and closes #220

<gb> Issue 220 StorageResource definition (by acoburn) [vocabulary] [access-request] [pr-exists]

<acoburn> PROPOSAL: Merge add lws:StorageResource to vocabulary w3c/lws-protocol#234

<gb> PR 234 Add lws:StorageResource to the vocabulary (by ebremer)

<gibsonf1> +1

<elf-pavlik> +1

<eBremer> +1

<acoburn> +1

<ryey> +1

<ericP> +1

<TallTed> +1

RESOLUTION: Merge add lws:StorageResource to vocabulary w3c/lws-protocol#234

Test Suite status update

<elf-pavlik> lws-contrib/lws-test-suite

acoburn: there is a test suite meeting in 1.5h. test suite group please share

langsamu: Following last demonstration, I'm extending to send HTTP request to servers, receiving responses, etc
… I'm also in the test suite task force

<eBremer> ebremer/touchstone

langsamu: going to make the repo public, and make it a docker
… doing demonstration
… started eBremer's server, run my test suite, see test reports from there
… sending HTTP requests to inside the docker; output is in the report

<TallTed> Just for awareness,"LWS Test Suite TF" conflicts with "FedID WG - DC API" and "VCWG Task Force: Barcodes, Data Integrity, Forgery Defense, Bitstring Status List" (and maybe more). I'm triple booked and expect to be present at the last of these.

<Zakim> elf-pavlik, you wanted to mention 2 recent PRs

elf-pavlik: sharing my screen
… I made two PRs for test suite

<langsamu> langsamu/LWS.net

elf-pavlik: I made it very easy to run

<langsamu> ^^ will move to lws-contrib soon.

elf-pavlik: you don't need to have language environment in your host; you just have a docker
… the idea is to allow running test suite in CI, and people can also run it locally
… We also made it customizable through vars
… We have an idea to have tests as a DAG, and run them
… we can't test them in isolation, but can do other advanced things

<Zakim> ericP, you wanted to ask if eBremer's impl is embedded int the docker

elf-pavlik: welcome to join the meeting in 1hour, if you have any comments or questions

ericP: it's all in a docker? what does that mean?

langsamu: it's in one run, but two parallel tasks; one clones and runs eBremer's code; the other runs test

ericP: are instructions to run it outside of Docker, for assisting debugging?

langsamu: not yet; but everything is command line
… I'll give instructions of prerequists of how to run it, e.g. dependencies

<acoburn> elf-pavlik: you might need to drop and re-join. I am unable to change the screen sharing

eBremer: there is a MCP to control

TallTed: this looks great; better than some other things I saw elsewhere

<pchampin> +1 that looks great

gibsonf1: will be possible to run it over the internet?

eBremer: I have several servers. I want to allow agent to inspect and improve

langsamu: test suite is a http client. I promise won't do backdoors.

gibsconf1: in the test, is there no possibility of halluscination?

langsamu: everything is determinstic

Threat Model status update

acoburn: where is it at?

<Zakim> ericP, you wanted to mention that auth may require some back-doors unless we leverage some authn requests

elf-pavlik: I've been focusing on test suites; not a lot in the threat modelling for now

never mind. I'll type

No a lot of updates from my side, as I was trapped in a lot of things... gradually getting out of that . should be able to do more soon

acoburn: the tentative timeline for TM would be later than Test Suite

Discussion: subject_identifier_types_supported PR#227

(hope I heard it right)

acoburn: some comments seem to refer to slightly different things, I feel

<Zakim> elf-pavlik, you wanted to suggest merging and a PR can followup to improve it further

acoburn: should we spend more time in this, or should we merge it?

<pchampin> +1

elf-pavlik: I would support merging

Discussion: prepare LWS Index document for FPWD PR#249

acoburn: will try to merge it soone, hopefully tomorrow, but at least this week

acoburn: we've not published first public draft for LWS Index yet
… we should make the short name shorter, and more generic.
… anything else before moving to first public working draft?

[no comment]

acoburn: two issues raised by jeswr, one about json and json-ld; one about server declare URI semantics. anything you want to discuss?

Conneg requirements for JSON/JSON-LD

jeswr: go for #246 first

<gb> Issue 246 Remove requirement that `application/ld+json` and `application/json` must be framed (by jeswr)

jeswr: it requires all three things returned in framed response
… the proposal is just to make the server not required to respond some types

pchampin: I feel the rationale works for ld+json
… if it's just json, probably the framed version is more appropriate
… I would +1 for json; but for ld+json, I see the point

jeswr: client requests json, but server almost always responses lws+json
… due to content negotiation
… but about ld+json ...?

<pchampin> I have to think about it :)

<Zakim> elf-pavlik, you wanted to ask for use case where client would request ld+json and not lws+json and expect it framed?

elf-pavlik: I agree with this in general. I would like to understand the use case
… since media type is define for lws+json. I don't think we need to think about more general cases

<Zakim> acoburn, you wanted to ask if this is *only* related to LWS containers

acoburn: I feel this only relates to containers

jeswr: also storage descriptions

acoburn: if we remove it, it doesn't prevent the server to still support this type of content negotiation
… it just allow the server to do content negotiation differently

<elf-pavlik> +1

<Zakim> ericP, you wanted to say our spec trumps conneg. a server could be required to serve the framed when requested

<pchampin> +1, I take back my earlier remark :)

jeswr: I would hope servers to always advise the upgrade from json to lws+json, and make it consistent