This is the old homepage of the DID Working Group. It is not maintained anymore. The new homepage lives at https://www.w3.org/groups/wg/did/.

DID Working Group Telco — Minutes

Date: 2019-12-03

See also the Agenda and the IRC Log

Attendees

Present: Ivan Herman, Daniel Burnett, Ganesh Annan, Chris Winczewski, Tzviya Siegman, Christopher Allen, Ted Thibodeau Jr, Brent Zundel, joel, Orie Steele, Dave Longley, Phil Archer, David Ezell, Manu Sporny, Alexander Hripak, Justin Richer, Jonathan Holt, Amy Guy, Drummond Reed, Michael Lodder, Yancy Ribbens, Daniel Buchner, sumita, Michael Jones, Adrian Gropper, Dmitri Zagidulin

Regrets:

Guests:

Chair: Daniel Burnett

Scribe(s): Brent Zundel

Content:

1. Agenda Review, Introductions, Re-introductions

2. agenda review, intros

Daniel Burnett: agenda reviewed, anything else folks want to add

Manu Sporny: public keys announcement

Daniel Burnett: anything else?
… anyone here for the first time?

Tzviya Siegman: this is my first time. I’m with Wiley, I’ve worked on the VC group, interested in identity management in particular. I work with Benjamin

Daniel Burnett: thank you, that’s great
… anyone else here for the first time?
… reintroductions, how about Phil, would you be willing?

Phil Archer: formerly W3C, now at GS1, barcode folks, supermarkets, cross-border shipments, our interest here is increasing the security and provability of our identifiers

3. Announcements: Next key format call. Use Cases FPWD published, VCWG Maintenance charter vote

Daniel Burnett: DID Key Management call: https://lists.w3.org/Archives/Member/member-did-wg/2019Dec/0000.html

Daniel Burnett: first announcements: key format discussion will be December 4 at Noon ET

Manu Sporny: during our last public keys call, there were some suggestions for refinements around the language. I have made those.
… I believe the text reflect consensus as of now. My hope is that during the next call we can come to consensus on pulling the PRs in.
… there may be some additional changes around base58 vs base64url. Please read the updated PRs.
… If you have objections to them, please raise those objections before the call.
… My hope is that we can pull the PRs in during the call and then shift to other topics.

Christopher Allen: Want everyone to hold the date of MArch 16-20, Buenos Aires, RWoT

Daniel Burnett: DID Use Cases FPWD Note: https://www.w3.org/TR/did-use-cases/

Daniel Burnett: also, we want to remind everyone our FPWD for Use cases was published.

Daniel Burnett: VCWG Maintenance charter vote: https://www.w3.org/2002/09/wbs/33280/vcwg-2019/

Daniel Burnett: also, the re-starting of the VCWG as a maintainence group. Please remind your AC reps to vote in favor of that group

4. F2F: boat tour sponsor, No. of attendees, topics

Daniel Burnett: See F2F topics/attendance:

Daniel Burnett: we need a sponsor for the boat tour.
… hopefully after we get a count we can get that.
… Microsoft is graciously hosting our location, with meals and snacks
… the chairs put together a draft agenda for F2F topics and attendance
… if you expect to attend, please add your name
… also, if you have any special requirements, add those on the attendees tab
… on the agenda tab, scroll down to the yellow section where you can add potential topics of interest.
… the chairs will figure out where they go in the agenda itself.

Ivan Herman: back to the boat tour, ballpark figure is 20 euros per person
… if you can sponsor it.
… plesae put in attendance so I can call the company and let them know soon how many will be there.

Daniel Burnett: quick check on irc, please indicate if you are planning to be there

Daniel Burnett: I will be there

Ivan Herman: will be there

Brent Zundel: I will be there

David Ezell: will be there

Michael Jones: I will be there

Christopher Allen: maybe

Ted Thibodeau Jr: highly unlikely to be physically present. will try to join remotely by whatever tech is available.

Drummond Reed: will be there

Yancy Ribbens: planning to be ther

Yancy Ribbens: /s/ther/there

Daniel Burnett: one other thing: Mike Jones sent the instructions for getting to the meeting to the mailing list
… they are also on the F2F meeting page

