DID Working Group Telco — Minutes

Date: 2019-12-17

See also the Agenda and the IRC Log

Attendees

Present: Daniel Burnett, Christopher Allen, Ivan Herman, Ted Thibodeau Jr, Phil Archer, Dmitri Zagidulin, Dave Longley, Michael Lodder, Yancy Ribbens, Ganesh Annan, Amy Guy, Orie Steele, Adrian Gropper, Irene Adamski, David Ezell, Chris Winczewski, Daniel Buchner, Drummond Reed, Michael Jones, Brent Zundel, Justin Richer, Manu Sporny, Joe Andrieu, Jonathan Holt, Kenneth Ebert, Kyle Den Hartog, Oliver Terbu

Regrets:

Guests:

Chair: Daniel Burnett

Scribe(s): Dmitri Zagidulin, Manu Sporny, Amy Guy

Content:

Michael Lodder: mike-lodder has joined #did

1. Agenda Review, Introductions, Re-introductions

Daniel Burnett: Agenda today - announcements, JSON/JSON-LD discussion for a few mins,
… then move into the meat of the meeting - discussion of matrix params
… because we were making good progress before (talking about their dimensions etc)
… then we’ll move to discussion of Metadata
… and if we end up with time, will work on additional unrelated PRs
… any requests?

Daniel Buchner: Markus: again on Slack yesterday, someone was arguing that any use of a Matrix parameter changes the entire DID of the string
I have literally heard this and the opposite by 5 different people now which is it?

Daniel Burnett: there’s a link to detailed logistics for the f2f off the Meetings page of the WG

Daniel Buchner: Would putting a value in a param after the DID Suffix change the DID itself, or not?

Michael Jones: Please post the meetings link to this chat

Daniel Burnett: introductions? anyone joining us for the first time?

Justin Richer: https://www.w3.org/2019/did-wg/Meetings/F2F/2020.01.Amsterdam

Daniel Burnett: ok, re-introductions!
… ok, how about Amy (rhiaro)
… also this is a good opportunity for you to mention the other ways of getting to the f2f

Amy Guy: hi, I’m amy, working with Digital Bazaar

Christopher Allen: I will be Amsterdam a week earlier - any ssi meetup.

Amy Guy: other ways to get to the f2f - Europe is very well connected, so this is a great opportunity for trains/buses/ferries
… if anyone wants help planning that / do that instead of flying, let me know

Daniel Burnett: Amy is very modest - she is well-known for great standards work at W3C

Drummond Reed: Hooray for Amy!

Amy Guy: and if you’re interested in coming from the US by ship (freighter), I know a couple websites

Phil Archer: I don’t see any reference to remote participation, for the f2f

Daniel Burnett: I’m awaiting reply on that, from our hosts

2. Announcements

Daniel Burnett: we need you to get your issues in
… the Editors will be spending the next week or two looking at issues / PRs, trying to classify them
… so if you have outstanding issues for the spec, please do get them in

Daniel Burnett: F2f signup/topics: https://docs.google.com/spreadsheets/d/11haGLiY3AYi8uxIQcfndAixmtXjymNTTFbDQWRYkKrQ/edit#gid=0

Daniel Burnett: related to that, there is a page (link in the agenda), there is a doc both for signing up for the f2f, and requesting agenda topics
… so there’s two tabs, attendees and Agendas
… on the Agenda tab, don’t fill in particular time slots, but add stuff to the yellow area (topics you’d like covered for the f2f)
… the discussion about JSON / abstract data model WILL be on the agenda, no worries
… one other thing that we wanted to bring up is that
… we have our f2f meeting in Jan. Our WG will meet at TPAC in Sept
… so there is an opportunity to schedule another face to face, between that
… there is an Advisory Committee in May, in Seoul
… quick show of hands - anybody interested in a may f2f, in Seoul?

Drummond Reed: Maybe

