Add ERC: EIP-712 Extensions for Account Abstraction #693
Conversation
eip-review-bot
changed the title
Co-authored-by: Andrew B Coathup <[email protected]>
frangio
changed the title
eip-review-bot
changed the title
| In the presence of `signingDomains` the account should encode the message to be signed according to the following recursive procedure: | ||
|
|
||
| - `encodeForSigningDomains(signingDomainSeparators : [𝔹²⁵⁶], verifyingDomainSeparator : 𝔹²⁵⁶, message : 𝕊) =` | ||
| - If `signingDomainSeparators = [first, ...others]`: `"\x19\x02" ‖ first ‖ encodeForSigningDomains(others, verifyingDomainSeparator, message)` |
There was a problem hiding this comment.
Is first the initial dapp domain? If so, I think dapp would be more explicit:
| - If `signingDomainSeparators = [first, ...others]`: `"\x19\x02" ‖ first ‖ encodeForSigningDomains(others, verifyingDomainSeparator, message)` | |
| - If `signingDomainSeparators = [dapp, ...others]`: `"\x19\x02" ‖ dapp ‖ encodeForSigningDomains(others, verifyingDomainSeparator, message)` |
There was a problem hiding this comment.
IIUC - signingDomainSeparators is a new addition and will only contain account domains. The dapp domain is the domain in L54
There was a problem hiding this comment.
Yes these are distinct from the dapp domain.
|
|
||
| - `id`: An string that identifies the method. It may be one of: | ||
| - `ECDSA`: ECDSA signatures by Externally Owned Accounts. | ||
| - `ERC-{n}`: A standard type of signature specified by an ERC. `n` must not be padded with zeros. |
There was a problem hiding this comment.
Is there an authentication method other than ERC-1271? If 1271 is generalized enough I think this can be simplified to just ECDSA or ERC-1271.
In the case we want to make this ERC more broadly compatible, then it may make sense to define the signature algorithms supported by other networks (e.g. ed25519 in cosmos). I feel this is not the case
There was a problem hiding this comment.
Is there an authentication method other than ERC-1271?
Yes, ERC-6492 is another standard that is mentioned earlier in the Motivation section. It covers a scenario that ERC-1271 doesn't (predeploy contracts). I'd rather keep this generic than listing the standards that exist now.
| Each member of the array is an object with the following keys: | ||
|
|
||
| - `id`: An string that identifies the method. It may be one of: | ||
| - `ECDSA`: ECDSA signatures by Externally Owned Accounts. |
There was a problem hiding this comment.
I feel we the spec should suggest priority for ERC-1271 if there's code in the address. Just as we do in SignatureChecker since after EIP-7702, the validation mechanism should decide whether to prioritize ECDSA or ERC-1271.
There was a problem hiding this comment.
I agree that if there's code ERC-1271 should take priority but not all contracts implement it that way (e.g., prior versions of OpenZeppelin Contracts didn't), so if a dapp needs a signature for one of those contracts it should be possible to express that order of preferences.
There was a problem hiding this comment.
This is explained in the Motivation section too, let me know if it's not clear.
frangio
changed the title
eip-review-bot
changed the title
|
The commit bd681c7 (as a parent of 7feed84) contains errors. |
Moved from ethereum/EIPs#8985