@pedrouid Would you mind updating the official ERC draft to reflect this? Also, why did the EIP712 and EthSign type swap? EIP712 used to be the one before. I don’t mind either way, but I’ve personally been using the following:
| Signature byte | Signature type |
|---|---|
| 0x00 | Illegal |
| 0x01 | EIP712 |
| 0x02 | EthSign |
| 0x03 | EIP1271 |
| 0x04 | EIP1654 |
As can be seen in this contract.
I raised an issue that was addressed a while back, and I’d like to re-submit it.
I think this enumeration put some very different thinks at the same level, like if there was a choice between them when it’s more of a combination.
EthSign and EIP712 are standard on how to compute a digest (aka challengeHash) which signature’s is checked at a further point. This allows signature verification mechanisms supporting a single type (bytes32) to extend to any message with some guaranties.
EIP1271, EIP1654 (and ecrecover) are standards that describe how to check the actual signature against the digest produced earlier.
What I mean is we can have EthSign + ecrecover (most common case today), EthSign + EIP1271, EIP712 + ecrecover , EIP712 + EIP1271, … depending of the digest scheme and the signing account specifications.
That being said, I understand this enumeration does not allow combination of bytes. What Signature byte should be set in the case of an structure signed with EIP712 hashing by a wallet using EIP1271 ?
EIP 712 changed significantly over time, there are now 4 variations out there (MetaMask supports 3: v1, v3, v4), so it might be worth either reserving an identifier for each, or specifying which is intended by this standard.
v1: Was very simple, just a key-value store, no array or struct support.
v2: Cipher browser was the only one to implement it, I’m unaware of where to find docs on it.
v3: Added array support
v4: Added struct, and recursive type support.
Our docs on these are not great at the moment, but here’s a lead: https://metamask.github.io/metamask-docs/API_Reference/Signing_Data/Sign_Typed_Data_v4
Actually do we even need EIP712? Signature verification should be independent of its structure right?
If a Dapp requests an eth_sign or eth_signTypedData, it will verify the signature the same way no matter if it’s a EOA or Smart Contract Wallet.
Correct me if I’m wrong but it would be more reasonable to focus this EIP in uniquely different verification processes:
| Signature byte | Signature type | Signature verification |
|---|---|---|
| 0x00 | Illegal | None |
| 0x01 | EIP191 | ecrecover |
| 0x02 | EIP1271 | isValidSignature(bytes, bytes) |
| 0x03 | EIP1654 | isValidSignature(bytes32, bytes) |
PS - Actually eth_sign and eth_signTypedData are described under EIP191 so I’ve renamed from EthSign to EIP191 in the table too
PSS - I just noticed that @Amxx had already mentioned that EIP712 didn’t really make sense to be indexed
Which signature type uses the “Compact Signature”, where it 65 bytes size? This is used by Gnosis Wallet, see https://github.com/gnosis/safe-contracts/blob/development/contracts/common/SignatureDecoder.sol#L38-L40
Perhaps we need to standardize that aswell. This is important, because wallets should be aware that the signature should be provided in this format.
I opened an issue at gnosis wallet here https://github.com/gnosis/safe-contracts/issues/169 detailing it, and where it came from.
Another thing to consider https://eips.ethereum.org/EIPS/eip-2098