Orie Steele: :(

Justin Richer: IIW is in March and October

Daniel Burnett: STRAW POLL: interest in May f2f in Seoul?

Daniel Burnett: IIW would be easier, but it’s in March, too close to the previous one

David Ezell: +1

Ivan Herman: +1

Drummond Reed: 0

Manu Sporny: -1, I won’t be going to AC meeting :(

Yancy Ribbens: +1

Michael Jones: +1

Phil Archer: -1

Joe Andrieu: -1

Dmitri Zagidulin: -1

Orie Steele: -1

Michael Jones: But what specific dates in May???

Ivan Herman: AC meeting days: 18-19 May

Ted Thibodeau Jr: +0

Brent Zundel: 0

Amy Guy: +0

Michael Jones: When is the AC meeting?

Markus Sabadello: IIW is end of April, not March

Orie Steele: ^ IIW would be better

Phil Archer: +1 for IIW in late April

Daniel Burnett: ok, I’m getting enough of a sense, not overwhelming strong support

Drummond Reed: IIW is April 28-30 in Mountain View

Justin Richer: +1 for post-IIW

Daniel Burnett: so May / Korea is not looking great. will consider other options
… (and yes, will ask this again on the other time zone call)

Christopher Allen: two things
… firstly, hold the date for RWOT, Mar 16-20th, for Buenos Aires, for the next Rebooting Web of Trust
… this is our first Southern Hemisphere RWoT, trying to attract some of the dev communities in the central & south americas
… tentatively holding the RWoT date for Singapore, for Sept
… so if you’re interested in that area of the world, that’s a good opportunity

Daniel Buchner: Will there ever be another RWOT anywhere within 4-5 hours of the West coast of the US?

Daniel Buchner: Just wondering

Daniel Buchner: I may want to go again

Daniel Buchner: I am only asking for something literally 5 hours in any direction

Christopher Allen: finally, I will be at the gathering at the end of Jan, in Amsterdam - I’ll be there a week early, and will stay a week late. hoping to attend a few SSI meetups in a few places, maybe Berlin’s meetup
… so if you have interest in joining me or meeting with me, let me know

Michael Jones: the answers to the interim meeting question depends on whether it’s Korea or IIW

Daniel Burnett: right, the straw poll was specifically for Korea
… the IIW one or others will be separate polls
… any other announcements?

Ivan Herman: question about Buenos Aires. Do you have any more details on the rough agenda? As in, when to fly in, etc?

Christopher Allen: It is a full week.
… doesn’t start until the evening of the first day, Monday. So, I imagine it’s ok for ppl to arrive then
… it tends to go through a full day on Fri, so most people leave on Sat
… JoeAndrieu is working on the EventBrite
… we’ll be in the center of town
… hotel-wise

Daniel Burnett: RWoT should be able to provide additional info on hotel options and logistics
… anything else on announcements?

3. JSON/JSON-LD Abstract data model - arrange special call

Daniel Burnett: the chairs are very aware of this discussion
… I have several comments. One, we’ve been following this very closely, and are very aware of the discussion thread.
… we’ve heard people are wondering what the chairs are waiting for here, why not force a vote now
… the Chairs are waiting for Proposals. and by that we mean, text.
… we’re not in incubation spec here, we’re in the WG.
… so we’re not looking for vague proposals. We need a PR, or a similar document with concrete text.
… the text doesn’t have to be perfect, it can contain stubs, and so on. But it has to be concrete.
… only then can we call for a vote, to merge a PR into the document, even as working text.
… standards work is done by those that do the work. Manu is not the only one who’s allowed to do PRs; anybody can do them.
… if you have trouble, let us know, we can help.
… if you don’t like the discussion that is happening on a PR, you’re not stuck with it, you can write a competing one.
… second point. I think most of you are aware that the recent giant discussion thread on a PR has been locked by an editor
… we want to remind everyone that issue locking takes more than one editor; we’re continuing discussion with chairs on that.
… however, we firmly believe that everyone has been acting in good faith.
… to put it bluntly: please stop accusing others of acting in bad faith.
… doesn’t help conversation. If you think that a PR is not going the way you want, write a new one.
… the Chairs do not consider a PR a decision, until the group actually agrees.
… third point: we expect to spend major discussion time on this at the Face to Face meeting.
… just to be clear, we’ve always understood from the beginning, that there’s a Data Model, and separately, Syntactic Realizations
… so we’re waiting on concrete text on those.
… so yes, we’ll be discussing this at the f2f. Of course, proposals in advance do help.
… we will be also scheduling calls about this, before the f2f.
… beginning in January, post-holidays.
… the intent of those calls will be to determine the relevant factors necessary for the discussion
… this includes things like - if we have a JSON format and a JSON-LD format, how much interop will there be, or we wish to encourage?
… there have been statements about “if you have an @context, it will have such & such problem” and others saying opposite.
… so, the intent of these pre-calls is not to make final decisions, but to see if we can come up with a set of factors for us to consider at the f2f
… we will be sending out a doodle poll to schedule those calls, 1st / 2nd week of Jan, so look for that
… brent, anything to add?

Brent Zundel: Just to reiterate, the January calls are not to come to consensus. It’s to come up with consensus criteria.

Daniel Burnett: any clarification questions?

Jonathan Holt: just to point out, I had a PR in Barcelona last year, about IPLD, to go alongside / on top of JSON-LD
… and it came down to an issue of MIME types
… I made the PR, and it got shelved (because I didn’t get it in on time, before the closed date), and now it seems to be gone.
… so, I’ve been working on - once we get the MIME type thing worked out - on how to transform it to JSON-LD

Daniel Burnett: please open a new issue / PR.
… unless the PR was discussed and nobody was interested.
… so, usually our policy is not to close things unless there is consensus.

4. Matrix Parameters

Brent Zundel: https://github.com/w3c/did-core/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+matrix

Daniel Burnett: ok, on to Matrix Parameters.

Michael Jones: The key JSON etc issue is https://github.com/w3c/did-core/issues/137

Daniel Burnett: which of the editors would like to lead this discussion?

Markus Sabadello: we’ve talked about Matrix Params a few times

Daniel Burnett: https://github.com/w3c/did-core/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+matrix

Daniel Buchner: Can someone DEFINITIVELY answer whether or not adding a Matrix param changes what the actual DID is?

Markus Sabadello: https://github.com/w3c/did-core/pull/144/

Markus Sabadello: one piece of feedback that we’ve received is - there is not enough guidance for WHEN matrix parameters should or should not be used

Ivan Herman: The new text by Markus

Markus Sabadello: I’ve added a clarifying language PR
… there’s also a green Note box in the spec, bookmarking this
… so let’s give a quick summary
… When you use Matrix Params, you are creating a NEW identifier.
… the PR also explains that matrix params are not the only way to influence DID resolution & de-referencing,
… there’s also the ability to pass query params to a DID Resolver
… and explains how in HTTP, you can make a decision whether to pass parameters as part of the http URL, or in http headers
… so, DID params should be used when there is a clear use case when the param should be part of the URI - to be included in other JSON / JSON-LD documents
… also provides guidance for when DID Parameters (our alias for Matrix Parameters) should NOT be used
… for instance, we recently closed a PR for a ‘key’ matrix param, since we have url fragments to accomplish the same mechanism, so we don’t need a second one
… also, this PR provides a second guidance on when they shouldn’t be used — that’s when the same thing can be accomplished by passing headers to the resolver (caching, format / content negotiation)
… so, please review the PR, propose additions and changes

Michael Jones: I think we’d agreed on the last call that we would track the issue of whether there should be matrix parameters at all, in issue 137
… so, we need to decide if they should exist at all, before specifics

Daniel Buchner: clarifying question to markus.
… the whole reason I was using matrix params is - I must be able to add some values for a DID that are temporary
… to be discarded later, to be used for the purposes of resolution
… I dont want these to change the URL
… just like query params do not change the authority/path of the URL
… so, are matrix params appropriate for this use case or not?

Phil Archer: I had the same question

Drummond Reed: the answer, based on the work we’ve done on matrix params, is that it’s very similar to the example you just used
… the DID always identifies the DID Subject. that is unchanged.
… the Matrix Param does change the Resource identified by the overall url
… as I’ve watched the discussion around the Initial Values param, my initial take as an editor was - that’s fine, you’re not changing the resource identified
… I think of it as a temporal param, somewhat similar to a version
… I want to reinforce - the intent of Matrix Params is never to change the subject identified by the DID
… but like anything else, if you add a path, that changes the resource

Daniel Burnett: queue is growing really fast, we were hoping this would be a shorter discussion.
… closing the queue for the moment.

Markus Sabadello: to answer Daniel, the proposed Initial Values param makes sense, I’m personally in favor of it

Daniel Buchner: My only follow-up would be: thank you Drummond - in light of this, should I use a generic param for this, given multiple methods use it the same way, or a bunch of method-specific ones that do the same thing?

Markus Sabadello: adding matrix param could change the resource identified, as in the case of a service param
… in the case of initial values, it doesn’t change the DID Subject identifier, so that’s fine,
… to answer Mike, yes, it’s valid to have that discussion on whether we want matrix params at all
… I dont recall which issue that should be in.

Phil Archer: I’m in danger of asking a question that’s been answered before
… If you didn’t have matrix params, would you not just use a Query param string?
… looking at Tim’s original matrix param proposal, there was a lot of mechanisms in there
… so, imagine if matrix params didn’t exist. would you re-invent them, or use existing mechanisms (query params)

Daniel Burnett: yeah, there’s been a lot of discussion

Markus Sabadello: yes this is a good question, perhaps we should add an info box to the spec explaining this

Dmitri Zagidulin: I also wanted to ask a similar question… are there any reasons why you cannot use a query param for the initial value?

Daniel Buchner: I could

Daniel Buchner: I just want to know the thing to do

Dmitri Zagidulin: Why not just use query parameters?

Daniel Buchner: need to stick some crap on the DID, don’t care about the vehicle for the crap

Daniel Buchner: could be a crap truck, crap car, just need me some crap

Daniel Burnett: dmitri that is not correct. The DID Document is not the resource

Dmitri Zagidulin: I want to push back on what Drummond said about DID subject… especially in the case of service parameters, when you add one, it fundamentally points to a different resource… it’s somewhat misleading to say that the bare DID identifies the subject… what the DID subject is is meaningless (in the case of services) because it’s a link to a binary resource.

Michael Jones: we owe it to ourselves to understand how we can use query params and fragments to solve all these use cases
… even if that means dedicating / reserving particular query or fragment params for those purposes

Manu Sporny: I agree with daniel’s use case can be solved w/ query parameters.

Michael Jones: that seems far more preferable, than having to write / modify URL parsers, to handle semicolons
… meta-comment to phila — I wasn’t in the CCG either. but, a WG is a whole new thing, totally fine to re-ask questions.

Drummond Reed: @phila it is a good question and it has been a long discussion. The short very high level answer is that if we use query parameters, we step on the ability of developers to control the complete query string.

Phil Archer: +1 to selfissued

Daniel Buchner: +1 to that

Orie Steele: +1 i dislike non standard url parsing…

Yancy Ribbens: +1 to dedicated query parms instead of introducing a non standard url parser

Manu Sporny: +1 if we do it right…

Daniel Burnett: of course, ok to re-ask questions. I was just pointing out that there has been extensive discussion on this

Dave Longley: I think I’ve been mostly persuaded by Mike’s/selfissued’s perspective on this
… as in, why can’t we just use query params
… and the reasons FOR them has been to cleanly separate spaces / concerns
… as far as I can tell, we’re basically whittling things down to Service redirection
… servers that are using service links will need to be aware of this mechanism anyways,
… so there isn’t quite a reason to shy away from query params for this purpose
… I’m also persuaded by the argument of - we wouldn’t have to modify URL parsers
… so in short, our use cases CAN be satisfied by query params. It won’t be as clean, but not so bad.

Daniel Buchner: ok, so, just to confirm
… the initial use case could be addressed by EITHER matrix params or query params,
… I’m happy to just use query params and close this out

Daniel Burnett: we were hoping we could make some progress on a specific answer
… since this is clearly going to exceed the bounds of our call today
… we’d like to plan to schedule this for another discussion on matrix params. probably a separate call.
… also, we’d like to make some progress on Metadata.
… so lets switch to that

5. metadata

Brent Zundel: https://github.com/w3c/did-core/labels/metadata

Manu Sporny: at the end of last weeks’ call,
… we almost got to consensus on - there’s 3 buckets of metadata
… 1) controller-asserted meta, 2) resolver-asserted meta, and 3) ledger-asserted meta
… when we were talking about ‘created’ timestamp, we were specifically talking about Controller-asserted metadata
… and at the end, on the straw poll, JoeA had a -1 on that
… so, I want to understand why

