ERC-5982: Role-based Access Control

An interface for role-based access control for smart contracts.

Metadata
Status: ReviewStandards Track: ERCCreated: 2022-11-15
Authors
Zainan Victor Zhou (@xinbenlv)
Requires
EIP-165, EIP-5750
Links
GitHub pageDiscussion on Ethereum Magicians

Abstract

This EIP defines an interface for role-based access control for smart contracts. Roles are defined as byte32. The interface specifies how to read, grant, create and destroy roles. It specifies the sense of role power in the format of its ability to call a given method identified by bytes4 method selector. It also specifies how metadata of roles are represented.

Motivation

There are many ways to establish access control for privileged actions. One common pattern is "role-based" access control, where one or more users are assigned to one or more "roles," which grant access to privileged actions. This pattern is more secure and flexible than ownership-based access control since it allows for many people to be granted permissions according to the principle of least privilege.

Specification

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.

Interfaces of reference is described as followed:







    

  1. Compliant contracts MUST implement IERC_ACL_CORE
    2. 

  2. It is RECOMMENDED for compliant contracts to implement the optional extension IERC_ACL_GENERAL.
    3. 

  3. Compliant contracts MAY implement the optional extension IERC_ACL_METADATA.
    4. 

  4. A role in a compliant smart contract is represented in the format of bytes32. It's RECOMMENDED the value of such role is computed as a
keccak256 hash of a string of the role name, in this format: bytes32 role = keccak256("<role_name>"). such as bytes32 role = keccak256("MINTER").
    5. 

  5. Compliant contracts SHOULD implement ERC-165 identifier.
    6. 



Rationale


    

  1. The names and parameters of methods in IERC_ACL_CORE are chosen to allow backward compatibility with OpenZeppelin's implementation.
    2. 

  2. The methods in IERC_ACL_GENERAL conform to ERC-5750 to allow extension.
    3. 

  3. The method of renounceRole was not adopted, consolidating with revokeRole to simplify interface.
    4. 



Backwards Compatibility


Needs discussion.


Security Considerations


Needs discussion.


Copyright


Copyright and related rights waived via CC0.