DID Working Group Telco — Minutes

Date: 2020-02-11

See also the Agenda and the IRC Log

Attendees

Present: Daniel Burnett, Joel Hartshorn, Manu Sporny, Dave Longley, Justin Richer, Chris Winczewski, Brent Zundel, Markus Sabadello, Irene Adamski, Ivan Herman, Orie Steele, Dmitri Zagidulin, Adrian Gropper, Eugeniu Rusu, Drummond Reed, Christopher Allen, Kenneth Ebert, Daniel Buchner, Joe Andrieu, Sumita T. Jonak, Kaliya Young, Jonathan Holt, Ganesh Annan, Kim Duffy

Regrets: Michael Jones, Phil Archer, Yancy Ribbens

Guests:

Chair: Brent Zundel

Scribe(s): Daniel Burnett, Manu Sporny

Content:

1. Agenda Review, Introductions, Re-introductions

Brent Zundel: (reviews agenda)
… any changes to the agenda? (crickets)

Joel Hartshorn: from advanced research at USAA, working on identity and related topics, now a member of W3C (and shortly the working group)
… waiting on sumita to add me

2. F2F review

F2F Meeting slides: https://tinyurl.com/didwg-ams2020-slides

Brent Zundel: This is a review of the Amsterdam F2F meeting that just happened.

Daniel Burnett: This is going to be a very brief summary.
… We began with a lot of background topics - one of the first was IoT use case.
… Sam Smith talked to us about IoT and needs there… talked about use of DIDs, again based on comments from Sam Smith, Brent presented security issues around DIDs, you can look at slides (getting that link now).

Adrian Gropper: https://docs.google.com/presentation/d/1XI5rrEdBUSYd2tW07GfzOjBkvgKmfeKQyh95Ekl-u8o/edit#slide=id.g76abf93741_68_0

Daniel Burnett: Then we covered possible DID Document links formats… wasn’t just JSON and JSON-LD… also included CBOR, PDF was also discussed (widely used in legal space, lots of interest wrt. PDFs of DID Documents)… we’d need to know how that maps.
… We also talked about extensbility for DID Documents, what are the ways in which people commonly extend JSON using registries and then looked at JSON-LD, since that’s an extensibility mechanism for JSON. The intent was on making sure everyone had same background/knowledge of possibilities on extensibility of JSON documents… registries, JSON-LD, etc.
… The key two points for discussion were extensibility and interoperability.
… We had a long discussion on those two topics - looking at different kinds/levels of interop, all the way from none, to abstract data model, all the way to same syntax.
… There was agreement on interop on being able to do loss-less conversation… exactly what lossless means is not clear, but we’ll get to that.
… We also talked about metadata, the challenge there is that everyone has a different idea of what metadata is. Everytime the Chairs have heard the group talk about this, people say “there is data” and there is “metadata”, but there are disagreements on number of categories… we don’t even agree on categories.
… The intent of the discussion was to write down potential metadata items. Something where you’re not sure where it should go - not trying to agree on whether a particular property is metadata, but cataloging what types of information we’re interested in… how was it generated, DID Controller, DID Resolution? It turned out to be a useful exercise.
… We are tracking this work in a document (link to be placed in here later).
… We are just trying to catalog.
… Next big item was the “Grand Compromise”, what we were leading up to - goal was to have extensibility and interoperability across JSON, JSON-LD, and CBOR. We had a fruitful discussion here, lots could be said, tried to summarize on list… folks might cringe, but I think this is where we are.
… The suggestion is that in any given representation, if you’re just working in JSON, or JSON-LD, or CBOR… you can extend in any way you wish. In JSON, you can extend by just adding properties… however, there is no guarantee of lossless interop unless you ALSO add your property into a registry.
… There is a registry that holds the information necessary for an extension such that it can be mapped to other representations and back. For example, if you extend JSON and add to registry, you also have to provide a JSON-LD context to ensure lossless conversion.
… This in no way limits someones ability to do an extension… but the second you want LOSSLESS GLOBAL INTEROP, you need to use the registry.
… Yes, there are details that need to be worked out… but that was basically the grand compromise. At that point, the group felt they could move forward.
… Once we got consensus on that… we talked about document structure and refactoring, based on work done at F2F based on work done by Drummond, we just needed to restructure based on the decisions made at F2F.

