Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update EIP-6366: Move to Review #6770

Merged
merged 10 commits into from
Oct 24, 2023
8 changes: 4 additions & 4 deletions EIPS/eip-6366.md
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
---
eip: 6366
title: Permission Token
description: A new token that held the permission of an address in an ecosystem
description: A new token that holds the permission of an address in an ecosystem
chiro-hiro marked this conversation as resolved.
Show resolved Hide resolved
author: Chiro (@chiro-hiro), Victor Dusart (@vdusart)
discussions-to: https://ethereum-magicians.org/t/eip-6366-a-standard-for-permission-token/9105
status: Draft
Expand All @@ -13,13 +13,13 @@ requires: 6617

## Abstract

This EIP offers an alternative to Access Control Lists (ACLs) for granting authorization and enhancing security. An `uint256` is used to store permission of given address in a ecosystem. Each permission is represented by a single bit in `uint256` as described in [ERC-6617](./eip-6617.md). Bitwise operators and bitmasks are used to determine the access right which is much more efficient and flexible than `string` or `keccak256` comparison.
This EIP offers an alternative to Access Control Lists (ACLs) for granting authorization and enhancing security. An `uint256` is used to store permission of given address in a ecosystem. Each permission is represented by a single bit in a `uint256` as described in [ERC-6617](./eip-6617.md). Bitwise operators and bitmasks are used to determine the access right which is much more efficient and flexible than `string` or `keccak256` comparison.
chiro-hiro marked this conversation as resolved.
Show resolved Hide resolved

## Motivation

Special roles like `Owner`, `Operator`, `Manager`, `Validator` are common for many smart contracts because permissioned addresses are used to administer and manage them. It is difficult to audit and maintain these system since these permissions are not managed in a single smart contract.

Since permission and role are reflected by the permission token balance of the relevant account in the given ecosystem, cross-interactivity between many ecosystems will be made simpler.
Since permissions and roles are reflected by the permission token balance of the relevant account in the given ecosystem, cross-interactivity between many ecosystems will be made simpler.

## Specification

Expand Down Expand Up @@ -65,7 +65,7 @@ interface IEIP6366Core {
* Allows `_delegatee` to act for the permission owner's behalf, up to the `_permission`.
* If this function is called again it overwrites the current granted with `_permission`.
* `approve()` method SHOULD `revert` if granting `_permission` permission is not
* a subset of all available permission of permission owner.
* a subset of all available permissions of permission owner.
* @param _delegatee Delegatee
* @param _permission Subset permission of permission owner
*/
Expand Down