DID Working Group Telco — Minutes

Date: 2019-10-29

See also the Agenda and the IRC Log

Attendees

Present: Daniel Burnett, Ivan Herman, Yue Jing (景越), Brent Zundel, David Trang, Dudley Collinson, Michael Jones, Manu Sporny, Ted Thibodeau Jr, Markus Sabadello, Adrian Gropper, Kyle Den Hartog

Regrets:

Guests:

Chair: Daniel Burnett

Scribe(s): Markus Sabadello, Manu Sporny

Content:

1. Agenda Review, Introductions, Re-introductions

Daniel Burnett: Today we will give notification of the winning specification short name, then we will talk about FPWD of main spec
… We might also talk about the Use Cases doc
… Then main topic will be key representation
… (We won’t make any decisions about this)
… If there’s more time, we can go over PRs

Michael Jones: FYI, I read the entire Use Cases doc and filed some issues at https://github.com/w3c/did-use-cases/issues/

Daniel Burnett: Any change suggestions for agenda?

Michael Jones: I read the whole Use Cases doc and raised a number of issues; we could assign owners if there is time

Daniel Burnett: Let’s see, we want to keep enough time for the main topic
… Other suggestions for agenda?

1.1. Introductions

Daniel Burnett: Yue, would you like to introduce yourself?

Yue Jing (景越): I come CAICT, China. We’re working on different identifiers, Internet of Things, blockchains
… It’s my first time in a W3C WG, thank you

Daniel Burnett: Anyone else joining for the first time? I think not

1.2. Reintroductions

Daniel Burnett: Manu, want to reintroduce yourself?

Manu Sporny: I’m CEO of Digital Bazaar, we’re working on standardization of payment processes and identity technologies. I’m co-editor of DID, VC, and other specs.

2. Specification shortname (Issue #76)

Daniel Burnett: https://github.com/w3c/did-spec/issues/76

Ivan Herman: actually, the issue is now https://github.com/w3c/did-core/issues/76 :-)

Daniel Burnett: Regarding DID spec short name, the winner is “did-core”

Daniel Burnett: This short name will appear in the URL to the permanent published document (the primary specification)
… We should use the name everywhere now (web, Github, etc)

Ivan Herman: On Github there’s also a redirect from the old name to the new

Daniel Burnett: Any other comments?

3. FPWD (Issue #68)

Daniel Burnett: https://github.com/w3c/did-core/issues/68

Ivan Herman: See PR #87 for the FPWD text

Manu Sporny: See also Current FPWD proposal

Daniel Burnett: In this issue, we’re discussing publishing an official “working draft” .. We currently have an “editor’s draft”
… Working draft does not imply group consensus.
… Publishing the first working draft (FPWG) is important since it starts some IPR processes
… To do this, we won’t have an official “vote”, but try to get consensus from the group
… The editors put together a document that would become the FPWD (asides from minor editorial fixes)
… We received one comment with concerns about the document, by selfissued (Mike Jones), do you want to speak about it?

Michael Jones: I raised a concern because since our last call I read the charter. The charter says we will create a Use Cases document with req’s for the technical specification.
… It’s important to have the Use Cases first that explain why we’re doing what we doing
… At TPAC I heard a reference about the Use Cases document, but no time has been spent on the WG to go over UC issues.
… UC document should not be an afterthought. It should inform the technical specification.
… Otherwise we may be condoning neglect of use cases.

Daniel Burnett: “Neglect” may be too strong, but you are right that UC are important and that we haven’t spent time on it yet.
… It’s reasonable to expect that we spend more time on UC upfront before focusing only on the main spec
… The group does need to begin to work on it.
… Topic today is, can we agree to publish FPWD of the core spec.
… We should consider FPWD of UC doc as well.

Michael Jones: See issue #8 in the UC repository

Manu Sporny: I agree UC document is important. I think so far the WG had higher priority items to address.
… Some time has been spent on UC. The current version reflects that, see the reference from the SOTD It’s one of the better UC documents out there compared to other groups.
… I don’t think it should be a gating factor. It’s easy to link from core spec to UC document, so readers are aware of it. This is fine for FPWD to point to documents that are in-process.
… I think people won’t get confused if FPWD of core spec points to in-progress UC document.
… Let’s not gate FPWD by this.

Michael Jones: I disagree with manu’s assertion that UC document is relatively mature.

Manu Sporny: I said “mature for a FPWD”

Michael Jones: I’m reading this with fresh eyes.
… There is a lot of tribal knowledge that is assumed. New readers of the UC document may be confused by not knowing certain things.
… Therefore I raised several issues about things that are not clear to new readers.
… Can we get a gentlemen’s agreement to get to FPWD also for the UC document?

Ivan Herman: I’m also a new reader without the tribal knowledge. I still think we should publish FPWD of the core spec, but FPWD of UC should also be prepared soon (e.g. by end of November)

Brent Zundel: +1 to publishing use cases during November

Daniel Burnett: What I’m hearing is Mike would be okay with publishing FPWD of core spec, if the group has a gentlemen’s agreement to publish FPWD within November and work toward that.

Michael Jones: Agreed

Daniel Burnett: Does anyone object to the intent of the group being publishing FPWD of UC document within November, and working toward that goal (working on Github issues, allocating time on WG calls for this)?

Dudley Collinson: +1 and also happy to participate in use case review

Manu Sporny: I’m trying to formulate a single proposal that addresses both FPWD of core spec and selfissued ‘s requests about UC document.

Ivan Herman: I would prefer three separate, crisp proposals, rather than having everything in a single proposal/resolution.
… We can have them now and vote for them, that’s easier from an admin perspective

Ivan Herman: +1

Daniel Burnett: We already agreed to work on UC document, and we already on Echidna.
… So we should only have to vote on publishing the DID core spec as FPWD

Proposed resolution: Publish the DID Core specification as a FPWD with a short name of did-core within the month of November. (Manu Sporny)

Ivan Herman: +1

David Trang: +1

Ted Thibodeau Jr: +1

Brent Zundel: +1

Manu Sporny: +1

Adrian Gropper: +1

Dudley Collinson: +1

Daniel Burnett: +1

Kyle Den Hartog: +1

Yue Jing (景越): +1

Daniel Burnett: Any suggestions to modify the proposal? Not hearing any. Please respond.

Markus Sabadello: +1

Michael Jones: +1 to trigger the IPR process

Daniel Burnett: Seeing no objections. This is resolved.

Resolution #1: Publish the DID Core specification as a FPWD with a short name of did-core within the month of November.

Daniel Burnett: Is there anyone who believes that we must do one of the other two proposals today?

Manu Sporny: We’ll merge and create a static copy for FPWD

Ivan Herman: Formally speaking, we have to wait 1 week before a resolution is accepted.
… I’m aiming for publishing this on Thursday 7th of November.

Daniel Burnett: If there are objections, we encourage people to raise them within 48 hours.

Ivan Herman: As soon as I have the static version, I will start the admin process.

Manu Sporny: Will try to create the static copy today.

4. Key representation (Issue #67)

Daniel Burnett: https://github.com/w3c/did-spec/issues/67

Daniel Burnett: This is the primary issue; other issues are related to it.

Manu Sporny: We’ve had the discussion about key representation before and coming back to it with new information.
… I made an attempt to summarize what this is about.
… We have some use cases and requirements that hadn’t really been summarized before, so this is what my comment is trying to do.
… We’re trying to represent cryptographic information (together with other information) in DID documents, so it can be consumed by applications.
… Three categories of applications:
… 1. Three categories of applications: 1. Outside our scope (not our business to define key formats, but we still want to encourage interop)
… 2. Keys used by the DID registry (internally e.g. to control the DID document). This also includes things other than keys
… 3. Applications that are somehow in the middle. E.g. authentication. These same mechanisms may be used by the DID registry and also outside.
… I think there’s a lot of the back and forth with different objectives.
… One argument: Everybody standardizes on one key format, this simplifies implementations.
… Other argument: It would be nice to have one representation, but the reality is that we don’t. There are existing implementations that have considered this but decided not to pick a single format.
… So today we have multiple different representations of keys and we have to acknowledge that, and transformations between formats are happening

Michael Jones: A friend in the industry said: ‘Making choices that don’t matter. To get interoperability you have to make a choice. It doesn’t matter so much what you choose, but it’s important that you do choose.’
… I look at what’s been happening so far, and I think nobody makes any choices. Everything seems loose, the union of what everyone wants, but in the end this doesn’t serve anyone

Kyle Den Hartog: Question for markus_sabadello about your comment in the Github issue.

Markus Sabadello: The question you’re asking about the comment in IRC… I was trying to argue… size of different key representations, issue for certain did methods, registries, size of representation too large… whatever representation or format we use, is not necessarily what is stored in the registry. The way a lot of DID Methods work, they don’t store DID Document internally… it is a result of resolution process.
… Bitcoin, Ethereum, they don’t actually store DID Document on the ledger, whatever we agree on, doesn’t mean, doesn’t impact how DID Documents get implemented internally. DID Document may or may not use DID Document internally.

Kyle Den Hartog: Thanks Markus, that makes me feel like my point is more a moot point and is resolved from the registry perspective. At the application layer this has larger implications.

Manu Sporny: I wanted to focus on real-world repercussions of this discussion. I agree with selfissued that DID spec writers are not forcing one way of doing it
… There was a heated discussion on forcing one key format vs. allowing multiple formats
… Both choices could result in more complexity for implementors
… Many implementations don’t use JWK today and have chosen not to use it. They use e.g. binary encodings of keys. I think that’s terrible, but that’s how it is.
… E.g. openssl is not going to support JWK, therefore if DID document requires JWK, transformations have to be implemented.
… Example of Ed25519: Most people just use raw binary encoding
… In Bitcoin and Ethereum communities, people use different formats even though the key types are the same
… This is how the ecosystem has developed. Attempts for people to agree on a single format have failed
… Let’s support JWK and keep trying to get people to use the same format. But also recognize that this will increase, not decrease, implementation burden

Michael Jones: Clarification question: We’re only taking about public key representations, right?

Manu Sporny: Yes

Michael Jones: About your complexity argument: If you force a single format, translation has only ever to happen once (between other format, and the single support format)
… In the current ecosystem however, transformation is more complex since every format has to be transformed to every other. This gets worse with additional formats
… Therefore, making one choice, the overall translation problem gets easier
… We could say that for known key types (RSA, EC) we could choose JWK and one or two other common formats, but also state that we will accept no other
… I don’t like that, but it’s better than being completely open-ended

Daniel Burnett: I think standards is about writing down where you can get agreement. Let other things wait
… Even if you have to leave some things open (they may become clearer over time)

Manu Sporny: Agree with selfissued, trying to push JWK isn’t going to result in end state selfissued wants. I also want everyone to use the same key format. But in reality I don’t think we will be able to change that.
… Agree with selfissued to do the next-best things: E.g. accept 2 most popular formats but then don’t allow others. Aggressively narrow the list, stop proliferation

Kyle Den Hartog: I was confused by selfissued ‘s comments about RSA and EC key types. But I thought we’re talking about different serialization formats, not key types.
… +1 to manu (which was +1 to selfissued)
… I think we should restrict formats, not key types (e.g. quantum crypto will become important)

Daniel Burnett: Perhaps we schedule an additional dedicated call for this topic

Kyle Den Hartog: +1 to that

Michael Jones: My point was that for a given key type (e.g. RSA) we should choose 1 (or maybe 2) supported representations for this key type.

Manu Sporny: Agreeing more and more with selfissued. Another wrinkle is something markus_sabadello highlighted on the last call: Don’t assume that DID documents will always be encoded as JSON.
… Like in the VC spec, we separate the abstract data model from the concrete format. E.g. you could represent a DID document in a binary format like CBOR.
… Therefore we should keep this in mind when talking about public key formats.
… I think JWK can also be represented in CBOR, but let’s keep this in mind

Michael Jones: This is a fine point. I find multibase particularly offensive, since that format itself refuses to make a choice;

Daniel Burnett: We don’t have enough time to resolve this, but I feel we’re getting to something. It may be best to have a dedicated call with those who are interested.

Manu Sporny: You can do multibase, but force ONE encoding… you do that because you can’t predict 10 years in the future… who thought that base58 would be a thing… but it is

Kyle Den Hartog: I’d be interested to join this

Manu Sporny: We need more than selfissued and kdenhartog and the editors to resolve this. We have to make sure we get consensus of the whole WG.

Manu Sporny: Summary of where we are right now…

Summary: It sounds like we’re closing in on a path forward, which is to allow multiple types, but limit to perhaps 2 mechanisms for each key type… for example, for RSA, PEM encoding and JWK encoding… While this doesn’t get us down to one key format, it does limit an explosion of key formats. We will need to have further calls to ensure that we’re taking all use cases and requirements into account, and those calls will be scheduled by the Chairs and Staff. We need to make sure that we have more than a handful of people providing input (Manu Sporny)

5. Resolutions