Add support for ethereumAddress public key type in @context

[awoie]

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.

[selfissued]

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.

[awoie]

@selfissued In general, I'm also in favor of having fewer representations of public keys. Nevertheless, some people, e.g., uPort, are using ethereumAddress: 0xabc... to express the "public key" which in this case is rather a parameter for the verification/ authentication. Technically, it is not a public key, just the last 20 bytes of the keccak of a public key, i.e., the Ethereum Address. This is needed because in some cases, e.g., smart contracts, we are not able to propagate the real public key in the DID Document and only have access to the ethereumAddress. Because secp256k1 keys are used we are still able to authenticate a message based on the message text, the message signature and the hash of the public key.

@selfissued Do you think it is likely that we can register a JWK representation for ethereumAddress?

[selfissued]

This sounds like it's a cryptographically derived Key ID - not the key itself.

[OR13]

Blocked by registry agreement.

[selfissued]

@awoie, given that ethereumAddress is a key identifier, not a key, we should remove all instances of ethereumAddress from the specification and close this issue. (Yes, per @OR13's comment, other specifications could define this key identifier and register it.)

[kdenhartog]

@selfissued if we take that stance than I'd argue that a base64url encoding of a key is also a key identifier rather than the key itself. The reason I'd argue this is because in both a base64url encoding and an ethereumAddress we're transforming a string into bytes rather than dereferencing to obtain the bytes. In my mind, when a piece of data that represents a key is dereferenced the input is an identifier, but when it's transformed it's the key itself.

Given the registry discussion though, I think we have other means of registering this (which get it into IANA Jose registries). With that in mind, I think it's fine to close.

[OR13]

I've always been bothered by ethereumAddress being in a section called publicKey.... IMO it has always belonged in any block but the publicKey section.

This issue remains blocked by the regstries discussion, please help review PRs / get that stuff stabilized so we can address this properly:

https://github.com/w3c/did-core-registry

[awoie]

IMO, we should rename the publicKey section into verificationMethod and that solves the problem. ethereumAddress is one form of verification method. It is more than just an identifier because it can be used (via ecrecover) to verify that a message was signed by that address.

[OR13]

technically ecrecover returns a publicKey... which you then have to convert to an address to use (if you only have an address to compare against)... why not just use assertionMethod for ethereumAddress... thats the property that is required by the VC DataModel, and you are only talking about signing...

The purpose of having assertionMethod and authentication be separate verificationMethods was to avoid bucketing all functionality into a single list, with root powers....

Put another way... why not just remove the publicKey section from the did:ethr spec all together?

In JOSE land, the there are uses for enc and sig, its generally a best practices not to use the same key for everything...

https://libsodium.gitbook.io/doc/advanced/ed25519-curve25519#notes

If you can afford it, using distinct keys for signing and for encryption is still highly recommended.

@awoie please review w3c/did-extensions#11, its currently blocking our ability make updates to the registry for things like this.

[selfissued]

Given that this is not a public key representation, it should not be registered as a public key representation. I'm fine with this being registered as a verification method.

[kdenhartog]

@selfissued just so I understand your position more clearly, are you thinking that this is unacceptable:

{
  "@context":[
    "https://www.w3.org/ns/did/v1",
    "https://w3c.github.io/did-core-registries/contexts/did-core-extensions/did-core-extensions-v0.0.1.jsond"
  ],
  "id":"did:example:123",
  "publicKey":[{
    "id": "did:example:123#vm-3",
    "controller": "did:example:123",
    "type": "EcdsaSecp256k1RecoveryMethod2020",
    "ethereumAddress": "0xF3beAC30C498D9E26865F34fCAa57dBB935b0D74"
  }]
}

But this is acceptable and legal:

{
  "@context":[
    "https://www.w3.org/ns/did/v1",
    "https://w3c.github.io/did-core-registries/contexts/did-core-extensions/did-core-extensions-v0.0.1.jsond"
  ],
  "id":"did:example:123",
  "authentication":[{
    "id": "did:example:123#vm-3",
    "controller": "did:example:123",
    "type": "EcdsaSecp256k1RecoveryMethod2020",
    "ethereumAddress": "0xF3beAC30C498D9E26865F34fCAa57dBB935b0D74"
  }]
}

[OR13]

^ i'm also a fan of not calling an ethereumAddress a public key... because its a deterministic function of one... not one.

[selfissued]

Yes, as long as it's not called a public key, I'm fine with it appearing places that it makes sense. The thing that's blocking this is the working group deciding what to call things like this - whether verification method or some other name, etc. That's where I'd focus your efforts.

[awoie]

That is fine by me as long as we can keep using the vocabulary.

[awoie]

There is just one issue with this approach. The public key section is nice because you can reuse the elements in other areas of the spec, e.g., by referring to them within an authentication section. This is great because it makes the DID Doc smaller in case the same verification method is used for multiple proof purposes. I will create a new issue to address that #283

[msporny]

This issue has been overtaken by events. We now have a DID Specification Registries document and this property should be registered there.

It will be up to the people that want to see ethereumAddress supported globally to add it to the DID specification registries document.

I suggest that we close this issue and a new issue (or ideally, a PR) is opened on the DID specification registries.

[jonnycrunch]

one observation is that this public key type for derived path derived from secp256k1 curve may be an ethereum address. Explicitly stating that is is an ethereum address may be problematic as it also doesn't state which fork or ethereum to locate it.

[OR13]

thats an issue for did:ethr, but not for general ECRecover.... its also an issue for all sidetree based DID methods, its warned about here: https://identity.foundation/sidetree/spec/#ledger-forking

[awoie]

yes, did:ethr encodes the chain id in the did itself.

[awoie]

It seems that ethereumAddress has been added already: https://www.w3.org/TR/did-spec-registries/#ethereumaddress. Am I missing something?

[OR13]

@awoie yes, its been registered... however you still need it to be present in a context, to be valid JSON-LD.

Given the significant work contributed by companies like ConsenSys, Transmute, Bloom, Jolocom, etc... all who work on ethereum, I would very much be in favor of including ethereumAddress here: https://github.com/w3c/did-spec-registries/blob/master/contexts/did-v1.jsonld

so that those companies don't need to create a custom context just to have a valid JSON-LD DID Document.... at this point, blocking publicKey representation that are being used by multiple companies, and have been for years, seems a little hostile to the spirit of mutual support and community development, the cost is a very low, we just need to add the property to a context.. if its did-v1... they don't need to do anything else.

You might also want to register the term here: https://github.com/w3c-ccg/security-vocab/blob/master/contexts/security-v3-unstable.jsonld

Speaking as a developer, if you don't care about JSON-LD, you don't need to do anything at this point, but expect people to complain when they try and use your DID Document with JSON-LD and ethereumAddress gets dropped because its not a registered property (in the context)...

[msporny]

Given the significant work contributed by companies like ConsenSys, Transmute, Bloom, Jolocom, etc... all who work on ethereum, I would very much be in favor of including ethereumAddress here: https://github.com/w3c/did-spec-registries/blob/master/contexts/did-v1.jsonld

Feels like a political minefield. We currently don't have any Blockchain-specific properties in the core DID Context. If Ethereum gets special treatment, then why not Bitcoin? Or Sovrin? Or Veres One? Or Ion?

If we're going to move stuff like this into the core context, we'll be viewed as gatekeepers (even more so than now), and stuff like that tends to lead to formal objections by moneyed interests. Personally, speaking as an Editor, I'd rather avoid that headache until we have the time to deal with it.

This isn't an argument for or against -- just highlighting that the proposed path may be fraught.

[OR13]

@msporny yep, I recognize this has been a sensitive area, but we have to address it.

Sovrin, Veres One, ConsenSys have all contributed significantly to the development of this and related specifications, and in many cases, they defined concepts and then registered them for interoperability purposes.... and they are still the only ones using them...

This is especially true of base58 and verification relationships.

Given the lack of contribution to JSON-LD contexts to date, I am far less worried about too many ledger specific properties getting added, and far more worried about not enough contribution from interested parties to support the ongoing development of JSON-LD.

There is a really simple reason why we might want to register bitcoin or ethereum addresses for all did methods... we might want to use those for payments.... they are still the 2 most popular decentralized ledger technologies.

Should we add support for (insert your favorite ICO here).... no, especially if they have not contributed to the WG at all... but thats not the case for the bitcoin or ethereum communities... in fact... one might argue that this entire space would not exist were it not for Bitcoin.

I'm also not volunteering to do this work... there are companies which built on Bitcoin (Microsoft) and Ethereum (ConsenSys), and Hyperledger (Sovrin / Evernym), and they are responsible for defining vocabulary concepts that are necessary to support interoperability with their systems, as Veres One has done for base58 and verification relationships.

TL;DR; we should be encouraging vendors to define terms in both HTML, and JSON-LD... or we are actually discouraging vendors from supporting the JSON-LD representation.... the same is true for CBOR and JSON....

This is especially important given the recent breakthroughs involving JSON-LD and ZKPs... there is good reason to believe that many DID Methods will want to be able to use those proofs because there is very little cross did method support for ZKPs today.

Are we really going to tell every did method that they need to pull a BLS and Ethereum and Bitocin specific context to use the only JSON-LD signature suite that supports ZKPs? or are we going to let them just use:

https://www.w3.org/ns/did/v1

and send and receive bitcoin and ethereum while exchanging selective disclosure BLS ZKPs ?

It seems like adding 4-5 lines to a JSON-LD contexts to support interoperability, is far better than asking people to learn how to use JSON-LD if they want to work with ethereum, bitcoin or bls related stuff.

My understanding of the last topic call regarding these concepts was that people wanted something that "just worked" for the "state of the art / recommended things"... If I were to generalize that into some simple statements about did documents, here's what I would get:

If your did method has an @context that is just https://www.w3.org/ns/did/v1, you get some features out of the box:

• support for jwk encoded keys
• support for JsonWebSignature2020 (a recommended subset of all JOSE JWS)
• support for representing bitcoin / ethereum addresses
• support for base58 encoded keys
• support for Bls12381G2Key2020 (and BLS based ZKPs)
• support for Ed25519Signature2018. (a recommended signature algorithm)
• support for services, verification relationships and public keys

If you need something beyond this AND you care about JSON-LD support, you might need to learn how to use JSON-LD, but if these features or some subset of them (JOSE only / base58 only) are good enough, you don't need to learn anything about JSON-LD.

[awoie]

I would highly appreciate it if ethereumAddress would be added to the core context. There are more than 300k Ethereum developers out there. I don't see any issue with adding vocabulary to the core context to support solutions that have been around for years.

[awoie]

If other projects can show similar traction as Ethereum, then I'm absolutely happy with adding that and that also includes Bitcoin. In case of doubt we should be more inclusive and try to make existing and proven solutions work across our industry with lowest friction.

[awoie]

If there are no political concerns with Bitcoin Base58 (which is part of the context), we should not have an issue with ethereumAddress.

[brentzundel]

lots of conversation since marked pending close, removing label.