search

decentralized-identity / EcdsaSecp256k1RecoverySignature2020

EcdsaSecp256k1RecoverySignature2020
https://identity.foundation/EcdsaSecp256k1RecoverySignature2020/docs/
Apache License 2.0
9 stars 13 forks source link

Generalized public key verification #10

Open clehner opened 3 years ago

clehner commented 3 years ago

I understand that EcdsaSecp256k1RecoverySignature2020 is supposed to enable linked data proofs where the verification method does not contain the public key but contains material to verify the recovered public key. For example, if the verification method contains an ethereumAddress property, we can verify that the address value can be reconstructed by hashing the recovered public key as Ethereum would do it.

did-spec-registries says that ethereumAddress is deprecated in favor of blockchainAccountId. blockchainAccountId can be used to represent an Ethereum address. Both did-spec-registries and security-vocab contain examples using EcdsaSecp256k1RecoveryMethod2020 with blockchainAccountId. ethr-did-resolver recently updated to use blockchainAccountId instead of ethereumAddress.

blockchainAccountId uses CAIP-10 and can represent account IDs on many blockchains, not just Ethereum. Some of the other blockchains, such as Bitcoin, also use ECDSA/Secp256k1, and so could theoretically also be used with EcdsaSecp256k1RecoverySignature2020. Should EcdsaSecp256k1RecoveryMethod2020 specify that it can be used with any blockchainAccountId that corresponds to a Secp256k1 keypair? Should some chain IDs (CAIP-2) be listed as required or recommended for implementers of EcdsaSecp256k1RecoveryMethod2020 to support?

Additionally, some applications may use Secp256k1 outside a blockchain context. Could verification of a secp256k1 public key be expressed in a more general way than blockchainAccountId?