Clarify ES256K / ES256K-R Documentation

[OR13]

Is your feature request related to a problem? Please describe.

ES256K is a draft:

• https://tools.ietf.org/html/draft-ietf-cose-webauthn-algorithms-01#section-3.2
• https://www.npmjs.com/package/@panva/jose

ES256K-R is not well defined (outside of the documentation in this repo).

Describe the solution you'd like

We should define ES256K-R sufficient for alternative implementations in other languages.

We should clarify how ecrecover is used, and provide support for people who want to use ethereumAddresses with ES256K (fully document how to do this).

We should submit this documentation to ietf, and push for it to be added to JOSE, and be very clear about the status of our draft request (Not Supported, Pending Review, Accepted)... This will help developers avoid disappointment related to interoperability.

Describe alternatives you've considered

• https://www.npmjs.com/package/@panva/jose

Supports ES256K, but nothing supports ethereum addresses like this library does. Thats why its so important we formalize what is happening here.

Additional context

There have been many threads related to this, I will try and add as many as I know here:

• Initial requirements w3c-ccg/lds-ecdsa-secp256k1-2019#1
• Update Spec w3c-ccg/lds-ecdsa-secp256k1-2019#2
• RFC 0021 - Sender and recipient identifiers used in envelope as DID key references hyperledger/aries-rfcs#104
• https://github.com/decentralized-identity/lds-ecdsa-secp256k1-2019.js#motivation

[OR13]

I propose the following:

1. We add support for ethereumAddress to DID Context (its not usable at all without doing this).
2. We clarify what is custom crypto, and what is ietf draft or JOSE compliant
3. We formalize a draft for ietf of ES256K-R, and work with the DIF to get it adopted.

[jonnycrunch]

same concern as w3c/did-extensions#79. At least I am familiar with ecrecover and have tooling that will work, but none of the readily available JWT libraries support it.

[OR13]

@jonnycrunch agreed, at this point, I would say that ES256K-R is a cryptographic golem ;)

I created https://github.com/decentralized-identity/EcdsaSecp256k1RecoverySignature2020 to try and teach DIF members how to create linked data suites, but I give up :)

I would suggest we add a warning, telling people to never use EcdsaSecp256k1RecoverySignature2020, or ES256K-R.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.