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

Added support for ethereumAddress in context - fixed #55 #56

wants to merge 1 commit into
base: master


Copy link

awoie commented Sep 27, 2019

Added support for ethereumAddress in context - fixed #55

The final community specification allows for ethereumAddress public key types. We have to add the respective key type to the context to be recognized by 3rd party applications, e.g.,

After following the discussion in w3c-ccg/did-spec#270, it seems like we should at least support all public key types that were mentioned in the W3C CCG DID spec.

@@ -38,6 +38,7 @@
"delegator": {"@id": "sec:delegator", "@type": "@id"},
"domain": "sec:domain",
"expirationDate": {"@id": "sec:expiration", "@type": "xsd:dateTime"},
"ethereumAddress": "sec:ethereumAddress",

This comment has been minimized.

Copy link

davidlehn Sep 27, 2019


This should be sorted above expirationDate.


This comment has been minimized.

Copy link

msporny commented Oct 7, 2019

How closely related is PR #63 to this PR?

With respect to expressing public keys in general... 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.

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?

It may be that we need ethereumAddress anyway... or maybe create a new scheme for an ethereum address and do this instead:

"publicKey": "eth:ropsten:0xe2a2a55E4e09AB542765D19Bcd73B78D9DCbc518"

That's also a possibility... how do you specify which Ethereum network the key exists on?

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.

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