Add did:ethr and EIP-712-based linked data proof type #99
Conversation
|
Hi, is this ready for review? The CI seems to have failed--but also we have just merged in #94. |
|
@wyc ready for review. I just pushed a fixup commit to try to fix the CI failure. |
|
Rebased. |
| } | ||
|
|
||
| /// [`encodeData`](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-712.md#definition-of-encodedata) | ||
| pub fn encode(&self, _type: &Struct, _types: &Types) -> Result<Vec<u8>, TypedDataHashError> { |
There was a problem hiding this comment.
Just to confirm, will we need to complete this section for verification?
There was a problem hiding this comment.
Yes, unless using another EIP-712 implementation.
| @@ -159,6 +176,12 @@ impl LinkedDataProofs { | |||
| x509_thumbprint_sha256: _, | |||
| } if ec_params.curve == Some("secp256k1".to_string()) => { | |||
| if algorithm.as_ref() == Some(&Algorithm::ES256KR) { | |||
| #[cfg(feature = "keccak-hash")] | |||
| if let Some(ref vm) = options.verification_method { | |||
| if vm.ends_with("#Eip712Method2021") { | |||
There was a problem hiding this comment.
What's the best way to document our VM support? Are we okay with treating it as EcdsaSecp256k1RecoverySignature2020 if we don't compile in keccak support?
There was a problem hiding this comment.
Could this cause problems in some circumstances? I'm thinking that perhaps the feature flag should specify eip712 and require keccak-hash, but happy to merge these changes and discuss this in an issue.
There was a problem hiding this comment.
This should probably instead fail here (if VM ends in #Eip712Method2021 but the feature is not enabled), since passing a VM ending in #Eip712Method2021 is currently the only way for the caller to choose Eip712Signature2021. Ideally the proof type should be chosen by the verificationMethod option entirely instead of by the key type as this function currently does. During signing, we would then deference the verificationMethod option to a verification method object (map) in the DID document, and then select the corresponding proof type, or error if it is unsupported.
VM support could be documented in a readme, or in some markdown files listing supported functionality/standards, or in the docs repo, and/or in the Rust docs.
| @@ -196,6 +219,12 @@ impl LinkedDataProofs { | |||
| return EcdsaSecp256k1Signature2019::prepare(document, options, public_key).await | |||
| } | |||
| Algorithm::ES256KR => { | |||
| #[cfg(feature = "keccak-hash")] | |||
| if let Some(ref vm) = options.verification_method { | |||
Based on: #94
Implements did:ethr. There are some some differences compared to the
did:ethrspec, due to updates to DID Core and usingEcdsaSecp256k1RecoveryMethod2020, as mentioned in decentralized-identity/ethr-did-resolver#99; and to add a second verification method using a new experimental linked data proof type based on EIP-712.The linked data proof type based on EIP-712 is named
Eip712Method2021. The signing payload includes the URDNA2015-canonicalized linked data document (credential) and options (proof) rendered as an array of RDF statements where each statement (quad/triple) is an array of 3 or 4 strings.Eip712Method2021 is not yet fully implemented here as the EIP-712 hashing is incomplete. So it can only be used via external signing, and does not yet have verification working.