Generalize access control mechanism

[tsuberim]

I've created a PoC for a more general access control mechanism for Arc, this file contains a PoC with a simple usage example.
The basic idea is that there are a set of "locks"/"topics" each with a set of "keys". A contract can protects one of it's methods with a lock (or more) such that anyone with the appropriate key can use it to access this method.
Each key can have an expiration time, # of uses. Accounts can also transfer some (or all) of their capabilities to other accounts if allowed. Initially the contract itself has a "master key" (infinite uses, no expiration), and then it can pass some partial capabilities to the desired accounts.

Features:

• Can define a number of uses & expiration date on keys and if to enable the key to be transfrred.
• Accounts can transfer partial (or full) abillites to other accounts (if allowed).
• We can use advanced lock ids to lock a method even on specific parameters, enforce ordering, or other properties (see example).
• Can define complex boolean predicates to protect methods.
• No performance loss over hand-crafted mechanisms.

Benefits:

• Declarative policy (no more sprinkling ifs all over the codebase)
• Easy control flow (ordering, timing, number of function calls) restrictions (e.g. only allowed to call B after calling A twice within 2 days).
• Allows accounts to call functions themselves instead of delegating through other contracts.
• Generalized logging mechanism: key usage events can be queried by clients to know whether a method was called and by which account, key revocations can be used to know when users no longer have access to a method.
• Easier security since we need to verify less code.

[dkent600]

@dev-matan-tsuberi Can you provide a list of use cases (like user stories), and one or more examples in code that demonstrate some of the use cases?

[tsuberim]

@dkent600 I've included a simple usage example in the linked file
Re: use cases, it's very general, it can be anything really:

• Our current permission system in Controller.
• We can imagine a DAO that has different types (roles) of agents. Different roles may have different capabilities.
• A helpful utility when developing any kind of contract that cares about enforcing the order, timing or number of calls to it's methods (that's basically any contract).
• We can have a marketplace of such permissions with people exchanging keys for various functions.

This system is really just a very general access control system for a contract's functions. The contract can be whatever and the logic can be very complex or very simple.

[leviadam]

Hi @dev-matan-tsuberi ,

Just had time to review this. I like it very much.
How about we try to integrate it in Arc?

Maybe @dev-matan-tsuberi and @ben-kaufman together?

[tsuberim]

@leviadam Thanks! Sure we can integrate it. Of course this is currently only a POC, so it's not perfect. And there's a little concern to think about (decide if it's tolerable or invent a solution).

@ben-kaufman What do you think?

[leviadam]

I know it is not perfect. This will require some research and work.
We have to consider gas costs. And also solve the problem you mentioned.

We should also have an EIP, and ask for comments.
But I think we should go down this road :)

[tsuberim]

@leviadam Why EIP?

[leviadam]

I think it is a useful concept, and also people building schemes should be aware of it. It is good to try to standardize it.

[ben-kaufman]

I like the implementation, looks really interesting and useful.
I agree with @leviadam an EIP for this can be good as it's very generalized and I think it can be very good to have that as a standard. I'll go deeper throw the code in the next few days and suggest changes where needed.

[tsuberim]

@leviadam Re: gas costs, I think gas costs are not any different from a hand-crafted solution since its not storing anything more or doing any more logic than absolutely required. i.e. if you want to restrict the no. of uses you'd have to at very least maintain a counter, if you want to restrict to a specific time you'd have to remember that time, etc..

Potential improvements:

• Have a magic number that allows client code to check if a contract is Protected.
• Somehow allowing accounts to specify which key they want to use if there are multiple options. Currently it works by taking the first key that fits the lock.
• Instead of each Protected contract maintaining his own locks & keys, have one global contract as-a-service that manages all locks & keys, allowing contracts to share locks and interact in more complex ways.
• Having the concept of a "Group" of accounts that can be assigned/revoked permissions all at once. This can be simply implemented by having a proxy contract that maintains a set of addresses belonging to the group, permissions are given to the proxy contract itself and members of the group can forward requests through it to the target contract.

[ben-kaufman]

Regarding the first comment, I think we should implement EIP165 which specifies how to do that.

I'm currently trying to solve the issue you mentioned, will update when I'm finished.