One foundational key representation please

[travisleithead]

This is part of the feedback from Microsoft's ballot response to the DID Core spec transition to REC AC review. As it pertains to future work on that spec, @iherman encouraged me to file it here for consideration in the charter process (as applicable). See also w3c/did-imp-guide#42, w3c/did-wg-charter#13.

Microsoft believes that interoperability of the spec could be improved with a single foundational key representation. We would prefer implementers use JSON Web Key for representing cryptographic keys. We believe JSON Web Key would be a great baseline of support that could be extended with additional formats. Any additional formats included in the spec text should include the appropriate usage context. See related section of the DID-Core spec, Section 5.2.1.

[peacekeeper]

Thanks for this and the other two suggestions! I think with regard to this topic, the current spec is not so far from what you are proposing, insofar as it already defines publicKeyJwk as one of two properties for verification method formats.

The DID WG had several dedicated calls about key formats. Early on, the idea was that the specification would support JWK, plus formats that are common for a given key type (e.g. PEM for RSA, Base58 for Ed25519, Hex for sep256k1). Even though the specification doesn't mention properties such as publicKeyHex or publicKeyBase58 anymore, they are still quite common in various DID method implementations.

Personally, I think we found a good balance in the spec, i.e. publicKeyJwk and publicKeyMultibase are defined, and others can be used as extensions. But your proposal of having a single foundational key representation would definitely also have advantages.

[iherman]

The issue was discussed in a meeting on 2021-08-31

• no resolutions were taken

View the transcript

### 6. Next DID WG Charter _See github issue [did-wg-charter#11](https://github.com/w3c/controller-document/issues/115), [did-wg-charter#12](https://github.com/w3c/did-imp-guide/issues/42), [did-wg-charter#13](https://github.com/w3c/did-wg-charter/issues/13)._ > *Brent Zundel:* [https://github.com/w3c/did-wg-charter/issues](https://github.com/w3c/did-wg-charter/issues) **Brent Zundel:** the reason this is a longer topic is due to issues that have been raised that we should discuss … the goal is to go through them briefly, then I encourage WG members to respond in the issues … the first issue is "one foundational key representation please" from Microsoft. … this has received extensive discussion in the WG already **Drummond Reed:** folks are still encouraged to reply in the issue, especially with citations to our earlier discussions of those topics. **Brent Zundel:** Microsoft is recommending non-normative guidance on cross-compatibility between JSON and JSON-LD … this sort of non-normative guidance would, in Brent's opinion, be in scope under the new charter … but would also retrod well-trodden ground … Microsoft would also like the WG to take the challenge to define a universal, mandatory-to-implement DID method … this would take the WG out of maintenance mode **Joe Andrieu:** There was a proposal to include `did:web` and `did:key` in the charter, but that was not done in order to keep it a maintenance WG … so this could be a chance to do that **Kyle Den Hartog:** `did:key` could work, but worried that `did:web` would derail the conversation … and not sure what would be the third **Brent Zundel:** The question of what DID methods could reach consensus would be challenging … `did:peer` might also be a candidate that could reach consensus **Ted Thibodeau Jr.:** Going through the exercise of determining which DID methods could become normative could be a work item for the W3C Credentials Community Group … but the DID Rubric might be a better tool for evaluating this **Drummond Reed:** likes the idea of looking at the DID Rubric and taking an evolutionary path

[msporny]

In general, the topic of JSON Web Keys and cross-format compatibility guidance was a topic of regular debate in the Working Group and the result of that debate was the current contents of the DID Core specification. If further language is desired, it is suggested that those wanting that language to exist in the specification submit a PR that can be reviewed and further debated by the Working Group.

While we have proponents in the group that are arguing for one key format, there are also proponents (such as my company) where JWK does not meet a number of use cases and requires more complex processing than some of the more modern key formats (such as Ed25519). The group ended up standardizing two ways to express keys... the "broad/verbose" approach, which is expressing a JWK... and the "narrow/compact" approach, which is publicKeyMultibase. The first should fit use cases where key expression size and format (both storage size and algorithmic processing) is more complex. The second should fix use cases where key expression size and format is more compact and simpler -- there are legitimate use cases where this matters, such as compression of the signed message and public keys into QR Codes that need to be expressed using less than 250 bytes of data AND where the signature can be verified offline that the JWK key format is not capable of addressing.

Our company would be a -1 to any proposal that attempts to remove features that we need for our customers, including one that attempts to remove publicKeyMultibase from the specification and Linked Data Integrity in general.

[dwaite]

While we have proponents in the group that are arguing for one key format, there are also proponents (such as my company) where JWK does not meet a number of use cases and requires more complex processing than some of the more modern key formats (such as Ed25519).

1. A minimal Ed25519 key in JWK is an Object with a fixed type descriptor, a fixed format descriptor, and the X value.
2. If you want it in COSE key format, it is a Map with a fixed type descriptor, a fixed format descriptor, and the X value.
3. A multibase multicodec key is going to be a type descriptor, and the X value. There is also an additional encoding format parameter from multibase, which may be variable in publicKeyMultibase

If the argument is to support another, more compact format which supports multiple keys that was designed for simpler constrained environments, I would suggest looking at COSE as a base rather than multicodec. As COSE has been a published RFC for four years, it is far less challenging to normatively reference.

Specifically around COSE - one can limit which parameters are defined in acceptable keys to the three above. One also can say it must be encoded deterministically, at which point an Ed25519 key would effectively have a fixed binary header on the (otherwise unencoded) binary X value.

With respect to multibase, I don't understand the desire to use it. The textual encoding of binary data is just about always context-specific in standards. Variable encoding just increases the complexity of parsing and the chance of interoperability issues.

E.g. In a JSON/JSON-LD DID document key format, you would typically mandate base64 because it is the most efficient encoding that is compatible with the text format it is embedded within. In a DID method specification which embeds binary data in the URI, you might instead choose to mandate one of the base58 schemes - trading off some encoding efficiency for OCR/human transcribability.

But what benefit comes from overriding that base decision in the spec (e.g. my implementation doing base32 instead of the base58 recommendation)? I have a hard time understanding what benefits would override the interoperability consequences.

[brentzundel]

Addressing this would be beyond the current scope of the draft charter. Defining this would be something a future DID WG could address, and it pertains to the core data model. I am going to transfer this issue to that repository.

[pchampin]

This was discussed during the #did meeting on 12 September 2024.

[msporny]

This issue has been transferred from did-core since the key representations are talked about in this specification and did-core will build on top of this specification.

[msporny]

PR #120 has been raised to address this issue. This issue will be closed once PR #120 has been merged.