The DID SPEC is Perfect! Change my mind.
The DID Spec is Perfect! Change My Mind.
Tuesday 2F
Convener: Dave Huseby
Notes-taker(s): Drummond Reed
Tags for the session - technology discussed/ideas considered:
Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:
David Huseby
Security Maven, Hyperledger
The Linux Foundation
+1-206-234-2392
dhuseby@linuxfoundation.org
Dave is one of the primary proposers of the did:git method and one of the primary implementers, together with his team, at the Linux Foundation, where he is Security Maven for Hyperledger.
In implementing the DID spec, he found overall that it allowed too many ways to do things, and it did not have enough guidance about critical points that developers need to know for interoperability. He has published a summary of his feedback here:
https://hackmd.io/@dhuseby/S1APLEDLH
He felt that the spec is overly reliant on JSON-LD as the serialization format, and that DID documents should be specified in a way that can be serialized using JSON-LD but also other formats such as CBOR.
He had a number of major areas of feedback. He broke them into four major suggestions and felt that the DID spec would ideally be broken into four specs to reflect these suggestions:
- One spec to just define the ABNF for DIDs and DID URLs.
- One spec to define DID documents.
- One spec for how to define a service endpoint.
- One spec for how define a public key or other type of cryptographic material.
With regard to this last point, Dave was particularly emphatic about the importance of being able to describe a key precisely and completely, including:
- Encoding
- Usage restrictions
- Issue date
- Revocation status
He mentioned JSON Web Keys and COZY Keys as examples of complete key description specifications.
In particular he wants to be able to Wants to be able to publish pre-keys—the first half of a Diffie-Hellman key exchange.
Justin Richer agreed with Dave that the spec needs to be much more prescriptive in order to drive true interoperability. Every feature needs to be justified. "The purpose of the spec should be to define the core stuff that everyone does."
Dave said that there was one particularly glaring mistake: the value of a key can currently be be either a JSON string or a JSON object. That is a nightmare. Dave said he wants to be able to use Lint on a DID document.
We discussed the role of registries, e.g., the current DID Method Registry at the W3C Credentials Community Group. We agreed there should be registries for:
- DID Methods
- Service Endpoint
- Key Descriptions
- These registries could either be maintained by an established body like IANA or by new registry services at W3C that Drummond said were being proposed at W3C TPAC by David Fisher of Apple.
Wayne had a suggestion he called "Implied DIDs" that could be based on OAuth identifiers such as
did:oath2:login.microsoft.online-john.doe@live.com
He emphasize that no private keys are involved, and this could help with mass adoption.
Drummond promised to take all of this feedback to the new W3C DID Working Group, which Dave and Justin plan to join, and invited all the rest of the attendees to join W3C and the Working Group if they wished to be part of the process of finalizing the spec, which should be at feature freeze in the next 6 months.