Michael Jones: Instructions on how to get to the Amsterdam meeting location (in Dutch and English): https://lists.w3.org/Archives/Public/public-did-wg/2019Dec/att-0003/Routebeschrijving_SpacesSchiphol.docx

5. Rubric document: when to publish FPWD Note?

Daniel Burnett: https://www.w3.org/2019/09/did-wg-charter.html

Daniel Burnett: We also agreed to publish a rubric. The charter says we will publish a first draft in December
… the chairs feel that is unlikely, especially since this call is scheduled for Christmas day and new year’s day (so it will be cancelled).
… can anyone speak to when they think we might get something together?

Drummond Reed: I am one of the folks helping work on that.
… We have made steady progress, January is pretty likely for a FPWD

Markus Sabadello: There have been regular calls with a small number of people. It still needs some cleanup before publishing as a note
… maybe one or two more calls with that DID Rubric group

Markus Sabadello: Current state of DID Rubric work: https://docs.google.com/document/d/1rYdWiwawWmLOWtHRvT0GzYcdewW_OS9M2mAkENLFdtY/

Daniel Burnett: the rubric is a collection of criteria to help folks determine the level of decentralization of a particular DID method
… Is it decentralized for your use case
… it must be converted into respec
… work on a google doc does not cut it. So until the doc is in respec and the doc is in our github repo it doesn’t count
… doing that will create a first document (not a FPWD) please get that in soon. Thanks for the update

Markus Sabadello: I’m happy to do the respec stuff when needed

6. Matrix Parameters

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

Ivan Herman: See DID parameter names in the core draft

Daniel Burnett: turn the call over to markus_sabadello

Markus Sabadello: quick intro to matrix parameters
… matrix parameters are a syntactic construct we can use in DID urls
… we can across it as a way to reference specific service endpoints
… the DID Core spec doesn’t tell you exactly which fragment to select
… the service endpoint can be specified with the matrix parameters, then the query fragments can be used by that service endpoint
… other examples are versioning, version-time, etc.
… also want to add, we don’t want to overuse matrix parameters, because we also have the idea of resolver options (separate from the DID url)
… that doesn’t need to be a matrix parameter, but could be passed separately to the resolver.
… but they are an interesting construct for adding capabilities to the dereferencing the DID url
… there are currently a number of matrix parameters in the spec already, more are proposed

Ivan Herman: clarification question, from a semantic web background, a url is used for identification. so if two different urls have different parameters, fragments, etc, they are completely different identifiers.
… what do we say? is adding a matrix parameter create a different identifier entirely?

Manu Sporny: I want to bring up some concerns. Matrix parameters, the syntax comes from the early days of the web. They were considered but never really used.
… now we are resurrecting them, but haven’t really said why. What do regular URLs not allow that matrix parameters do?

Yancy Ribbens: +1 to concern of using matrix params

Manu Sporny: every time a new matrix parameter is recommended, it is concerning because we don’t have a good design pattern for when to use it or not. there is still a bit of controversy around when to use them

Orie Steele: Historical context, circa 1996: https://www.w3.org/DesignIssues/MatrixURIs.html

Drummond Reed: Strongly stated as the reason we are using them: we want to be able to control what a DID URL identifies in the authority component of the URI so that we can leave the path, query, and fragment components completely free for DID URL authors to use.

Manu Sporny: as far as Ivan’s question, we have to treat URLs that vary in matrix parameters as different IDs
… they point to a very specific instance of a thing at a particular point in time, which may be different from that thing over all of time. just something to keep in mind

Drummond Reed: there is a very specific structural reason for matrix parameters.
… the general rule of a URL is the scheme is the authority level for the URL. we wanted the path, query and fragment identifier to be free for the methods.
… the matrix parameters are for identifying other resources, which is why they are in the authority component.
… to have control over specification, you are aways identifying some other resource with a different identifier.
… from my standpoint both the motivation and structure are clear. So we should talk about specific matrix parameters

Dave Longley: Each of these URLs is a different identifier. Vanilla DID is the DID subject, adding a matrix parameter refers to something else, possible the DID subject at a certain time.

Daniel Buchner: I was not under the impression that the presence of a matrix param meant that the base DID and the DID with the param are to be seen as two different DIDs

Daniel Buchner: Why is this the case?

Markus Sabadello: @daniel not two different DIDs, but two different URLs