Joe Andrieu: because that is the only place that the controller can specify when it was created

Dmitri Zagidulin: that’s very close to what the straw poll was proposing

Manu Sporny: let me clarify
… the proposal was: let’s experiment with this in the did:web method;
… if we find it’s generally applicable, we can pull it into the core DID spec
… the other option is - we try it out on the core DID spec, and agree on whether other methods will want that feature
… so, the proposal is - let’s kick it over to did:web for now

Joe Andrieu: I’m not sure we should take it out

Manu Sporny: counter-proposal. We clarify that ‘created’ and ‘updated’ are specifically controller asserting when the /document/ was created or updated
… so we at least clarify the semantics, to avoid confusion

Justin Richer: +1 to clear, narrow semantics

Manu Sporny: if anyone wants to, we can argue about whether it’s a useful general feature

Dave Longley: -1

Dave Longley: I still think it’s mismodeled, it’s a statement about the DID subject right now, i would -1 that change to change the meaning without remodeling it

Joe Andrieu: I can support that.

Manu Sporny: any objections?

Dave Longley: I consider it a statement about the DID Subject right now. If we change the meaning

Ted Thibodeau Jr: “a DID about a thing” doesn’t make sense. a DID identifies a thing. a DID document is about a thing.

Drummond Reed: @dlongley: can we do that just by changing the name of the property?

