From 026675e59eacf773e081093c06155a2e924d2f7b Mon Sep 17 00:00:00 2001 From: Philippe Castonguay Date: Mon, 3 Dec 2018 17:21:20 -0500 Subject: [PATCH] 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 | 46 +++++++++++++++++++++++++++++----------------- 1 file changed, 29 insertions(+), 17 deletions(-) diff --git a/EIPS/eip-1271.md b/EIPS/eip-1271.md index 8e5e9fb0..94b8551e 100644 --- a/EIPS/eip-1271.md +++ b/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 -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