– DRAFT –
Linked Web Storage

Introductions and announcements

acoburn: I want to talk about TPAC
… occurs in Fall hosted by W3C

i hear you

acoburn: great opportunity for face to face conversations...
… given time frame of working group....this coming Fall only opportunity
… is anyone planning to attend TPAC...
… just trying to gauge the audience...

<uvdsl> we (tobias and myself) probably wont be able to be at TPAC in person

<bendm> I most probably won't be able to attend TPAC in person

<pchampin> FTR, I will be attending TPAC (and ISWC)

acoburn: .. would make arrangements to do remote

jeswr: solid symposium will probably be a no. it wont be in the fall

acoburn: we want to make sure we are making good progress on the specification..
… not wait for a full additional year passess.

jeswr: I agree

acoburn: looks like some positive reactions to somewhere in Europe or London-ish...

Action Items

acoburn: only one standing action item...

hadrian: issue one closed last week
… this week, 37, 109, 113 were closed
… they are mostly duplicate of other and 31, 34, 107, 111, 35, and 95

Resolutions

hadrian: are not closed yet, but they are ready to close pending mergin 149

<acoburn> Current draft using GH Pages

acoburn: two procedural steps related to the publication of first drafts documents such as the UCR document6

<acoburn> 404 Not Found on W3C site

acoburn: this is not a document thats on the rec track, but it will be published as a note
… alot of work with use cases document

hadrian: conversation a whole ago about having links and tracking procenance of use cases and all that
… documents has to be self-contained...

pchampin: hadrian, you raise this issue of having long lived links to the use cases....
… so I made a PR on the UC documents where basically just wrote a script that created sections for the use cases...
… in the github
… more consistent on text but at least we will have this.
… LWS-UCS is the current short name. we could decide to change.

csarven: I would suggest not to use numbers.
… give human readable in order to move it around easier....
… maybe not what you were getting at...

pchampin: I use the issue numbers as assigned by github
… not that they would represent any order in the final document
… not the most user-friendly achors
… problem with user-friendy, if we rename use case...opaque identifiers more robust

csarven: thats fine

hadrian: use cases titles are also definitions..
… if we use numbers, I will make sure they are in-sync

acoburn: questions about publishing the first draft?

pchampin: idea of publishing first draft is just that, its a draft, lets not worry about it being in the perfect shape
… release early...
… second resolutionis release often part..

<acoburn> PROPOSAL: The Linked Web Storage WG will publish the first draft of the Use Cases and Requirements document at https://www.w3.org/TR/lws-ucs/

<laurens> +1

<pchampin> +1

<gibsonf1> +1

<bendm> +1

<hadrian> +1

<eBremer> +1

<bartb> +1

<RN> +1

<kaefer3000> +1

<dmitriz> +1

<csarven> 0

<acoburn> +1

<TallTed> +1

<cpn> +1

csarven: im not sure if there anything substative that would meet a first draft..
… not like any representative of most things we have been discussing

RESOLUTION: The Linked Web Storage WG will publish the first draft of the Use Cases and Requirements document at https://www.w3.org/TR/lws-ucs/

csarven: but if the group thinks it is its still useful for the community. no objection from me

<acoburn> PROPOSAL: The Linked Web Storage WG will use echidna for subsequent publications of the Use Cases and Requirements document.

<acoburn> Using Echidna

acoburn: to use Echidna, used widely in W3C for publishing these specification...

<acoburn> Using Echidna requires a WG decision

acoburn: in order to use it, look at this location

<gibsonf1> +1

<pchampin> +1

<bendm> +1

<TallTed> +1

acoburn: whenever a merge to the main branch happens, for example, Echidna would automatically go through all of the automation...

<bartb> +1

<RN> +1

<eBremer> +1

<hadrian> +1

<acoburn> +1

<laurens> +1

<cpn> +1

RESOLUTION: The Linked Web Storage WG will use echidna for subsequent publications of the Use Cases and Requirements document.

User cases and requirements status

acoburn: hadrian, where we are in terms of the status of the use case and requirements document...

hadrian: my focus right now is on sharing and consent which ties into the identities and infrastructure
… notifications and discovery...i think we are going to discuss later...
… notifications should be part of spec or just mention because its really a big thing

acoburn: even if it doesnt make it in, there are a lot of advantages to having this described in a use cases document

Discussion: Authorization use cases and scope

acoburn: this will take several weeks of discussion...
… and that will probably just limited to framing the topic and scoping it...
… authorization is a tricky one.
… partly because its such a big area.... we do have prior art
… want to scope so as not to boil the ocean...
… try not to prevent us from doing new things..
… WAC is something that goes back a very long time...
… other attempts...Inrupt's ACP
… just sort of a discussion at this point....I want to open the floor to comments, questions, and discussion

<dmitriz> (I'd also add zcap-ld to authorization methods)

csarven: I like the idea of what you said breaking it down to some function and non-functional requirements.

<csarven> https://www.w3.org/TR/design-principles/#simplicity

csarven: one or more solutions that might come out to cover various aspects of those use cases.
… can do fine with simple solutions.
… solutions as simple as possible
… implementable within a reasonable amount of time
… more complex number of implementations will drop
… developers will say "too complex"
… take google docs, four options for access control like viewer, editor, commenter, owner...
… you can map them easily to read write append and control
… I'd rather see something like that then something far more complex
… than jeopardize the number of implementations that we might have
… were almost halfway into this group and we do not have a use cases document out
… generally prefer simpler solutions over complex ones

<Zakim> gibsonf, you wanted to say agent hierarchy and resource hierarchy (in context of authorization)

acoburn: simplicity really relevant here.

gibsonf1: on authorization, who does it and what gets done

<Zakim> bendm, you wanted to talk about usage control (needed by EU law for personal data), and to talk about have simplicity as a base, and extensibility to external authz servers)

gibsonf1: a department, a whole company....doesn't scale if you dont have some kind of hierachy

bendm: example within GDPR laws, just who gets access to what but also for which purpose...
… start with some simple but is extensible

acoburn: finding balance of simplicity that Sarven is speaking about with making sure it is feasible to deply it in a context where you need something more

csarven: if we can show some form of success.
… help us be in a better position to make the case to request an extension or renew charter
… instead of going all-in with the complex thing and then jeopardizing showing "adequate implementation experience"
… we have 10, 20 people relatively active,. not sur eif that is enough to show that we have implementation experience
… simpler choice is going to get us to the finish line

acoburn: we need to come up with something and if it is as consistent and as implementable as possible

gibsonf1: like idea of simple protocol but ideal could be built on

acoburn: better if we can extend rather than re-write