Added support for ethereumAddress in context - fixed #55 #56
Conversation
| @@ -38,6 +38,7 @@ | |||
| "delegator": {"@id": "sec:delegator", "@type": "@id"}, | |||
| "domain": "sec:domain", | |||
| "expirationDate": {"@id": "sec:expiration", "@type": "xsd:dateTime"}, | |||
| "ethereumAddress": "sec:ethereumAddress", | |||
There was a problem hiding this comment.
This should be sorted above expirationDate.
|
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. 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? It may be that we need ethereumAddress anyway... or maybe create a new scheme for an ethereum address and do this instead: That's also a possibility... how do you specify which Ethereum network the key exists on? |
|
Based on the outcome of the extensibility discussion at the DID WG F2F, this PR isn't going to survive in its current form. There is a new registry-based process that will be utilized to add these sorts of extensions. See discussion here: https://www.w3.org/2019/did-wg/Meetings/Minutes/2020-01-30-did#section2-5 As a result, I'm closing this PR and expecting a new PR that adds ethereumAddress to the registry once it's created. Please object and re-open the PR if you disagree @awoie. |
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., uniresolver.io.
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.