Daniel Burnett: Moving on to matrix parameters, there was a group of people that felt we need them and others that felt we didn’t. Those that feel like we need matrix parameters, need to come up with use cases. Those that feel like we do not need matrix parameters, need to explain how the pro-matrix-parameters folks use cases can be solved w/o matrix parameters.
… So both groups need to do some work.

Dave Longley: +1 to requiring use case and to requiring people to show how it can be done without matrix parameters if that is argued

Dave Longley: (i think that’s the right approach for all of these sorts of issues)

Daniel Burnett: We talked about DID Resolution work because there is a relationship to the work we’re doing - it’s not clear that we’ll move faster if the DID Resolution work will move into this group because it’s many of the same people. There are some Charter/Scope/IPR issues around that. However, there are some people that believe that this group should define the contract between DID Resolution and work we have control over in this group.
… Not everyone agrees on that, but it’s a topic of discussion. That section could be done as a non-standards-track NOTE - same as rubrics, it doesn’t tie us to schedule, no IPR, allowing document to progress, and making it simple to pull it in as a standards-track item if we can recharter WG to do that. Ivan mentioned that having that work as an information note would provide additional incentive to W3C to bring it in as a charter work item.
… Did I miss anything major?

Joe Andrieu: There was some confusion on matrix parameters… service specs got bundled into that - folks that weren’t there, might be worth noting for them, we also have included service endpoints in that discussion.

Manu Sporny: juan c wrote up a good perspective on the f2f meeting
… Juan wrote up a good article on the F2F meeting - https://medium.com/spherity/worldwide-web-consortiums-w3c-did-working-group-meeting-bf6c8cef1751
… may be useful for people who tweet, etc.

Justin Richer: for extensibility compromise, don’t be worried. we are trying to solve what interop means for this group and this spec.
… For the extensibility compromise, one alarm that I saw in the channel - one of the things we discussed is that we’re really trying to solve the definition of “What interop means for the group” and we need to clarify in text.
… Dan’s excellent summary was too short to capture that.
… we need that written down. Dan’s summary doesn’t capture all the subtle details.
… /me I thought I was

Orie Steele: justin: interop is hard, we need to define it in text.

Daniel Buchner: question on matrix params. if i want to do something in 2 months, can i just use an obfuscated URL parameter?

Justin Richer: I had a good feeling of what we mean as “interop” when we left the F2F – in terms of what I’m allowed to do and what I can expect when I plug in two unrelated off-the-shelf things that are both compliant

Daniel Buchner: are URL parameters still in, or are they out?
… can i just use URL parameters without reservation

Drummond Reed: Daniel, the short answer is that the questions around matrix parameters have still not been settled. We want to get there ASAP.

Markus Sabadello: after f2f joe and i have assignment to work on google doc to describe a use case unique to matrix params

Daniel Buchner: OK, so I was hoping to get a “Yeah, totally fine, URL params are perfectly safe and you can trust that nothing about them will change from under you”

Markus Sabadello: joe and I will share with group when ready

Daniel Buchner: It’s getting down to decision time for us, so I MUST make a decision here

Manu Sporny: i doubt the group will remove query params. you could hack something and it might be what we do if we remove matrix params.

Daniel Buchner: OK, thank you Manu!

Manu Sporny: pretty sure that won’t go away as option.

Orie Steele: If MS shipped matrix params… they would not got away either ;)

Daniel Burnett: Time to move on :)

Brent Zundel: Agree, we need to move on.

3. New repos: Registry, Impl. Guide

Brent Zundel: manu sent an email with links to repos and proposals

Proposed resolution: Adopt https://msporny.github.io/did-core-registry/ as an Editors Draft for the DID WG’s DID Core Registry. (Brent Zundel)

Brent Zundel: as meniotioned we decided on a registry for extensible interop. Manu has created outline for such a registry
… proposal to start work here

Daniel Burnett: I wanted to point out that we haven’t figured out structure of registry or anything, don’t panic with this document, we need a place to start working on registry/registries.

Brent Zundel: This is a place to begin development.
… this is a place to begin development. it’s a starting point

Jonathan Holt: still processing. I haven’t had a chance to process this, can we take a week to understand it

Manu Sporny: jonathan wants to table proposal until there has been time to review.

Drummond Reed: +1 to proceeding with the Registry document

Manu Sporny: I disagree. There has been plenty of time to review since the f2f, it’s a starting draft with no commitments, there is no reason to delay.

Orie Steele: +1

Daniel Burnett: +1 to moving forward

Manu Sporny: +1 to proceeding w/ registry document.

Eugeniu Rusu: +1

