Add support for EIPE 191 Version 0 (Intended Validator Data)

Feature Requests
1

Description: MetaMask currently supports two versions of EIP191:

  • Version 0x45: Ethereum Signed Message (rpc method personal_sign), which is the most widely used.
  • Version 1: EIP712 (eth_signTypedData_v4), which is also somewhat utilized.

However, EIP191 version 0, which allows for signing data with an intended validator, is not supported by MetaMask. This limitation forces users to rely on eth_sign, which is highly restricted and displays severe warnings due to its potential dangers.

Version 0 is being more used now after it has been added to OpenZeppelin library, Snekmate for Vyper, and JS tools that encode the message structure.

Seeing specific features for new EIPs being worked on, like signing operation for 4337, it does make sense to fully support an old EIP, and then continue to the new EIPs.

Purpose: Adding support for eth_signIntendedValidatorData will:

  • Enable more dApps to use MetaMask without triggering security warnings.
  • Allow for the parsing of data to be signed, such as Validator and Validator Specific Data.
  • Provide a safer alternative to eth_sign by specifying an intended validator, thereby reducing phishing risks.
  • Offer a simpler and more secure option compared to the complex EIP712 and the broadly used but risky EIP191 version 0x45, which is often used for login messages and other purposes.
  • Be particularly relevant for smart contract accounts, as it allows for signing data with a specific intended validator address.

Extension/Mobile/Both: Both

Images/Attachments: N/A

2

While I think it’s great to support more signature mechanism, I have concern that this will generate more unreadable signatures and expose users to phishing attack. How do we mitigate the risk if we approve the proposal?

3

I think it is similar to version x19 (/Ethereum Signed Message), aside from that it could be even more specific and limit the phishing.

When you’re signing, you need to specify as well the address of the validator, and usually, contracts/apps will request that the sig is relevant only to the validator address and several contracts use it and specify that the signature is only linked to 1 unique validator address, but I can’t post links for reference.

In this case on MetaMask UI, it can be parsed with 2 fields:

  • The validator address (Which should be verifiable by users)
  • The message

While with x19/EthereumSignedMessage, they can see an arbitrary message signed without indication of where it will be consumed.

Even this version is not ideal, but I would see it as more specific and safer than x19/Ethereum Signed Message and less complex from 712 Sigs.