Add EIP: Add wallet_signIntendedValidatorData method

Merged by EIP-Bot.

EIPS/eip-7749.md

@@ -0,0 +1,102 @@
+---
+eip: 7749
+title: Add wallet_signIntendedValidatorData method
+description: A new RPC method to sign data with an intended validator address according to ERC-191 version 0x00.
+author: Yamen Merhi (@YamenMerhi), Patronum Labs (@Patronum-Labs)
+discussions-to: https://ethereum-magicians.org/t/eip-7749-add-wallet-signintendedvalidatordata-method/20693
+status: Draft
+type: Standards Track
+category: Interface
+created: 2024-06-21
+requires: 191, 712
+---
+
+## Abstract
+
+This EIP introduces a new JSON-RPC method, `wallet_signIntendedValidatorData`, which allows signing data with an intended validator address using [ERC-191](./eip-191.md) version 0x00 with this format:
+
+```bash
+0x19 <0x00> <intended validator address> <data to sign>
+```
+
+## Motivation
+
+Currently, signing messages relies heavily on ERC-191 version 0x45 (`eth_sign`) and [EIP-712](./eip-712.md) (`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:
+
+- Enable more dApps to use ERC-191 version 0x00 without using raw signing methods which might be dangerous and restricted in few wallets.
+- Enhance security by parsing data and displaying the intended validator address, reducing phishing risks.
+- Provide a simpler alternative to EIP-712, offering a balance between usability and security.
+- Be particularly relevant for smart contract accounts, allowing signing with a specific intended validator address.
+
+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.
+
+## Specification
+
+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_signIntendedValidatorData`
+
+MUST calculate an Ethereum signature using `sign(keccak256("\x19\x00<signature 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.
+
+#### Parameters
+
+1. `DATA` - 20-byte account address: The address signing the constructed message.
+2. `DATA` - 20-byte account address: The intended validator address included in the message to sign.
+3. `DATA` - Data string: The data to sign.
+
+#### Returns
+
+`DATA` - Signature.
+
+#### Example
+
+**Request:**
+
+```bash
+curl -X POST --data '{"jsonrpc":"2.0","method":"wallet_signIntendedValidatorData","params":["0x6aFbBC5e6AFcB251371711a6551E60ead2779Dc0", "0x345B918b9E06fAa7B0e56bd71Ba418F31F47FED4", "0x59616d656e"], "id":1}'
+```
+
+```json
+{
+  "jsonrpc": "2.0",
+  "method": "wallet_signIntendedValidatorData",
+  "params": [
+    "0x6aFbBC5e6AFcB251371711a6551E60ead2779Dc0",
+    "0x345B918b9E06fAa7B0e56bd71Ba418F31F47FED4",
+    "0x59616d656e"
+  ],
+  "id": 1
+}
+```
+
+**Result:**
+
+```json
+{
+  "jsonrpc": "2.0",
+  "id": 1,
+  "result": "0x4355c47d63924e8a72e509b65029052eb6c299d53a04e167c5775fd466751c9d07299936d304c153f6443dfa05f40ff007d72911b6f72307f996231605b915621c"
+}
+```
+
+## Rationale
+
+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.
+
+## Backwards Compatibility
+
+No backward compatibility issues found.
+
+## Security Considerations
+
+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
+
+Copyright and related rights waived via [CC0](../LICENSE.md).