Daniel Buchner: Why can’t a matrix param simply aid in some aspect of resolution of the same base DID

Daniel Buchner: ok

Dave Longley: the original use case for matrix parameters was to allow people to refer to things.. Did Docs have services, suych as the DID subject’s social media stream, or some other service. The DID subject or controller may want to change those services over time.
… the matrix parameters could refer to those services over time, some resource that lives on that server, like facebook or twitter. this would be for creating self-sovereign storage and credential wallets.
… there’s a lot of contextual information in the community

Drummond Reed: @daniel: one bright line with matrix parameters is that they always identify another resource besides the unadorned DID subject. So they should be used for identification purposes, not for controlling resolution.

Dave Longley: another way to think about it is like w3id.org … a perma ID redirection service…

Dave Longley: where the redirection in this case happens via changes to a DID Document’s service’s endpoint

Christopher Allen: Especially what DOESN’T belong

Markus Sabadello: I want to agree with Dave and Drummond on when to use matrix parameters and when to not. You use them when you need a way to identify a different resource.
… for example indicating when something is using a cached copy wouldn’t use matrix params.
… kind of like http headers would be resolver options and also wouldn’t be matrix params

Ivan Herman: these should be emphasized more in the doc.

Drummond Reed: I agree that needs to be added

Daniel Burnett: is that an action on you?

Drummond Reed: Yeahm I guess

Drummond Reed: +1 to Markus’ point that matrix parameters correspond to what would go into an HTTP URL and resolution parameters correspond to what would go into HTTP headers.

Manu Sporny: we need this for DID implementors who don’t have our tribal knowledge. We need to clearly define where they came from, why we are using them now, and some rules around when you should use them and when you shouldn’t

Markus Sabadello: there is a green NOTE box here that explains when to use them, but i agree that should be emphasized more: https://w3c.github.io/did-core/#generic-did-parameter-names

Dave Longley: URL foo refers to some resource … and a DID controller can change the server where that resource lives without the URL having to change.

Dave Longley: ^matrix parameter use case

Adrian Gropper: privacy related question: with a peer did where we have a service endpoint that we don’t want to be a point of correlation
… would the matrix param apply in this context?

Manu Sporny: I think we don’t know yet. It depends on your definition of correlation, etc.

Drummond Reed: I think if you apply what we were saying earlier, if it is only about routing or resolution, that doesn’t change the resource being identified
… so you wouldn’t use a matrix param
… maybe if you’re saying its an anonymous version of the identifer …

Christopher Allen: I wanted to add that it is a privacy concern whether or not the service endpoint receives the entire DID URL or whether they only receive the content hash.
… as you pass this information on, the client doesn’t include the full DID information once they’ve resolved the matrix param.
… transitioning or changing services without the identifier changing. There is a privacy concern that implementors will need to keep in mind

Dave Longley: wrt to services, matrix parameters don’t say anything about service endpoints “receiving” information, they just map one URL to another.

Manu Sporny: this is a bit cart before the horse. We need use cases and modeling before we can do threat and privacy risk modeling

6.1. PR issue #59

Manu Sporny: https://github.com/w3c/did-core/pull/59

Manu Sporny: did:example:1234;key=mykey

Manu Sporny: Let’s pick PR 59, relatively easy. suggestion for a “key” matrix parameter

