Update Spec

[OR13]

• Select ES256K JWS as Signature Algorithm DRAFT
• Select ES256K JWS Unencoded Payload (Detached Signatures) as Signature Format

rfc7797

Misc definitions.

Trying to make this as close to Ed25519Signature2018 as possible, comments / feedback welcome.

[OR13]

What can I do to move this along? @peacekeeper

[awoie]

@OR13 it would be great to support ethereumAddress as one potential format of the public key. I think the JWK requirement might be a problem and would prevent us from adding support for ethereumAddress.

[awoie]

Also adding @christianlundkvist to bring him into this conversation.

[OR13]

@awoie @christianlundkvist, yes this issue with ethereum address has come up a few times.

DID Methods like ETHR, or other ledger specific methods may not define public keys by default.

There is no real precedent for building a JSON linked data signature that does not use a public key, but it is possible to do.

For context, this spec is based on https://w3c-dvcg.github.io/lds-ed25519-2018/

The objective is to provide a much more standard secp256k1 JSON-LD signature.

The closest usable existing signature is: https://w3c-dvcg.github.io/lds-koblitz2016/

You can see it handles public keys in yet another non standard way:

{
  "@context": ["http://schema.org/", "https://w3id.org/security/v1"],
  "description": "Hello world!",
  "signature": {
    "type": "EcdsaKoblitzSignature2016",
    "created": "2016-10-23T05:50:16Z",
    "creator": "ecdsa-koblitz-pubkey:020d79074ef137d4f338c2e6bef2a49c618109eccf1cd01ccc3286634789baef4b",
    "domain": "example.com",
    "signatureValue": "H1jslvQ08/hAiqUSNiGoAYqU8sRCrwkgcNO/9xKxqZJTAX5v5SbAcBv69wrAQovBHR9ddfwvW1Skogbi1odGt7o="
  }
}

My recommendation is to not conflate ethereum or blockchain specific alternatives to the verification definition with this spec.

We need a secp256k1 json-ld signature suite that works, and we need a signature suite that works for ethereum addresses. We are more likely to get both of these done by not combining them.

We can and probably should add this bit to the spec for this signature suite, regarding publicKeyHex: https://context.transmute.org/element/#EcdsaSecp256k1VerificationKey2019

Bottom line, the name of the suite that relies on an ethereum address, bitcoin address, etc... should be something other than EcdsaSecp256k1Signature2019... Some suggestions are:

EcdsaSecp256k1EthereumSignature2019, EcdsaSecp256k1AddressSignature2019, EcdsaSecp256k1EthereumRecoverableSignature2019...

We may want to add a separate suite for ES256K and ES256K-R that use ethereum or bitcoin addresses for verifying.

It would not be difficult to create such a suite based on the work here: https://github.com/decentralized-identity/lds-ecdsa-secp256k1-2019.js/blob/master/packages/es256k-jws-ts/src/__tests__/interop/uport/uport.spec.ts

The PR to add support for publicKeyHex is still pending here: w3c-ccg/did-spec#270

There is some discussion relating to documentation which is relevant to this thread.

IMO the best solution to the ethereumAddress JSON-LD issue is for us to create our own context, fully document it, build a JSON-LD Signature suite that uses it, and then make the case to the W3 CCG for adding the suite to the registry (strictly speaking not a necessary thing to do). Maybe we can circle up at IIW and hammer this out, I think I could probably do it in a weekend, we could host it under the DIF, and we would make the job of the CCG a lot easier by fully documenting the whole process.