– DRAFT –
Linked Web Storage WG

Introductions & announcements

laurens: agenda for today - 3 topic

laurens: introduction and announcements

laurens: next monday is easter monday, so bank holiday so do we push the meeting or cancel it ?

laurens: proposal is cancellation

<gibsonf1> +1

<TallTed> ±0

<balessan> +1

<hadrian> +0

<pchampin> +1

<jeswr> +0

<acoburn> +0

<csarven> sqrt(-1)

laurens: ok on that proposal to cancel next monday's meeting

<jeswr> https://theodi.org/news-and-events/news/solid-advisory-committee/

jesse: my announcement is nomination/application are open for ODI advisory committee

jesse: A number of roles here, all related to solid

jesse: Implementer, researcher, commercial and entities using solid, sustainability and inclusion.

jesse: looking for applicants

hadrian: One comment, does that apply to LWS as much as Solid?

jesse: Obviously yes as ODI has an official representation in LWS

<csarven> pchampin: train wifi + zoom is not looking good for me. is there a low bandwidth alternative that I can join with? or only phone call or something.

hadrian: There were conversation about wallets, self sovereign identifiers and

<Zakim> acoburn, you wanted to note a scribe convention

<pchampin> https://internetidentityworkshop.com/

ben: what is expected from those volunteers exactly ? what kind of outputs ?

<csarven> pchampin: Okie, I'm in. Will see how this holds up

jesse: 8 Meetings per year and, 5 cumulative days of work, travel can be subsidized. outputs: Drive the strategic orientation that ODI takes.

jesse: looking for some representatives that are not especially from the existing solid communities

<Zakim> gibsonf, you wanted to ask - what is official ODI app deadline?

gibsonf1: the deadline?

jesse: Registration ends right after the solid symposium? April 30th. Light application ok. Just some lines and attaching your resume does it.

laurens: next action item: do we have open action item?

Portability and identifiers

<Zakim> ericP, you wanted to say that the reason i presented those https://hackmd.io/udygiH3STieqHniB38h1ig#/ last week was to get us all on the same page wrt the differential cosrts between identifiers and locators.

laurens: Next item: portability of identifiers

ericP: wanted to get us all on the same page on this identifiers and locators question

ericP: Why we might want to think about the URN vs URLs ?

hadrian: if we build system with identifiers which reverts to identity, registry are not the only way to dereference identifiers to identity

laurens: one of the challenges I see to have identifiers for resources which are linked to their locators is that when you decouple those, your surface of specification becomes more larger

<Zakim> gibsonf, you wanted to ask - would it be possible in splitting identifier/locators to still use QR codes of an identifier to jump to a resource? How would that work?

gibsonf: how would that work with that locator vs identifier split ?

dmitri: you have to divide the use-case between the general camera. The qr code check by an app can have some logic for instance. (missed the rest...)

<Zakim> ericP, you wanted to say that the downside of gibsonf1's notion of a URL is that it might need to be portable

<pchampin> I would suggest that an identifier with broadly deployed resolution mechanism is undistinguishable from a locator

ericP: When you point QR Read to point to a URI, now you are a slave to the domain name which is supposed to serve the identifier.

ericP: If we go the way to use URLs as resource locator, we have a point of vulnerability on the UI which resolves that

hadrian: I don't think we should move to another way to identify resource. Did is another thing for identities. For accessing resources, let's continue to use HTTP.

hadrian: any other views ?

<Zakim> ericP, you wanted to describe cost of HTTP

ericP: In Solid land I have no problem registering domain names, move them and so on, if you scale that up to expected 9billions people, that might not be doable

ericP: Using something other than DNS for resource and identity locators ?

laurens: what about identities of agents, use-case for identity of resources ?

laurens: Scaling issue/portability issue. What is the killer use -case for decoupling those ?

laurens: It is unclear to me now. I just see the issues

tobias: Hadrian said for retrieving, if we have DID we should keep HTTPs for dereferencing identifiers. I did not understand that completely. ericP stated the issue of portability.

tobias: everybody is having his identity in email address and is tied to that from a long time. How much does that really hurt ?

<Zakim> gibsonf, you wanted to say: In our case, QR codes point to the app URL with the resource in the query string - so app comes first

tobias: Everything registering DNS should obviously not be what people needs to do but they did it.

gibsonf1: for the qr code you actually have to go the app to retrieve and resolve the identifier from the qr code

hadrian: Laurens, about the killer app, it is data portability and provenance. This coupling is hindering adoption

hadrian: for this to work it will required some kind of infrastructure. We do not talk about that but it should be stated.

hadrian: If you lose your email address you lose access to everything but you count on your email provider to manage that

hadrian: What happens at that scale when everybody relies on the DNS? And you change that.

laurens: DO you need to make every identifiers portable?