Markus Sabadello: I agree, let’s look at concrete parameters
… key has been suggested as a way to select a particular key (similar as they way the service endpoint could be identified with a service matrix parameter

Daniel Buchner: Tell me how to pass intermediate state values that can be dropped after anchoring

Orie Steele: -1 seems like a use for JsonPath… https://goessner.net/articles/JsonPath/

Markus Sabadello: example: use did:ex:1234#keys-1 instead of did:ex:1234;key=keys1

Dave Longley: If you want to refer to something that has an id in the document, we already have a way to do that.
… not in my view what matrix parameters are for.
… generally for things outside of the DID doc
… something in the past, or on a different server (redirect)
… I haven’t seen a use case that requires a matrix param just to refer to a key.

Christopher Allen: -1 agree with dlongley.

Justin Richer: +1 … fragments are for internal processing, matrix params are for processing things on their way to the document

Daniel Buchner: I agree. the issue I suggest I don’t think is solved.
… we have to have a way to do it.

Manu Sporny: +1 to Justin_R’s language.

Orie Steele: to clarify: -1 to adding key matrix param, I’d rather see selection in a document built on an existing syntax

Manu Sporny: +1 to what Orie just said.

Daniel Buchner: if there’s any other way to do it. I have a intermediary state where some value must be passed that people can use in lieu of having an actual anchor

Markus Sabadello: daniel is talking about https://github.com/w3c/did-core/pull/84

Christopher Allen: That sounds like something else though

Markus Sabadello: just one more time. key matrix parameter. One small different form using the fragment. the matrix parameter would be independent of the mime type of the did doc
… if we use did urls with fragments, those would depend on the media type of the did doc, whereas the matrix parameter would allow you to refer to a key independent of the media type of the did doc.
… that said, I support closing this PR

Daniel Buchner: manu, Chris: if a DID is not anchored in Bitcoin for 10 minutes, how do I pass a resolvable ID to the RP in the meantime?
It is not an acceptable answer to say “just wait 10-20 minutes”, when clearly we can just allow passage of some values

Drummond Reed: Markus is correct that a “key=” matrix parameter would be a primary resource from a SemWeb standpoint.

Manu Sporny: daniel, add a different matrix parameter… like matrix-unresolved=true or something… we’re talking about a specific PR… key one.

Daniel Buchner: it is not about a boolean
it is about actually passing the values REQUIRED to resolve the DID

Daniel Buchner: In ION’s case, the initial-value is the base64 encoded state of the initial DID document
Same in Element
same in all the methods that use an actual decentralized system
no
not some flag

Justin Richer: This is a prime example of why we need to be having the DID resolution and dereferencing conversation here

Orie Steele: +1 to justin’s point.

Justin Richer: matrix parameters are passed to the resolver, which is a black box as far as this group is concerned.

Manu Sporny: daniel, this is issue #70?

Justin Richer: resolution has different mime types, etc. we should bring resolution into this group.

Drummond Reed: +1 to matrix parameters being passed into the resolution process. That’s also different from fragments.
+1 to bringing resolution into the scope of the WG

Christopher Allen: what is your proposal again?

Dmitri Zagidulin: plus one ot did resolution.
… question, why are we giving keys special treatment?

Daniel Buchner: Chris: https://github.com/w3c/did-core/issues/70

Dmitri Zagidulin: why not a general id parameter

Daniel Burnett: what are the next steps?

Jonathan Holt: +1 to id seems reasonable compromise

Michael Jones: Bringing DID resolution into the WG would require rechartering, as it’s a significant increase in scope

Justin Richer: @selfissued no it is not, there is a phrase in the charter about resolution mechanisms

Establish a deterministic mapping between DID method identifiers and the resolution process used to resolve that DID method.

Markus Sabadello: a generic “id” matrix parameter has been casually talked about, e.g.: https://github.com/WebOfTrustInfo/rwot9-prague/blob/master/draft-documents/did-resolution-v2.md

Manu Sporny: I think we need folks to weigh in on the PRs. Now that you have the background, tell us why the PRs should or should not be merged.

Daniel Buchner: Can folks do a call on the initial-values matrix param?

Markus Sabadello: That is the goal of today’s discussion, to introduce matrix parameters so we can get feedback on the PRs

Daniel Buchner: I see a lot of misunderstanding of what at least our proposed param actually is for/does

Michael Jones: can someone drop a link to the matrix parameters?

Dave Longley: id is obviously more general – but we need a clear use case we can discuss because id would be the same as referring to something in the DID Document using DID#<id>… we need to be able to analyze the bitcoin use case, etc. to really understand the problem and other potential solutions.

Daniel Buchner: Not this call, a sidebar call. That’s what I was hoping to do, a separate call

Daniel Burnett: from a chair perspective, there’s a point of diminishing returns on somewhat inter-related calls. We’ve continued the key format calls. we wanted to get this conversation started and see where things went
… the chairs are paying attention. what we’d like to see if poeple make some effort to comment on the PRs.
… that will make if easier to have the discussion

Amy Guy: +1 doing one thing at a time via extra calls

Daniel Burnett: thanks everyone, remember the key format discussion tomorrow.