ERC-2126: Signature Type Recognition

@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.

    • The choice here is app based. If the 0x protocole uses EIP712 signature I, as a user, have to use this scheme.
  • EIP1271, EIP1654 (and ecrecover) are standards that describe how to check the actual signature against the digest produced earlier.

    • This is the part we want to make “universal” as its availability dependes on the wallet used by the user. External accounts support direct ecrecover. Smart contract based wallet do not support ecrecover but can support EIP1271 and or EIP1654. We would like dapps to support these seamlessly.

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 ?

1 Like

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

3 Likes

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