Add v2 JSON-LD context file

[clehner]

To successfully use this suite, JSON-LD terms need to be defined that are not currently defined in the suite's context file - as noted in #9 and in #21 (comment). There are also term definitions in the current context file which we might want to remove (#14, #15). This PR proposes a new context file, v2 (lds-ecdsa-secp256k1-recovery2020-2.0.jsonld). This versioning skips over 1.0, since 0.0 was already registered as v1 in w3id (I think that was my mistake) but now we can hopefully re-unify the versioning with v2 (2.0).

If the changes here can be agreed on, I think we could request a new redirect for this context file at https://w3id.org/security/suites/secp256k1recovery-2020/v2 here (Edit: requested in perma-id/w3id.org#2409) and then update the specification and test vectors accordingly (and examples in DID Specification Registries, etc.).

In the registration of this suite in Security Vocab and w3id.org, @msporny suggested looking at ed25519-signature-2020-v1.jsonld (Ed25519 Signature 2020) as an example of a modern cryptosuite. I looked at this, and also at JSON Web Signature 2020's context file, and tried to follow the patterns. Below are a summary of diffs between those context files with this one as currently proposed, as well as comparison with various other approaches. I have attempted to explain/document all the relevant changes (or lack of changes). If this is too much I could try to split it into more incremental changes. This is a draft, open to feedback and/or change requests.

Diff from other context files

Compared to secp256k1recovery-2020/v1 (lds-ecdsa-secp256k1-recovery2020-0.0.jsonld)

• Remove term definitions that conflict with W3C/CCG definitions (Fix Conflicting term definitions #14).
  • esrs:publicKeyJwk (Re-adding as sec:publicKeyJwk, in the VM type, below)
  • esrs:publicKeyHex (Not re-adding)
  • esrs:ethereumAddress (Not re-adding)
• Remove private key term definitions (Fix Security concern about private key terms in public context #15).
  • privateKeyJwk
  • privateKeyHex
• Define proof property.
• Define properties in the verification method type and proof type
  • vm.controller
  • vm.blockchainAccountId
  • vm.publicKeyJwk
  • proof.challenge
  • proof.created
  • proof.domain
  • proof.expires
  • proof.jws
  • proof.nonce
  • proof.verificationMethod
  • proof.proofPurpose (assertionMethod, authentication, capabilityInvocation, capabilityDelegation, keyAgreement)

Compared to ed25519-2020/v1

• proof.proofValue → proof.jws
• vm.publicKeyMultibase → vm.publicKeyJwk
• Remove vm.revoked

Compared to jws-2020/v1

• Remove privateKeyJwk
• Add vm.controller

Compared to both ed25519-2020/v1 and jws-2020/v1

• Proof type and verification method type are in esrs2020 (https://identity.foundation/EcdsaSecp256k1RecoverySignature2020#) namespace rather than w3id security namespace (https://w3id.org/security#).
• Add vm.blockchainAccountId.

Compared to secp256k1recovery-2020/v1 + esrs2020-extra-0.0

This is basically the approach that https://github.com/spruceid/ssi/ uses - defining an additional context file for the extra needed terms.

• Define proof properties scoped(?) under the proof type rather than at the top-level.
• Add proof purposes capabilityInvocation, capabilityDelegation and keyAgreement.
• Remove proofValue.
• Remove esrs namespaced term definitions - except for the proof and verification method type.

Compared to what was previously proposed for security-v3-unstable.jsonld

Originally proposed in w3c-ccg/security-vocab#95: w3c-ccg/security-vocab@11944c6. Withdrawn in w3c-ccg/security-vocab#95 (comment) based on PR feedback.

• Define proof property
• Change from w3id security namespace to DIF esrs namespace
  • https://w3id.org/security#EcdsaSecp256k1RecoveryMethod2020 → https://identity.foundation/EcdsaSecp256k1RecoverySignature2020#EcdsaSecp256k1RecoveryMethod2020
  • https://w3id.org/security#EcdsaSecp256k1RecoverySignature2020 → https://identity.foundation/EcdsaSecp256k1RecoverySignature2020#EcdsaSecp256k1RecoverySignature2020
• Define verification method properties
• vm.controller
• vm.blockchainAccountId
• vm.publicKeyJwk
• Remove "@version": 1.1

Compared to Veramo's lds-ecdsa-secp256k1-recovery2020-0.0.jsonld

• Change from esrs namespace to w3id/security namespace for proof type (EcdsaSecp256k1RecoverySignature2020)
• Remove use of "@version": 1.1
• Use @protected": true at top-level
• Use full IRIs rather than compact IRIs
• Define proof property
• Define properties in verification method
  • controller
  • blockchainAccountId
  • publicKeyJwk
• Add more proof purposes: capabilityInvocation, capabilityDelegation and keyAgreement.
• Remove proofValue.
• Remove esrs namespaced term definitions (except for the verification method type): publicKeyJwk, privateKeyJwk, publicKeyHex, privateKeyHex, ethereumAddress.

More info

The following are explanations/justifications of the proposed changes, including other details and references that may be relevant.

Security Vocab says publicKeyHex is deprecated; publicKeyMultibase is suggested as an alternative. Related: w3c-ccg/lds-ecdsa-secp256k1-2019#4

DID Specification Registries says ethereumAddress is deprecated (in favor of blockchainAccountId).

Private key term definitions are not retained, since they are not needed for proof objects or verification method objects. If needed (e.g. for Universal Wallet 2020) they could be defined in an additional context file?

proof definition - I assume this is useful for proofs on objects other than VCs/VPs (not having the Credentials base context that defines proof).

Support for blockchainAccountId is proposed in #23.

Regarding proofValue (like in Ed25519Signature2020): This proof type (EcdsaSecp256k1RecoverySignature2020) seems pretty squarely JWS; it's specified and implemented as such. Changing the signature algorithm or adding an additional signature algorithm would be a breaking change. Do any implementers really want this option?

About publicKeyMultibase: this specification and reference implementation doesn't use it currently. Support could be added if it is desired (similarly to blockchainAccountId). Maybe it could be useful as a successor to publicKeyHex? This would not be a breaking change in the way that changing the signature algorithm would be - this would only pertain to the verification method object.

Verification method controller property is defined in Ed25519VerificationKey2020. It's already defined in the DID Core v1 base context, but I guess it's useful if we want to use the verification method in non-DID-documents?

The revoked property of a verification method is used in Ed25519VerificationKey2020's context. Do we need that?

Whether or not @version: 1.1 is needed (I am not sure I understand the consensus) is discussed in w3c-ccg/security-vocab#95 (comment).

Changing the proof type and verification method type to use w3id/sec namespace instead of dif/esrs namespace was mentioned in w3c-ccg/security-vocab#95 (comment).
Using the separate namespace was questioned in perma-id/w3id.org#2108 (comment). Given that the test vector / reference implementation doesn't currently sign over the proof type (#20, proposed fix #21), arguably the proof type IRI hasn't yet been committed to.

cc @OR13 @peacekeeper