主页EIPs周刊
EIPsEIP-7749
EIP-7749

Add wallet_signIntendedValidatorData method

A new RPC method to sign data with an intended validator address according to ERC-191 version 0x00.
DraftStandards Track: Interface
创建时间: 2024-06-21
关联 EIP: EIP-191, EIP-712
Yamen Merhi (@YamenMerhi), Patronum Labs (@Patronum-Labs)
社区讨论原文链接编辑
1 分钟了解
欢迎补充好内容
去提交
相关视频
欢迎补充好内容
去提交
正文

Abstract

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:

0x19 <0x00> <intended validator address> <data to sign>

Motivation

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:

  • 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

interface WalletSignIntendedValidatorDataParams { signerAddress: string; validatorAddress: string; dataToSign: string; }
  1. signerAddress - 20-byte account address: The address signing the constructed message.
  2. validatorAddress - 20-byte account address: The intended validator address included in the message to sign.
  3. dataToSign - Data string: The data to sign.

Returns

Signature - The Ethereum Signature generated.

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.

Test Cases

Example

  • 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 verfying the signature, could be an EOA or a 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:

curl -X POST --data '{"jsonrpc":"2.0","method":"wallet_signIntendedValidatorData","params":["0x6aFbBC5e6AFcB251371711a6551E60ead2779Dc0", "0x345B918b9E06fAa7B0e56bd71Ba418F31F47FED4", "0x59616d656e"], "id":1}'
{ "jsonrpc": "2.0", "method": "wallet_signIntendedValidatorData", "params": [ "0x6aFbBC5e6AFcB251371711a6551E60ead2779Dc0", "0x345B918b9E06fAa7B0e56bd71Ba418F31F47FED4", "0x59616d656e" ], "id": 1 }

Result:

{ "jsonrpc": "2.0", "id": 1, "result": "0x4355c47d63924e8a72e509b65029052eb6c299d53a04e167c5775fd466751c9d07299936d304c153f6443dfa05f40ff007d72911b6f72307f996231605b915621c" }

The result field contains the Ethereum signature generated by signing the hashed message according to version 0 of ERC-191.

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 and related rights waived via CC0.

扩展阅读
欢迎补充好内容
去提交
相关项目
欢迎补充好内容
去提交

不想错过最新的 EIP 动态?

订阅 EIPs Fun 周刊以跟进相关更新,建⽴你与 EIP 之间的连接 ,更好地建设以太坊。

详情
支持以太坊贡献者,推动生态建设
资源
GitHub
支持社区