Skip to content
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

Add publicKeyHex as a valid publicKey format #63

Open
wants to merge 1 commit into
base: master
from

Conversation

@gjgd
Copy link

gjgd commented Oct 5, 2019

Re-creating PR from CCG repo: w3c-ccg/did-spec#270. Please consider earlier discussions there.

@msporny

This comment has been minimized.

Copy link
Member

msporny commented Oct 7, 2019

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?

Copy link

selfissued left a comment

We should be removing public key formats from the spec - not adding them. We should get down to one key format to increase interoperability of implementations - preferably JWK.

@selfissued

This comment has been minimized.

Copy link

selfissued commented Oct 8, 2019

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.

@mikelodder7

This comment has been minimized.

Copy link
Contributor

mikelodder7 commented Oct 15, 2019

Why are we putting the encoding in the "name"?
The encoding should go in the value. Programmatically, this would help with implementations.

@dlongley

This comment has been minimized.

Copy link
Contributor

dlongley commented Oct 15, 2019

@mikelodder7,

Why are we putting the encoding in the "name"?
The encoding should go in the value. Programmatically, this would help with implementations.

Yeah, if we adopt multibase we can move the encoding into the value.

@selfissued

This comment has been minimized.

Copy link

selfissued commented Oct 15, 2019

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.

@mikelodder7

This comment has been minimized.

Copy link
Contributor

mikelodder7 commented Oct 15, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.