You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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?
The text was updated successfully, but these errors were encountered:
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 anethereumAddress
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 ofblockchainAccountId
.blockchainAccountId
can be used to represent an Ethereum address. Bothdid-spec-registries
and security-vocab contain examples usingEcdsaSecp256k1RecoveryMethod2020
withblockchainAccountId
. ethr-did-resolver recently updated to useblockchainAccountId
instead ofethereumAddress
.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 withEcdsaSecp256k1RecoverySignature2020
. ShouldEcdsaSecp256k1RecoveryMethod2020
specify that it can be used with anyblockchainAccountId
that corresponds to a Secp256k1 keypair? Should some chain IDs (CAIP-2) be listed as required or recommended for implementers ofEcdsaSecp256k1RecoveryMethod2020
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
?The text was updated successfully, but these errors were encountered: