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 https://github.com/decentralized-identity/EcdsaSecp256k1RecoverySignature2020/pull/21#issuecomment-973316817. 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/v2here (Edit: requested in https://github.com/perma-id/w3id.org/pull/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.
Proof type and verification method type are in esrs2020 (https://identity.foundation/EcdsaSecp256k1RecoverySignature2020#) namespace rather than w3id security namespace (https://w3id.org/security#).
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?
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 https://github.com/decentralized-identity/EcdsaSecp256k1RecoverySignature2020/pull/21#issuecomment-973316817. 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/v2here (Edit: requested in https://github.com/perma-id/w3id.org/pull/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)
Compared to ed25519-2020/v1
Compared to jws-2020/v1
Compared to both ed25519-2020/v1 and jws-2020/v1
esrs2020(https://identity.foundation/EcdsaSecp256k1RecoverySignature2020#) namespace rather than w3id security namespace (https://w3id.org/security#).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.
esrsnamespaced term definitions - except for the proof and verification method type.Compared to what was previously proposed for security-v3-unstable.jsonld
Originally proposed in https://github.com/w3c-ccg/security-vocab/pull/95: https://github.com/w3c-ccg/security-vocab/commit/11944c69cde2a75acadf1c1c1e3cc2e357e858a6. Withdrawn in https://github.com/w3c-ccg/security-vocab/pull/95#issuecomment-818237451 based on PR feedback.
proofpropertyhttps://w3id.org/security#EcdsaSecp256k1RecoveryMethod2020→https://identity.foundation/EcdsaSecp256k1RecoverySignature2020#EcdsaSecp256k1RecoveryMethod2020https://w3id.org/security#EcdsaSecp256k1RecoverySignature2020→https://identity.foundation/EcdsaSecp256k1RecoverySignature2020#EcdsaSecp256k1RecoverySignature2020"@version": 1.1Compared to Veramo's
lds-ecdsa-secp256k1-recovery2020-0.0.jsonld"@version": 1.1@protected": trueat top-levelesrsnamespaced 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: https://github.com/w3c-ccg/lds-ecdsa-secp256k1-2019/issues/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?
proofdefinition - I assume this is useful for proofs on objects other than VCs/VPs (not having the Credentials base context that definesproof).Support for
blockchainAccountIdis 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.1is needed (I am not sure I understand the consensus) is discussed in https://github.com/w3c-ccg/security-vocab/pull/95#discussion_r611047814.Changing the proof type and verification method type to use w3id/sec namespace instead of dif/esrs namespace was mentioned in https://github.com/w3c-ccg/security-vocab/pull/95#issuecomment-838555029. Using the separate namespace was questioned in https://github.com/perma-id/w3id.org/pull/2108#issuecomment-818387984. 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