From 6e68ede11fec7d7096ee381f5a15d367a92cc57e Mon Sep 17 00:00:00 2001 From: Erik Marks <25517051+rekmarks@users.noreply.github.com> Date: Wed, 3 Jun 2020 22:26:29 -0700 Subject: [PATCH] Automatically merged updates to draft EIP(s) 1193 (#2694) Hi, I'm a bot! This change was automatically merged because: - It only modifies existing Draft or Last Call EIP(s) - The PR was approved or written by at least one author of each modified EIP - The build is passing --- EIPS/eip-1193.md | 65 +++++++++++++++++++++++++++++++++++++++--------- 1 file changed, 53 insertions(+), 12 deletions(-) diff --git a/EIPS/eip-1193.md b/EIPS/eip-1193.md index 3556d1a5..bf1665fb 100644 --- a/EIPS/eip-1193.md +++ b/EIPS/eip-1193.md @@ -51,8 +51,8 @@ You can find a list of common methods [here](https://eips.ethereum.org/EIPS/eip- Multiple RPC protocols may be available. For examples, see: -- [EIP 1474](https://eips.ethereum.org/EIPS/eip-1474), the Ethereum JSON-RPC API -- [EIP 1767](https://eips.ethereum.org/EIPS/eip-1767), the Ethereum GraphQL schema +- [EIP-1474](https://eips.ethereum.org/EIPS/eip-1474), the Ethereum JSON-RPC API +- [EIP-1767](https://eips.ethereum.org/EIPS/eip-1767), the Ethereum GraphQL schema ### sendAsync (DEPRECATED) @@ -125,7 +125,7 @@ The event emits a hexadecimal string `chainId` per the `eth_chainId` Ethereum RP The event `networkChanged` is deprecated in favor of [`chainChanged`](#chainchanged). -For details, see [EIP 155: Simple replay attack protection](https://eips.ethereum.org/EIPS/eip-155) and [EIP 695: Create eth_chainId method for JSON-RPC](https://eips.ethereum.org/EIPS/eip-695). +For details, see [EIP-155: Simple replay attack protection](https://eips.ethereum.org/EIPS/eip-155) and [EIP-695: Create eth_chainId method for JSON-RPC](https://eips.ethereum.org/EIPS/eip-695). #### accountsChanged @@ -279,9 +279,11 @@ _This section is non-normative._ - Provider - A JavaScript object made available to a dapp, that provides access to Ethereum by means of a Client. - Client - - An endpoint accessed by a Provider, that receives Remote Procedure Call (RPC) requests and returns their results. + - An endpoint that receives Remote Procedure Call (RPC) requests from the Provider, and returns their results. +- Wallet + - An end-user application that manages private keys, performs signing operations, and acts as a middleware between the Provider and the Client. - Remote Procedure Call (RPC) - - A Remote Procedure Call (RPC), is any request submitted to a Provider for some procedure that is to be processed by a Provider or its Client. + - A Remote Procedure Call (RPC), is any request submitted to a Provider for some procedure that is to be processed by a Provider, its Wallet, or its Client. ### Availability @@ -341,8 +343,8 @@ If the returned Promise rejects, it **MUST** reject with a `ProviderRpcError` as The returned Promise **MUST** reject if any of the following conditions are met: -- The client returns an error for the RPC request. - - If the error returned from the client is compatible with the `ProviderRpcError` interface, the Promise **MAY** reject with that error directly. +- The Client returns an error for the RPC request. + - If the error returned from the Client is compatible with the `ProviderRpcError` interface, the Promise **MAY** reject with that error directly. - The Provider encounters an error or fails to process the request for any reason. > If the Provider implements any kind of authorization logic, the authors recommend rejecting with a `4100` error in case of authorization failures. @@ -480,15 +482,54 @@ If the accounts available to the Provider change, the Provider **MUST** emit the The "accounts available to the Provider" change when the return value of `eth_accounts` changes. +## Security Considerations + +_This section and its sub-sections are non-normative._ + +The Provider is intended to pass messages between an Ethereum Client and an Ethereum application. +It is _not_ responsible for private key or account management; it merely processes RPC messages and emits events. +Consequently, account security and user privacy need to be implemented in middlewares between the Provider and its Ethereum Client. +In practice, we call these middleware applications "Wallets," and they usually manage the user's private keys and accounts. +The Provider can be thought of as an extension of the Wallet, exposed in an untrusted environment, under the control of some third party (e.g. a dapp). + +### Handling Adversarial Behavior + +Since it is a JavaScript object, consumers can generally perform arbitrary operations on the Provider, and all its properties can be read or overwritten. +Therefore, it is best to treat the Provider object as though it is controlled by an adversary. +It is paramount that the Provider implementer protects the user, Wallet, and Client by ensuring that: + +- The Provider does not contain any private user data. +- The Provider and Wallet programs are isolated from each other. +- The Wallet and/or Client rate-limit requests from the Provider. +- The Wallet and/or Client validate all data sent from the Provider. + +### Chain Changes + +Since all Ethereum operations are directed at a particular chain, it's important that the Provider accurately reflects the Client's configured chain, per the `eth_chainId` Ethereum RPC method (see [EIP-695](https://eips.ethereum.org/EIPS/eip-155)). + +This includes ensuring that `eth_chainId` has the correct return value, and that the `chainChanged` event is emitted whenever that value changes. + +### User Account Exposure and Account Changes + +Many Ethereum write operations (e.g. `eth_sendTransaction`) require a user account to be specified. +Provider consumers access these accounts via the `eth_accounts` RPC method, and by listening for the `accountsChanged` event. + +As with `eth_chainId`, it is critical that `eth_accounts` has the correct return value, and that the `accountsChanged` event is emitted whenever that value changes. + +The return value of `eth_accounts` is ultimately controlled by the Wallet or Client. +In order to protect user privacy, the authors recommend not exposing any accounts by default. +Instead, Providers should support RPC methods for explicitly requesting account access, such as `eth_requestAccounts` (see [EIP-1102](https://eips.ethereum.org/EIPS/eip-1102)) or `wallet_requestPermissions` (see [EIP-2255](https://eips.ethereum.org/EIPS/eip-2255). + ## References - [Initial discussion in `ethereum/interfaces`](https://github.com/ethereum/interfaces/issues/16) -- [Ethereum Magicians thread](https://ethereum-magicians.org/t/eip-1193-ethereum-provider-javascript-api/640) -- [Continuing EIP-1193 discussion](https://github.com/ethereum/EIPs/issues/2319) +- [Deprecated Ethereum Magicians thread](https://ethereum-magicians.org/t/eip-1193-ethereum-provider-javascript-api/640) +- [Continuing discussion](https://github.com/ethereum/EIPs/issues/2319) - Related EIPs - - [EIP 1102](https://eips.ethereum.org/EIPS/eip-1102) - - [EIP 1474](https://eips.ethereum.org/EIPS/eip-1474) - - [EIP 1767](https://eips.ethereum.org/EIPS/eip-1767) + - [EIP-1102 (`eth_requestAccounts`)](https://eips.ethereum.org/EIPS/eip-1102) + - [EIP-1474 (JSON-RPC specification)](https://eips.ethereum.org/EIPS/eip-1474) + - [EIP-1767 (GraphQL RPC specification)](https://eips.ethereum.org/EIPS/eip-1767) + - [EIP-2255 (wallet permissions)](https://eips.ethereum.org/EIPS/eip-2255) ## Copyright