-
Notifications
You must be signed in to change notification settings - Fork 95
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Leverage existing RFC7517 to specify cryptographic key #7
Comments
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. |
I agree that we should use JWK for key representations whenever possible, as it is JSON-based, extensible, and already a widely implemented standard. |
@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:
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:
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. |
This is done, the spec now has the option to use JWK... from the spec:
https://w3c.github.io/did-core/#public-keys Closing if no one objects in 7 days. |
@AxelNennker Taken over from the CCG (w3c-ccg/did-spec#37)
The text was updated successfully, but these errors were encountered: