From 79509bed927c61c9624f0f460d0faeb68845c249 Mon Sep 17 00:00:00 2001 From: Nick Johnson Date: Mon, 12 Mar 2018 12:54:18 +0000 Subject: [PATCH 1/2] Create EIP-X-authorisations-nickjohnson.md --- EIPS/EIP-X-authorisations-nickjohnson.md | 56 ++++++++++++++++++++++++ 1 file changed, 56 insertions(+) create mode 100644 EIPS/EIP-X-authorisations-nickjohnson.md diff --git a/EIPS/EIP-X-authorisations-nickjohnson.md b/EIPS/EIP-X-authorisations-nickjohnson.md new file mode 100644 index 00000000000000..a754f94dfe034d --- /dev/null +++ b/EIPS/EIP-X-authorisations-nickjohnson.md @@ -0,0 +1,56 @@ +## Preamble + + EIP: + Title: Generalised authorisations + Author: Nick Johnson + Type: Standard track + Category: ERC + Status: Draft + Created: 2018-03-12 + +## Abstract +This EIP specifies a generic authorisation mechanism, which can be used to implement a variety of authorisation patterns, replacing approvals in ERC20, operators in ERC777, and bespoke authorisation patterns in a variety of other types of contract. + +## Motivation +Smart contracts commonly need to provide an interface that allows a third-party caller to perform actions on behalf of a user. The most common example of this is token authorisations/operators, but other similar situations exist throughout the ecosystem, including for instance authorising operations on ENS domains. Typically each standard reinvents this system for themselves, leading to a large number of incompatible implementations of the same basic pattern. Here, we propose a generic method usable by all such contracts. + +The pattern implemented here is inspired by [ds-auth](https://github.com/dapphub/ds-auth) and by OAuth. + +## Specification +The generalised authorisation interface is implemented as a metadata provider, as specified in EIP-X-metadata-nickjohnson. The following mandatory function is implemented: + +``` +function canCall(address owner, address caller, address callee, bytes4 func) view returns(bool); +``` + +Where: + - `owner` is the owner of the resource. If approved the function call is treated as being made by this address. + - `caller` is the address making the present call. + - `callee` is the address of the contract being called. + - `func` is the 4-byte signature of the function being called. + +For example, suppose Alice authorises Bob to transfer tokens on her behalf. When Bob does so, Alice is the `owner`, Bob is the `caller`, the token contract is the `callee`, and the function signature for the transfer function is `func`. + +As this standard uses EIP-X-metadata-nickjohnson, the authorisation flow is as follows: + + 1. The callee contract fetches the provider for the `owner` address from the metadata registry contract, which resides at a well-known address. + 2. The callee contract calls `canCall()` with the parameters described above. If the function returns false, the callee reverts execution. + +Commonly, providers will wish to supply a standardised interface for users to set and unset their own authorisations. They SHOULD implement the following interface: + +``` +function authoriseCaller(address owner, address caller, address callee, bytes4 func, bool authorised); +``` + +Arguments have the same meaning as in `canCall`, with the addition of `authorised,` which specifies if the authorisation is being set or cleared. Implementing contracts MUST ensure that `msg.sender` is authorised to call `authoriseCaller` on behalf of `owner`; this MUST always be true if `owner == msg.sender`. Implementing contracts SHOULD use the standard specified here to determine if other callers may provide authorisations as well. + +Implementing contracts SHOULD treat a `func` of 0 as authorising calls to all functions on `callee`. If `authorised` is `false` and `func` is 0, contracts need only clear any blanket authorisation; individual authorisations may remain in effect. + +## Backwards Compatibility +There are no backwards compatibility concerns. + +## Implementation +Example implementation TBD. + +## Copyright +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From 6519f179a9f2f2cc875c8057d5664d96e3376a5a Mon Sep 17 00:00:00 2001 From: Nick Johnson Date: Mon, 12 Mar 2018 13:51:12 +0000 Subject: [PATCH 2/2] Update EIP-X-authorisations-nickjohnson.md --- EIPS/EIP-X-authorisations-nickjohnson.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/EIPS/EIP-X-authorisations-nickjohnson.md b/EIPS/EIP-X-authorisations-nickjohnson.md index a754f94dfe034d..31e93fb8e07575 100644 --- a/EIPS/EIP-X-authorisations-nickjohnson.md +++ b/EIPS/EIP-X-authorisations-nickjohnson.md @@ -39,10 +39,11 @@ As this standard uses EIP-X-metadata-nickjohnson, the authorisation flow is as f Commonly, providers will wish to supply a standardised interface for users to set and unset their own authorisations. They SHOULD implement the following interface: ``` -function authoriseCaller(address owner, address caller, address callee, bytes4 func, bool authorised); +function authoriseCaller(address owner, address caller, address callee, bytes4 func); +function revokeCaller(address owner, address caller, address callee, bytes4 func); ``` -Arguments have the same meaning as in `canCall`, with the addition of `authorised,` which specifies if the authorisation is being set or cleared. Implementing contracts MUST ensure that `msg.sender` is authorised to call `authoriseCaller` on behalf of `owner`; this MUST always be true if `owner == msg.sender`. Implementing contracts SHOULD use the standard specified here to determine if other callers may provide authorisations as well. +Arguments have the same meaning as in `canCall`. Implementing contracts MUST ensure that `msg.sender` is authorised to call `authoriseCaller` or `revokeCaller` on behalf of `owner`; this MUST always be true if `owner == msg.sender`. Implementing contracts SHOULD use the standard specified here to determine if other callers may provide authorisations as well. Implementing contracts SHOULD treat a `func` of 0 as authorising calls to all functions on `callee`. If `authorised` is `false` and `func` is 0, contracts need only clear any blanket authorisation; individual authorisations may remain in effect.