Justin Richer: +1 to clear, narrow names

Dmitri Zagidulin: we have consensus we’re only talking about document-created and document-upated. If the name is confusing, let’s rename it

Joe Andrieu: +1 to changing name to clarify
… dlongley and I are at distinct odds about whether the subject of the DID is the subject of all the statements in the doc
… I feel quite strongly that - what’s in the DID Document is /how you interact/ with the subject, not statements /about/ the subject
… because that latter is what VCs are.

Dave Longley: insufficient to just change the name

Dave Longley: didDocument.created, didDocument.updated would be fine with me, it’s a separate object

Dave Longley: but not just longer names

Dave Longley: I would object to making longer names
… if we want to embed another object in there, that’s ok
… but that’s my modeling concern

Ted Thibodeau Jr: DIDCreated, DIDDocCreated, DIDRegEntryCreated…

Dave Longley: I want to separate statements about DID Subj and metadata about it

Orie Steele: +1 to object encapsulation

Justin Richer: just to clarify, if we had a “_document” property or whatever, for metadata,
… two questions - one, would you be OK with that, and two, would the group consider it to be able to be queryable from multiple metadata locations

Drummond Reed: +1 to make a clear distinction between statements describing the DID subject and statements describing the DID document.

Justin Richer: what I mean is - if you get that property in the document itself,
… can you ask the DID Resolver to hand that section to you in addition to the resolver/method meta
… basically, can we pull this out and re-use it for resolver results

Dave Longley: the short answer is - I think you’re heading in the right direction, to resolve my concerns

Daniel Buchner: My last month of aimless URL/Matrix wandering, crying out for a final answer, in one image: https://giphy.com/gifs/hr9SUKNQYgEcLykKjp/fullscreen

Dave Longley: lots of bikeshedding is in order, but this is the right direction

Drummond Reed: I’ve been wondering when this was going to come up, to clearly separate statements about the DID Subject, from metadata about the document
… so I’d be for a unified way of doing that

Daniel Burnett: ok, let’s wrap up

Manu Sporny: yes, I’ll put together a concrete PR with a proposal for this
… and then we can revisit

Daniel Burnett: thank you

Daniel Buchner: That’s why they pay me the medium bucks, orie

Daniel Burnett: and just remember, anyone can submit a PR
… Manu has volunteered to write one, but you can also make your own one in parallel
… any other comments?
… Ah, Justin made a PR, thank you.
… ok, next call is Jan 7th
… look out for a Doodle poll to schedule upcoming calls / meetings
… happy holidays