laurens: Or do we need to make some of them portable

hadrian: You need at least one identifier which is sovereign and that has been given to you.

dmitriz: I think we see the value of completely portable identifiers and the current difficulties

dmitriz: your current goal is to make the first specification of the LWS

dmitriz: we could say that we need https identifiers

dmitriz: We probably should not require http urls

<jeswr> +1

<pchampin> +1

<bendm> +1

<laurens> +1

<acoburn> +1

<csarven> -1

<gibsonf1> +1

<kaefer3000> -1

<Zakim> ericP, you wanted to noodle on bootstrap process

ericP: +1 for dmitriz proposal

<dmitriz> I'd be of course curious to hear from kaefer3000 and csarven abut those -1s

ericP: : if we say must support ONLY https. what it means writing the spec with "may". If we rewrite the spec in one year, what will be the impact on existing systems?

ericP: we need to noodle on that

<Zakim> gibsonf, you wanted to ask about the status of Webid's as used in Solid in this context (as in the semantic subject of the agent)

hadrian: big +1 to dmitriz, the thing we can do is that there are necessary but we cannot be resolved today

gibsonf1: question about the webid, using the webid as the resource location about the agent, how would the decoupling cope with this idea of semantic webid ?

hadrian: the idea behind webid there was a one-to-one equivalence between webids and did:web emitted for the same agent.

hadrian: you only care about the webid document, you need to get it in some way. You need an id which uniquely represent the document and being able to dereference it

hadrian: really good conversation to have in more details in issues

<Zakim> csarven, you wanted to mention HTTP working within the OWP and 99%+ coverage on the web

<hadrian> looks like nothing I said today was captured in the minutes

<dmitriz> @csarven -- I think my comment (and the +1s) were about not RESTRICTING it to HTTPs only IDs

<gb> @csarven

<dmitriz> obviously HTTPS IDs are fine. we just want to add an upgrade path

yeah sorry I have issues following here

If somebody is able to decode

csarven: I suggest to consider alignment with the web platform for starters, which is HTTP - proven to work before dismissing it. Is somebody here trying to build applications which are scaling to the whole world?

<Zakim> acoburn, you wanted to respond to Fred

acoburn: We are talking about not restricting identifiers to HTTP URIs

<hadrian> as identifiers today we don't use http :), we use strings and email addresses

acoburn: Two things you need: one mechanism to validate a given identifiers, webid is just one example. As a locator, an app can resolve that ID and fetch additional information, as long as there is a mechanism to get additional information, you are fine

<csarven> acoburn dmitriz balessan , may I ask you to update minutes in what is being suggested regarding HTTP identifiers? What I've interpreted from the part audio and the draft minutes above on IRC are a bit different than what acoburn just said.

acoburn: right now WebId is a community draft. It does not have the level of maturity as DID of HTTP for instance.

<gibsonf1> Thanks Aaron

laurens: Want to second that we should focus on the use-cases. Portability, provenance are areas where we need to ensure that decoupling.

<dmitriz> yeah, so to restate my comment for IRC: This is a great discussion. I think we all agree on both sides of the discussion -- that cross-domain portable IDs (for agents and resources) would be really useful, but have some challenges at the current moment, so we can't REQUIRE them.

Action items

@laurens: final agenda item. Update on the actions items from last week.

<gb> @laurens

<laurens> https://github.com/w3c/lws-ucs/issues?q=is%3Aissue%20state%3Aopen%20label%3Aneeds-discussion

hadrian: no update this week on that side. The target was the end of the month. Holiday next week is to be considered.

<dmitriz> so, really, this is a discussion about MAY vs SHOULD vs MUST, in the spec. My proposal is: we _don't_ want to say "all identifiers MUST be HTTPS" (like the current OpenID Federation spec does). That's too restrictive. Similarly, we don't want to say "all identifiers MUST be cross-domain portable". So instead, I propose we say something like "IDs can be either https-based or using a cross-domain portable identifier spec", and have a Portability

<dmitriz> Considerations section in the spec

hadrian: let's continue the discussions in the issues themselves, we can go in more details.

<Zakim> gibsonf, you wanted to ask about adding UC - is that via the issues?

gibsonf1: To add a new use-case, should we just create a new issue?

laurens: yes definitely

<csarven> Meh, I have a bandwidth problem

<dmitriz> @csarven - yeah, probably best to type out your comment here

<gb> @csarven

<dmitriz> or mailing list

<csarven> I give up re Zoom

<csarven> No need to call a requirement level at this point on what a particular requirement should be in isolation. I think that's premature. I don't disagree with the idea to not limit the URI scheme to HTTP. That's fine, but we're still only talking about UC requirements!

<csarven> And never need to say "all x should use y". instead say "to do x, use y"