Add publicKeyHex as a valid publicKey format #63
Conversation
|
How closely related is PR #55 to this PR? Could we specify publicKeyMultibase instead to support this use case as well as base58btc encodings for public keys? That would be my preference since we would only need to define one new vocabulary term to support base16, base32, base58btc, and base64 encodings for raw public keys. https://github.com/multiformats/multibase/ The other option would be to support publicKeyMulticodec, which would be a multibase encoded multicodec expressed public key, which would give us full forward compatibility for all future key types. I know that we (Digital Bazaar) did publicKeyBase58, which was a mistake... can we please try to standardize on something future resistant rather than iterating over a large number of new vocabulary terms? |
|
Because JWK has the accompanying IANA JSON Web Key Types registry https://www.iana.org/assignments/jose/jose.xhtml#web-key-types it is extensible and therefore future-proof. An example of a new specification using this extensibility in support of decentralized systems is https://tools.ietf.org/html/draft-ietf-cose-webauthn-algorithms-01, which among other things registers identifiers for using secp256k1. |
|
Why are we putting the encoding in the "name"? |
Yeah, if we adopt multibase we can move the encoding into the value. |
|
Please see the distinction that I made in #67 (comment) between (1) keys used to prove control of the DID and (2) keys that are application data. For (1), we should choose a standard representation. For (2), we should make it syntactically clear that the data is data for the application and not a key of the DID. For (1), I view multibase as a problem rather than a solution, as it's a way of encoding the same thing in a plethora of ways - explicitly deciding not to decide. Good standards make choices to improve interop. For (2), applications should be free to use whatever data representations they want, including for keys specific to the application. The standard should be silent on what's in application data, other than to clearly distinguish between data about the DID and application data. |
|
The problem I want to solve is not putting the encoding in the "name" like publicKeyHex or publicKeyBase58. I don't have an opinion on multibase yet but you can also make the "value" field an object that has the name "encoding": "hex" or something like that. @selfissued I agree that the DID methods should make good decisions about this, but the DID spec shouldn't force an encoding on the method implementors. |
|
I suggest we close this PR, and tackle this again when we have a registry and way to resolve these issues, or people who need to use publicKeyHex use extensions, or the DIF context to do so in the mean time. |
Err, what DIF context? |
|
https://github.com/decentralized-identity/context I had to centralize all the jsonld contexts and documentation in order to create integration tests with the universal resolver to show interoperability, and demonstrate how updating contexts can support interoperability. Interoperability of JSON-LD DIDs without alterations: Interoperability of JSON-LD DIDs with W3 context: Interoperability of JSON-LD DIDs with DIF context: I did this work before the F2F and shared it on the mailing list, since I could not attend. My goal was to demonstrate that all that is needed for interoperability was updating json and markdown files in a single repo... I succeeded at my goal, by creating the DIF context and showing that I could resolve issues by defining properties. I also added documentation for every property defined in any context linked to by the did core context... its in markdown, but it will be helpful for those looking to quickly update the registry, when we get that. |
|
To be clear, I'd love to not have the DIF context be a thing, I just needed it to show how easy it should be to get interoperability... if there is a registry that can be easily updated :) Seems like the F2F landed at a similar conclusion. |
Here are the concerns w/ a DIF context for a spec that the DID WG is producing:
Please put in a PR for an experimental context that the W3C DID WG can host beside the other one so that all of the DID Contexts are at least in one place. I missed whatever email you sent to the group about this so am just now becoming aware of what's going on. Lots of concerns w/ the approach taken and would rather the work is done in the W3C WG that is officially responsible for the DID Core spec than at DIF. |
I don't think the F2F landed at a similar conclusion... unfortunately, I think you're missing a good bit of the discussion that happened at the F2F. The registry is not going to lead to something that "can be easily updated" :( In any case, we should bring this up on a WG meeting and see if we can migrate what you've done over to the WG. |
|
Moving this to an issue: #188 |
Re-creating PR from CCG repo: w3c-ccg/did-spec#270. Please consider earlier discussions there.