This EIP introduces a new JSON-RPC method, wallet_signIntendedValidatorData, which allows signing data with an intended validator address using ERC-191 version 0x00 with this format:
Currently, signing messages relies heavily on ERC-191 version 0x45 (eth_sign) and EIP-712 (eth_signTypedData). While EIP-712 provides a more structured approach, it is often seen as complex. On the other hand, ERC-191 version 0x45 is widely used but poses significant phishing risks due to the lack of data parsing.
ERC-191 defines three versions: 0x45, 0x01, and 0x00. This proposal aims to fully support ERC-191 by introducing the rpc call for 0x00 version, which enables signing data with an intended validator address. This new method will:
With the rise of smart contract accounts and the reliance on signatures to improve UX, the need for supporting ERC-191 version 0x00 increases, especially given the prevalence of verifier smart contracts, such as Entry Points, Smart Contract Accounts, Key Managers, etc.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
wallet_signIntendedValidatorDataMUST calculate an Ethereum signature using sign(keccak256("\x19\x00<intended validator address><data to sign>")).
This method adds a prefix to the message to prevent malicious dApps from signing arbitrary data (e.g., a transaction) and using the signature to impersonate the victim.
signerAddress - 20-byte account address: The address signing the constructed message.validatorAddress - 20-byte account address: The intended validator address included in the message to sign.dataToSign - Data string: The data to sign.Signature - The Ethereum Signature generated.
The wallet_signIntendedValidatorData method aims to bridge the gap between the simplicity of ERC-191 version 0x45 and the structured approach of EIP-712. By specifying the intended validator address, it reduces phishing risks and provides a more secure signing method for smart contract accounts and other use cases requiring a specific validator address.
No backward compatibility issues found.
Signer Address (0x6aFbBC5e6AFcB251371711a6551E60ead2779Dc0): This is the address of the account that will be used to sign the constructed message. We have access to the private key of this address, which allows us to generate the signature securely.
Verifier Address (0x345B918b9E06fAa7B0e56bd71Ba418F31F47FED4): This address represents the address verifying the signature, could be an EOA or smart contract. For example, it could be a contract that performs specific actions based on the validity of the signature. By including this address in the data to be signed, we ensure that the signature cannot be reused by malicious actors for unintended purposes.
Data to Sign (0x59616d656e): This is the hex-encoded string representing the actual content to be signed. In this example, it is the hex encoding for the ASCII string "Yamen". The data, combined with the verifier address, is hashed and signed to generate a unique signature that cannot be used for any other purpose.
Request:
Result:
The result field contains the Ethereum signature generated by signing the hashed message according to version 0 of ERC-191.
Users should exercise caution when signing messages. Double-check the address of the verifier and ensure trust in the dApp triggering the sign request.
To protect against replay attacks and cross-chain replay attacks, include chainId and nonce in the validator data to sign.
Copyright and related rights waived via CC0.