mirror of https://github.com/status-im/EIPs.git
57 lines
3.4 KiB
Markdown
57 lines
3.4 KiB
Markdown
|
## Preamble
|
||
|
|
|
||
|
|
EIP: <to be assigned>
|
||
|
|
Title: Generalised authorisations
|
||
|
|
Author: Nick Johnson <nick@ethereum.org>
|
||
|
|
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/).
|