Drummond Reed: agree with manu. Jonathan, we had extremely thorough discussion at f2f. It is not the only way to extend, but it is the interoperable way to do so.

Proposed resolution: Adopt https://msporny.github.io/did-core-registry/ as an Editors Draft for the DID WG’s DID Core Registry. (Brent Zundel)

Ivan Herman: +1

Dave Longley: +1

Orie Steele: +1

Manu Sporny: +1

Daniel Burnett: +1

Drummond Reed: +1

Jonathan Holt: -1

Brent Zundel: +1

Eugeniu Rusu: +1

Daniel Buchner: +1

Kenneth Ebert: +1

Joe Andrieu: +1

Jonathan Holt: I just need to get my head around a registry in a decentralized platform

Kim Duffy: +1

Joe Andrieu: we can’t make everything perfectly decentralized. we can accept centralization of what properties we will allow.
… operationally it is still fully decentralized
… it lets us agree on what properties mean

Justin Richer: +1 to JoeAndrieu ‘s point

Brent Zundel: agree with Joe’s comments

Daniel Burnett: +1 JoeAndrieu

Dave Longley: +1 to Joe

*Jonathan Holt: Just need time to process. Haven’t attended the f2f I’m just slow on the upkeep

Dave Longley: feel free to bring any concerns to the group after processing

Manu Sporny: if jonathan wants time to process, you will have that time while we work on the document. it will be a while before we publish as any formal doc
… ‘not enough time to review’ is not a good enough excuse. minutes were released in a timely manner almost two weeks ago.
… it is not acceptable to stand in the way of the entire group this way.

Daniel Burnett: Manu is correct, we understand that not everyone was there, this is always going to happen, there will always be someone that’s not there. As Manu mentioned, the minutes have been out for more than a week, which is the stated minimum requirement that we have in our process.
… There is nothing we’re doing right now that allows you to approve publication of a document.
… This was viewed as an acceptable compromise by a very very very large percentage of the group. I understand that you need more time and are a -1, I’m going to ask the question as Chair… are you going to raise a formal objection at W3C if we proceed?

Jonathan Holt: I did attend WebEx at 3am… I haven’t had a chance to read it… short enough, parameteres, property registries, then I’m content.

Daniel Burnett: I will make one comment - none of those details were agreed to in the meeting. That’s what we need to work on.

Jonathan Holt: Reading the document right now… where does this registry live?

Brent Zundel: All to be determined.
… all to be determined once we start.

Jonathan Holt: Ok, no objections.

Resolution #1: Adopt https://msporny.github.io/did-core-registry/ as an Editors Draft for the DID WG’s DID Core Registry.

Action #1: create the did-core-registry repo (Ivan Herman)

Brent Zundel: the repo is where all of this conversation will occur.

Dave Longley: +1 to ChristopherA, myself as a supporter of permissionless, decentralized extensibility, i have no reason not to support creating a place for this document

Brent Zundel: right now there isn’t even anything to object to - it’s an empty shell

Proposed resolution: Adopt https://msporny.github.io/did-imp-guide/ as an Editors Draft for the DID WG’s DID Implementation Guide. (Brent Zundel)

Ivan Herman: +1

Dave Longley: +1

Manu Sporny: +1

Kenneth Ebert: +1

Orie Steele: +1

Eugeniu Rusu: +1

Joe Andrieu: +1

Brent Zundel: implementation guide is a place where we can discuss KERI proposal from Sam and other security and other topics

Daniel Burnett: +1

Drummond Reed: +1

Joel Hartshorn: +1

Christopher Allen: +1

Adrian Gropper: +1

Daniel Burnett: Just wanted to point out why this proposal is happening… There are things that need to be written down, but they don’t belong in the core spec.

Kim Duffy: +1

Daniel Burnett: Some of the broader questions a round security… use of the specification, belongs in an implementation guide. That’s all that this is, this will eventually be a WG note, there is no place to write these things down right now and that’s what this proposal is meant to address.

Resolution #2: Adopt https://msporny.github.io/did-imp-guide/ as an Editors Draft for the DID WG’s DID Implementation Guide.

Action #2: create the did-imp-guide repo (Ivan Herman)

Brent Zundel: not hearing any objections

4. Document restructuring PR

Brent Zundel: https://github.com/w3c/did-core/pull/186

Daniel Burnett: https://github.com/w3c/did-core/pull/186

Brent Zundel: restructures document so we can begin to put in content. No substantive changes at all.

