Leverage existing RFC7517 to specify cryptographic key about did-core HOT 6 CLOSED

Tagging @awoie as he's still not in the W3C group (this was an issue in Verifiable Credentials WG as well, IIRC). @iherman any chance we could fix that? I can't assign issues to him until that happens.

from did-core.

Thanks @msporny . Yes, I'm Oliver Terbu and according to my W3C account I'm officially member of the W3C DID WG. My GitHub account is connected with my W3C account.

from did-core.

@awoie @msporny it should work now

from did-core.

I agree that we should use JWK for key representations whenever possible, as it is JSON-based, extensible, and already a widely implemented standard.

from did-core.

@brentzundel thank you for taking the time to write this up. I agree with you partially. I spent this summer implementing a Rust crate for parsing DID's and DID documents. It is now the primary DID handling code in Hyperledger Aries. After getting a mostly working crate together, I was so incensed at the state of the spec that I drank three beers and then wrote out a rant from an implementer's perspective. I also recently began writing a paper that surveys all of the past/present representations of cryptographic key material.

Just like what I suggested in issue #103, I think we should step back and not be so quick to re-invent the wheel. In terms of representing cryptographic key material there are a number of different standards that we should learn from. I think the most important lesson I learned from doing the research into all of the other methods is that there are four aspects that need to be addressed in any cryptographic key representation.

My survey paper compiling all of my findings is a work in progress but the four aspects is an important observation and probably not new to people like yourself. Similar to what I suggested over in issue #103 I think we should do the following:

1. The key representation part should be broken out into it's own DID related spec.
2. The key representation spec should be focused solely on what must be in a key "data unit" to support self-sovereign identity.
3. There should be a registry of standard encodings of key "data units".
4. There should be a process by which new encodings can be added.
5. We should probably provide a critique of previous key representations and make suggestions for how those standards could evolve to be useful in the new SSI world--I'm looking at you X.509 certificates, it may be as simple as repurposing the common name (CN) in the subject to contain a DID URI instead of a URL in a standard EV cert from a CA.

I know there is an urge to just pick one and go. But I don't think that is the right move for the DID spec. JWK could be a part of one valid encoding...maybe. I think we should be working along the lines of standardizing that DID key material needs at least the following:

• key id
• key serial number
• key algorithm identifier
• key encoding method identifier
• key usage flags (e.g. sign, verify, auth, etc)
• encoded key material
• key management data (i.e. revocation method such as something akin to OCSP stapling, or maybe a service endpoint to a blockchain backed revocation log. maybe a cryptographic commitment to authenticate a future key rotation, etc).
• issue date
• expiration date

You get the idea. Then we specify a registry of algorithm identifiers and a process by which that gets updated. We also specify a registry of encoding method identifiers and a process by which that gets updated. Then in each of the DID document encoding methods, there must be sections specifying how the algorithm and encoding identifiers are represented in a specific DID document encoding method.

For instance, in the JSON-LD encoding method, we could very well choose the RFC 7518 algorithm identifier strings will be used. If CBOR is used, then there would be a different set of representations (i.e. numerical constants) that are used.

If we take this approach, then it opens up the door to making DIDs and SSI into an evolution instead of a revolution. Old standards can be adapted as special cases of the DID standard so that we don't have to scrap everything and start from scratch. I think that would drive adoption a lot harder.

from did-core.

This is done, the spec now has the option to use JWK... from the spec:

Public keys of all types MUST be expressed in either JSON Web Key (JWK) format using the publicKeyJwk property or one of the formats listed in the table below.

https://w3c.github.io/did-core/#public-keys

Closing if no one objects in 7 days.

from did-core.