ACL improvements

[heueristik]

Situation

Currently, the ACL is intended to control access on the contract level. It is not intended to control user-level permissions.

https://github.com/aragon/zaragoza/blob/58710cc3677db5b04d2d65c53ca6bb6e147e10a7/packages/contracts/contracts/core/acl/ACL.sol#L34-L37

In this design concept, Components such as WhitelistVoting have to manage the user-level permissions themselves inside the Component contract. https://github.com/aragon/zaragoza/blob/58710cc3677db5b04d2d65c53ca6bb6e147e10a7/packages/contracts/contracts/votings/whitelist/WhitelistVoting.sol#L49

Remark: In WhitelistVoting, users can vote in either every voting or none at all. To allow for controlling access to single votings or have specific user groups, a more complicated permission management would be needed inside WhitelistVoting.

Problem Description

This design is problematic for several reasons: Permission-management for each component

• is dangerous because the responsibility of coding a secure permission management (the most critical component in a DAO) is shifted to less-experienced component developers
• leads to code duplication
• is wasteful in terms of gas (more state to manage, more function calls to control access)
• confusing and hard to manage (a DAO needs to keep track of the permissions in each component)
• is unintuitive from a developer perspective because one would intuitively think that permission management in a DAO is the job of the DAOs ACL

Requirements

We need to be able to manage access for different actors: contracts, users, or groups (of both)

• contract-specific
  • EXAMPLE: Contract A can call specific functions in contract B
• user-specific
  • EXAMPLE: Alice can call specific functions in contract B
• group-specific (both, contracts and users can belong to a group)
  • EXAMPLE: A member of Group ALPHA can execute specific functions in contract B

The access should be granular down to the level of specific objects managed by the smart contract via object identifiers.

• EXAMPLE: Assume a contract managing a range of objects mapping (uint256 => Object) objects. Alice in group ALPHA can execute function bar(uint256 _id, ...) auth(_id, ALPHA) on object with _id=1 but not _id=2.

Moreover, permissions dynamically depending on contract state would be nice to have.

• dynamic/limited permissions
  • EXAMPLE: Members in the executive committee group can withdraw from the DAO until a certain budget limit is reached.

A general requirement is that the developer-facing functions should be clear and self-explanatory in their usage and naming.

Possible Actions

1. Add the functionality to the core ACL by modifying mapping (bytes32 => address) internal authPermissions; and associated functions to be more generic.
2. Leave the ACL as is, but provide the user-level permission-management functionalities (user groups / roles, dynamic permissions) as a specialized DAO component using the ACLOracle
3. Leave everything as is.

[heueristik]

In a call, Sam, Giorgi, and me opted for 2.

[nivida]

Thanks, Michael for writing this down.

As discussed on the call do @novaknole and I recommend keeping the ACL with the current degree of complexity it already has. Further permission management possibilities can be handled with the existing ACLOracle interface we provide. To improve the UX in case someone wants to have eg further permission levels do we definitely have to provide related packages in the upcoming marketplace to provide a no-code solution. Also, we should provide some abstract implementations of ACLOracle contracts over the Aragon SDK to improve the DX of package creators and/or third parties creating their own fully custom DAO based on the Aragon tech stack. I'm optimistic that we with this approach and good guides/documentation can prevent the problems you listed above while not adding more complexity to the core or limiting his flexibility.

[nivida]

as addition: We probably should overthink the naming of ACL and ACLOracle. I think for many third party engineers is it not clear what exactly ACL is and even less clear what ACLOracle means and what flexibility those two do provide.