Justin Richer: i raised a comment on the PR. Not objecting to it, just asking what we need in addition to this. I would like to see something around producers and consumers being included. Otherwise great.

Daniel Burnett: +1 to follow-on PR

Dave Longley: +1 to do that as a separate PR

Brent Zundel: can this be a follow-on PR?

Drummond Reed: +1 to using the terms “Producer” and “Consumer” and +1 to doing it in a subsequent quick PR.

Justin Richer: yes. if it is handled quickly, okay. Want our discussion to happen in those terms as soon as possible.

Dave Longley: and to understand that it means “producer” and “consumer” of the data model

Ivan Herman: understand and agree that current PR means just a restructure with no content changes. Doc as it is now is difficult to read to understand what DIDs are. As soon as we merge it becomes offcial to outside world.
… can we put temporary warning that we are the middle of a major restructure so be prepared for changes over the coming weeks

Orie Steele: +1 for not making all the changes in a single PR…

Manu Sporny: justin’s changes sound like good ones. would prefer to make those changes as follow-on PRs. Goal of this PR is to make the core better so we can parallelize all the other changess that need to happen

Brent Zundel: +1 to Orie’s +1

Justin Richer: +1 – as stated in my comment, it was my intent that most of them be addressed in follow ons as we go forward

Dave Longley: +1 to get things in the right place so we can work in parallel on separate sections

Manu Sporny: if we put it all in one PR then everyone will want to add ‘one more littel thing’

Justin Richer: to be clear, that is not at all what I was asking

Drummond Reed: +1 to making iterative improvements

Manu Sporny: we can make iterative improvements. Two PRs suggested:
… producer/consumer, let’s put into separate PR. I suspect we will need to discuss whether there are conformance changes as well, so a bit more complex.
… ivan is right about flow. Front matter is okay, but the rest is not. Specifically didn’t change any content to avoiid claims of biased mods.
… would be good to add disclaimer at the top, but i don’t think we should do anything else to this PR

Proposed resolution: Merge PR #186 to implement structural changes to the specification as discussed during the recent DID WG F2F meeting, as soon as a note is added which informs readers that further changes are underway. (Brent Zundel)

Ivan Herman: +1

Dave Longley: +1

Orie Steele: +1

Daniel Burnett: +1

Eugeniu Rusu: +1

Adrian Gropper: +1

Drummond Reed: +1

Manu Sporny: +1

Brent Zundel: +1

Markus Sabadello: +1

Joe Andrieu: +1

Kenneth Ebert: +1

Kim Duffy: +1

Christopher Allen: +1

Resolution #3: Merge PR #186 to implement structural changes to the specification as discussed during the recent DID WG F2F meeting, as soon as a note is added which informs readers that further changes are underway.

Brent Zundel: not hearing/seeing any objections

Joe Andrieu: mikej and I have discussed what the name of the JSON section should be

Manu Sporny: you and Mike and others who want to discuss should probably start a new PR.
… it’s editorial beacuse it doesn’t change any normative statements.
… personally agree that there is no such thing as “pure JSON”, just JSON.

Orie Steele: There is no such thing as Pure JSON, but i don’t really care.

Brent Zundel: get your PRs in. Once 186 is merged we can really move ahead.

Jonathan Holt: working on the CBOR section. what would makej it more readable?

Drummond Reed: +1 to Jonathan working on the CBOR section

Jonathan Holt: CBOR is tough to read.
… anyone else have suggestions for making it morec readable?

Orie Steele: Start by adding anything… PRs gather feedback.

Manu Sporny: +1 to Orie

Brent Zundel: not with CBOR, but I have found that it is worth just writing down my thoughts in a PR for others to improve upon
… so getting a PR in sooner is better.

Manu Sporny: s/+1 to Orie/manu: +1 to Orie/

Jonathan Holt: ?CDDL

Justin Richer: CDDL is used in the COSE specs to great effect. Also, producer/consumer/conformance strucuter will have a big impact on how we manage serializations.

Jonathan Holt: “Concise Data Definition Language”

Jonathan Holt: cool

Justin Richer: keep in mind that the doc may require a different organization of the info than you have had in mind.

Manu Sporny: Yeah, I wouldn’t write that section yet…

Joe Andrieu: cheers, all

Brent Zundel: thanks all for being engaged and passionate.

Manu Sporny: wait until we have the JSON / JSON-LD sections done.

Irene Adamski: Thanks everyone!

5. Resolutions

6. Action Items