HomeEIPs
EIPsERC-927
ERC-927

Generalised authorisations

StagnantStandards Track: ERC
Created: 2018-03-12
Requires: EIP-926
Nick Johnson <nick@ethereum.org>
Original linkEdit
1 min read

The ERC-927 standard proposes a generic authorisation mechanism that can be used to implement various authorisation patterns in smart contracts. This mechanism replaces approvals in ERC20, operators in ERC777, and bespoke authorisation patterns in other types of contracts. The motivation behind this standard is to provide a standardised method for third-party callers to perform actions on behalf of a user in smart contracts. This is a common requirement in the ecosystem, and each standard typically reinvents the system for themselves, leading to a large number of incompatible implementations of the same basic pattern.

The generalised authorisation interface is implemented as a metadata provider, as specified in EIP 926. The interface includes a mandatory function called canCall, which takes in the owner address, caller address, callee address, and function signature as parameters. If the function returns false, the callee reverts execution.

The standard is inspired by ds-auth and OAuth, and it uses EIP 926 for the authorisation flow. The callee contract fetches the provider for the owner address from the metadata registry contract, which resides at a well-known address. Then, the callee contract calls canCall() with the parameters described above. If the function returns true, the callee contract can perform the action on behalf of the owner.

In summary, ERC-927 provides a standardised method for implementing authorisation patterns in smart contracts. It replaces the need for bespoke authorisation patterns in various types of contracts and provides a generic method usable by all such contracts. The standard is implemented as a metadata provider and includes a mandatory function called canCall, which takes in the necessary parameters for authorisation. The standard is inspired by ds-auth and OAuth and uses EIP 926 for the authorisation flow.

Video
Anyone may contribute to propose contents.
Go propose
Original

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 and by OAuth.

Specification

The generalised authorisation interface is implemented as a metadata provider, as specified in EIP 926. 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 926, 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); function revokeCaller(address owner, address caller, address callee, bytes4 func);

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.

Backwards Compatibility

There are no backwards compatibility concerns.

Implementation

Example implementation TBD.

Copyright and related rights waived via CC0.

Further reading
Anyone may contribute to propose contents.
Go propose
Adopted by projects
Anyone may contribute to propose contents.
Go propose

Not miss a beat of EIPs' update?

Subscribe EIPs Fun to receive the latest updates of EIPs Good for Buidlers to follow up.

View all
Serve EIP builders, scale Ethereum.
Resources
GitHub
Supported by