Automatically merged updates to draft EIP(s) 1271

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-1271.md

@@ -1,7 +1,7 @@
 ---
 eip: 1271
 title: Standard Signature Validation Method for Contracts 
-author:  Francisco Giordano (@frangio), Matt Condon (@shrugs), Philippe Castonguay (@PhABC)
+author:  Francisco Giordano (@frangio), Matt Condon (@shrugs), Philippe Castonguay (@PhABC), Amir Bandeali (@abandeali1), Jorge Izquierdo (@izqui), Bertrand Masius (@catageek)
 discussions-to: https://github.com/ethereum/EIPs/issues/1271
 status: Draft
 type: Standards Track
@@ -36,36 +36,48 @@ One example of an application that requires addresses to provide signatures woul
 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt).
 
 ```javascript
-/**
-* @dev Should return whether the signature provided is valid for the provided data
-* @param _data Arbitrary length data signed on the behalf of address(this)
-* @param _signature Signature byte array associated with _data
-*
-* MUST return a bool upon valid or invalid signature with corresponding _data
-* MUST take (bytes, bytes) as arguments
-* MUST allow external calls
-*/ 
-function isValidSignature(
-    bytes _data, 
-    bytes _signature)
+pragma solidity ^0.5.0;
+
+contract ERC1271 {
+
+  // bytes4(keccak256("isValidSignature(bytes,bytes)")
+  bytes4 constant internal MAGICVALUE = 0x20c13b0b;
+
+  /**
+   * @dev Should return whether the signature provided is valid for the provided data
+   * @param _data Arbitrary length data signed on the behalf of address(this)
+   * @param _signature Signature byte array associated with _data
+   *
+   * MUST return the bytes4 magic value 0x20c13b0b when function passes.
+   * MUST NOT modify state (using STATICCALL for solc < 0.5, view modifier for solc > 0.5)
+   * MUST allow external calls
+   */ 
+  function isValidSignature(
+    bytes memory _data, 
+    bytes memory _signature)
     public
     view 
-    returns (bool isValid); 
+    returns (bytes4 magicValue);
+}
 ```
 
-`isValidSignature` can call arbitrary methods to validate a given signature, which could be context dependent (e.g. time based or state based), EOA dependant (e.g. signers authorization level within smart account), signature scheme Dependant (e.g. ECDSA, multisig, BLS), etc.
+`isValidSignature` can call arbitrary methods to validate a given signature, which could be context dependent (e.g. time based or state based), EOA dependant (e.g. signers authorization level within smart wallet), signature scheme Dependant (e.g. ECDSA, multisig, BLS), etc.
 
 
 
 ## Rationale
 <!--The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.-->
 
-Such a function is important because it allows *other contracts* to validate signed messages on the behalf of the smart account. This is necessary because not all signed messages will first pass by the smart account as in ERC-1077, since signatures can be requested by independent contracts. Action based signed messages do not require this method for external contracts since the action is `Smart Account A -> Contract C` (e.g. owner of smart account `A` wants to transfer tokens `T` to contract `C`), but when the action is in the opposite direction (`Contract A -> SmartAccount`) this external function is necessary (e.g. `contract A` requires smart account `A` to transfer tokens `T` when event `E` is triggered). 
+Such a function is important because it allows *other contracts* to validate signed messages on the behalf of the smart wallet. This is necessary because not all signed messages will first pass by the smart wallet as in ERC-1077, since signatures can be requested by independent contracts. Action based signed messages do not require this method for external contracts since the action is `smart wallet A -> Contract C` (e.g. owner of smart wallet `A` wants to transfer tokens `T` to contract `C`), but when the action is in the opposite direction (`Contract A -> SmartAccount`) this external function is necessary (e.g. `contract A` requires smart wallet `A` to transfer tokens `T` when event `E` is triggered). 
 
-We believe the name of the proposed function to be appropriate considering that an *authorized* signers providing proper signatures for a given data would see their signature as "valid" by the smart account. Hence, an signed action message is only valid when the signer is authorized to perform a given action on the behalf of a smart account. 
+We believe the name of the proposed function to be appropriate considering that an *authorized* signers providing proper signatures for a given data would see their signature as "valid" by the smart wallet. Hence, an signed action message is only valid when the signer is authorized to perform a given action on the behalf of a smart wallet. 
 
 Two arguments are provided for simplicity of separating the data from the signature, but both could be concatenated in a single byte array if community prefers this.
 
+`isValidSignature()` should not be able to modify states in order to prevent `GasToken` minting or similar attack vectors. A gas limit being passed is being considered, but could prevent some interesting use cases like large multisignatures or more costly validation and cryptographic schemes.  
+
+
+
 ## Backwards Compatibility
 <!--All EIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The EIP must explain how the author proposes to deal with these incompatibilities. EIP submissions without a sufficient backwards compatibility treatise may be rejected outright.-->