-
Notifications
You must be signed in to change notification settings - Fork 61
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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:/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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to confirm, will we need to complete this section for verification?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 to failing when in doubt
@@ -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 { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same note here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Based on: #94
Implements did:ethr. There are some some differences compared to the
did:ethr
spec, 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.