Initial requirements

[peacekeeper]

Initial requirements for this spec are:

• Define EcdsaSecp256k1Signature2019 term
• Define EcdsaSecp256k1VerificationKey2019 term
• Define publicKeyHex as a public key property
• Define ethereumAddress as a public key property (see discussions at Allow to use addresses instead of public keys. did-spec#56 and Add support for recoverable public keys did-spec#201 and "Key Addresses" on the did:erc725 method doc [Question] WebOfTrustInfo/rwot6-santabarbara#63)

[OR13]

If any of this is usable for this, I would happily move it here / rename / remove / delete my repo...

https://github.com/transmute-industries/PROPOSAL-EcdsaKoblitzSignature2019

I created this a while back while being thoroughly frustrated with the current JSON-LD Secp256k1 Signature suites, and their lack of clear conformance to the Linked Data Signatures spec. I don't want to create any confusion regarding the spec, I want to be using a real standard.

The most standards like one is EcdsaKoblitzSignature2016, and UPort and Jolocom both have libraries that are more JWT like, this issue has some discussion:

jolocom/jolocom-lib#261

I'd love to assist / provide an implementation of the signature suite.

Another challenge when working with lds suites is that the key terms have changed, when creating a suite in 2019 see (digitalbazaar/jsonld-signatures#66)

owner -> controller,
signature -> proof
creator -> verificationMethod

I have implemented support for both in various libraries, happy to provide support for both here if it would be valuable.

[OR13]

I'm working on the spec in the DIF repo along side a js implementation:

There are a couple issues which need to be resolved before I can open a PR and point to this repo as the official spec.

https://github.com/decentralized-identity/lds-ecdsa-secp256k1-2019.js

[peacekeeper]

@OR13 I think if possible the spec should be here, and implementations could be at DIF (or elsewhere). Is that what you were thinking?

[OR13]

@peacekeeper, I have pushed a revised spec + implementation + demo here:

https://github.com/decentralized-identity/lds-ecdsa-secp256k1-2019.js

As I noted in decentralized-identity/lds-ecdsa-secp256k1-2019.js#3, The current spec checked into the DIF because I have commit control there, but I will open a PR with the revised spec here shortly.

[OR13]

IMO, ethereumAddress should not be requirement for this spec. Its a transformation of a public key, that is required to verify according to ES256K.

The fact that ethereum addresses are often known when the corresponding public key is not is unfortunate, but JWS / JOSE are about cryptography not crypto currencies, they should operate on keys in JWK format.

Its possible to automatically convert a hex encoded key to JWK, but not an ethereum address, making registering of an ethereumAddress not as helpful.

However, if ES256K-R is used I believe ethereumAddress might make sense, as the public key can be extracted from the signature and then converted / compared with an address.

If the true desire is for a Ecdsa Secp256k1 Signature Suite for ES256K-R, we should probably create clearer names, probably including the word "ethereum" in the suite definition.

I tried my best to follow the example of: https://w3c-dvcg.github.io/lds-ed25519-2018/

I'm happy to write a spec for an ethereumAddress based signature suite, it would not be hard to do.

[OR13]

I have removed the spec draft from the DIF to avoid confusion, this PR contains the draft:

#2

Happy to make any changes.

[OR13]

On a related note, if we do want to support ethereum or bitcoin specific variants, i think there are a couple points to be made.

Ethereum and Bitcoin Signature formats need THEIR OWN jws algs.

ES256K does not do any of this message packing / formatting \x19Ethereum Signed Message:\n or \x18Bitcoin Signed Message:\n...

https://bitcoin.stackexchange.com/questions/77324/how-are-bitcoin-signed-messages-generated

This means that you cannot generate valid ES256K signatures over these interfaces (ES256K does not specify that its ok to prepend your message with this stuff).

You can't hack around these message formats because you want to be able to rely on Bitcoin / Ethereum Nodes and Hardware Wallets / existing tools like MetaMask / web3.js, bitcoinjs, etc...

They all will generate signatures that have this stuff prepended.

Assuming that these signature formats where supported by JOSE (and I find that unlikely), you could use alg: ESETH or ESBTC... you would probably also want to make the spec recoverable by default.

[OR13]

I should note, you can totally get JWS to work with this custom signature formats, its just not ES256K...

[peacekeeper]

@OR13

Ethereum and Bitcoin Signature formats need THEIR OWN jws algs.

Not sure I completely follow this.. I don't think people who want to use Bitcoin- or Ethereum-based keys and DID methods are necessarily proposing to also use Bitcoin- or Ethereum-style message packing.

So while I understand that for the ethereumAddress public key property we may need a different spec than this one, I don't really understand why this would require a different signature spec. But I'm not as close to this as you, e.g. this is the first time I hear about ES256K-R :)

Perhaps @awoie could comment on this issue and also review your PR #2 ?

[OR13]

The issue is what standard is the use of ethereumAddress attached to?

If its JOSE / JSON-LD, it needs to not have name conflicts with things that use public keys.

If its not a standard, but it works fine, I think it should have a clear, unique name and documentation and then people can decided to use it.

I really don't like when things are named the same, but implemented differently, it makes the standard meaningless.

Saying you can use an ethereum address or a public key to verifying a JWS is not as good as saying, you need a public key to verify ES256K and you need an ethereumAddress to verify ES256K-R.

[awoie]

@OR13 I still think there is a misunderstanding. In practice, how the signature of the JWT/JWS is generated does not relate to how you would obtain the cryptographic material to verify the signature. The latter is related to the DID resolution process. did:ethr or ethereumAddress-based DID systems that use JWTs with alg=ES256K are 100% compatible with the alg described in the IETF paper (https://tools.ietf.org/id/draft-jones-webauthn-secp256k1-00.html). I don't believe we should introduce a separate IANA alg for that as the signature algorithm is 100% the same! But I understand your point that you want to have the verification process separated.

The easiest way that also has minimal implications on existing implementations that make use of ethereumAddress is likely to define a separate LD Crypto Suite that is very similar to this one.

@mirceanis do you think that this is a feasible approach from an implementers point of view?

@peacekeeper @OR13 do you think that is a feasible approach from a LD Crypto Suite perspective?

[awoie]

@OR13 uPort uses ES256K-R instead of ES256K just for convenience reasons. There is no real technical limitation that won't allow us to use ES256K as well. We could however register ES256K-R with IANA but I don't think that will make a lot of sense. The only difference between these two is that -R adds an additional recovery bit which you don't need because you could also test if one of the two recovered public keys is valid.

But I will check with the rest of the uPort team. If we keep using ES256K-R, then we will definitely have to register it with IANA :) .

[OR13]

@awoie I agree from a JOSE perspective, the signatures are ES256K...

From a JOSE library thats supports verification perspective, the standard form (which takes a public key) is likely to be implemented in many languages, a form that takes an ethereum address is implemented by UPort, and a verifier can choose which library to use for verification.

A verifier will not be able to verify signatures from DIDs that only have an ethereumAddress if they want to use a library that takes public keys.

A verifier will be able to verify signatures from DIDs that have public keys if they want to use a library that supports addresses.

While I'd like to encourage the use of public keys for JOSE and JSON-LD DID related signature suites and discourage the use of addresses, there is nothing cryptographically wrong with supporting both.

I would prefer to have separate names so that there is a single, strong coupling between how sign and verify are implemented for any given algorithm, but if we are only talking about custom extensions to JOSE, its technically the case that verification can be handled however the verifier wishes.

From a JSON-LD Signatures perspective, we must define how to handle verifying an ES256K JWS used in a JSON-LD Signature, and we must define the format of the material used to verify, and I'm strongly against supporting addresses and regular public keys in the same spec.

I'm very much in favor of a separate JSON-LD Signature suite that supports verification with ethereumAddress, I'm happy to help build it with UPort did-jwt library, and define the spec for it.

[OR13]

@dmitrizagidulin See also: digitalbazaar/ecdsa-secp256k1-verification-key-2019#6

I need you or someone from DB to help develop this spec... especially since you are implementing support for base58 without making updates here.

@awoie I think ethereumAddress is out of scope for this, since its only used with ES256K-R... most implementations of a jws are checked against a publicKeyJwk...

If you would like to help develop this, please open a PR to add yourself / open some additional issues.