主页EIPs
EIPsERC-927
ERC-927

Generalised authorisations

StagnantStandards Track: ERC
创建时间: 2018-03-12
关联 EIP: EIP-926
Nick Johnson <nick@ethereum.org>
原文链接编辑
1 分钟了解
欢迎补充好内容
去提交
相关视频
欢迎补充好内容
去提交
正文

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.

扩展阅读
欢迎补充好内容
去提交
相关项目
欢迎补充好内容
去提交

不想错过最新的 EIP 动态?

订阅 EIPs Fun 周刊以跟进相关更新,建⽴你与 EIP 之间的连接 ,更好地建设以太坊。

详情
支持以太坊贡献者,推动生态建设
资源
GitHub
支持社区