Generalised authorisations

[Arachnid]

This EIP proposes a standard for generalised authorisations using a pattern inspired by ds-auth and OAuth. This EIP depends on the generalised metadata registry.

[0xjac]

Similar to operators in #777, I would split

authoriseCaller(address owner, address caller, address callee, bytes4 func, bool authorised)

into

authorizeCaller(address owner, address caller, address callee, bytes4 func)
revokeCaller(address owner, address caller, address callee, bytes4 func)

Also note the change to z in authorizeCaller. (I also prefer British English but sadly US English has become the norm in our world)

[Arachnid]

@jacquesd Good idea; done.

Edit: Apart from the s/s/z/; I'm not giving up on british english.

[MicahZoltu]

A simpler auth contract would be one that doesn't have the owner parameter/concept. I suspect for a lot of use cases, this is what people want and it is a bit easier to understand. This is also a good generalized authorization interface, just trying to think of what would be the simplest "first interface" to go with the generalized metadata registry.

[Arachnid]

A simpler auth contract would be one that doesn't have the owner parameter/concept. I suspect for a lot of use cases, this is what people want and it is a bit easier to understand. This is also a good generalized authorization interface, just trying to think of what would be the simplest "first interface" to go with the generalized metadata registry.

This is the difference between two legged and three legged auth. With only two legged auth, we wouldn't be able to replace concepts such as token authorisations/operators.

[MicahZoltu]

Sure, I'm only saying that two legged auth is simpler, and very often what people want vs three legged auth. I think standard for both is valuable, and for the sake of a "first example for #926" there may be value in providing for the simpler of the two first. Alternatively, just spec out both. 😄

Note: This isn't a blocking concern, just figured simpler is better for the maiden voyage of #926.

[Arachnid]

@MicahZoltu I understand where you're coming from, but the primary use-cases of this require three-legged auth. Can you suggest some use-cases for two-legged auth that would still benefit from a registry?

[MicahZoltu]

Any contract that simply wants to have a set of callers valid callers. e.g., callerAllowedToCall modifier. While I'm not a huge fan of the pattern, Augur uses this mechanism to limit functions that can only be callable by other Augur contracts (since Augur is big enough that it is split into many contracts). Right now Augur has rolled its own system for this, but it could be replaced almost wholesale with a generalized 2-legged auth system.

Note: I fully acknowledge that 3-legged auth is more powerful and I was pretty happy with how it was implemented in CryptoKitties with their CTO, CFO, CEO limited functions.

Out of curiosity, what is the primary use case this is being designed for?

[Arachnid]

Any contract that simply wants to have a set of callers valid callers. e.g., callerAllowedToCall modifier.

The provider is owned by the caller, though - we can't really trust them to tell us what functions they're allowed to call.

Out of curiosity, what is the primary use case this is being designed for?

I've been pondering the need for an OAuth-like mechanism for a while, every time I see someone using the pattern in a token contract or elsewhere. I wrote this up now because 777 is in the process of being standardised, and I think it would be useful there; it'd also be useful in future versions of ENS registrars.

[jbaylina]

EIP-X-metadata-nickjohnson should be ERC820 (#820) The name of the interface I propose to be ERC927Delegator

And the implementation, just as you defined:

function canCall(address owner, address caller, address callee, bytes4 func) view returns(bool);

[alexvandesande]

If you want to do a generic authorization, wouldn't it be better instead of returning a boolean to return an address where to call to receive the boolean? It might sound a bit like too many steps but here's what I have in mind:

• Bob wants to build a token that doesn't require users to ever have ether or do any ethereum transaction other than signing. Therefore he needs to have a central operator that is authorized for all accounts by default, until the owner revokes that authorization

• Alice wants to allow an operator only to move at most $100 dollars per day, in any tokens, at the current market valuation, so it builds a contract that can check the price of ether and token

• Eve wants to authorize Charlie only to trade on weekdays, when she knows Charlie is actually working

It seems that these can be done by setting a custom authorization methods that can be returned true or false depending on a variable set of circumstances, and not ALL true or ALL false.

update even before posting while writing this I realized you can do 2 and 3 by putting that sort of code on the authorized contract. You can do 1 by making so that the token overrides the authorization pattern unless it has been explicitly set.

I guess I support the proposal

[Arachnid]

@alexvandesande See also #926 for an additional indirection step; this EIP could be implemented using that, using #820, or standalone using trusted-deployment.

[Arachnid]

This is a courtesy notice to let you know that the format for EIPs has been modified slightly. If you want your draft merged, you will need to make some small changes to how your EIP is formatted:

• Frontmatter is now contained between lines with only a triple dash ('---')
• Headers in the frontmatter are now lowercase.

If your PR is editing an existing EIP rather than creating a new one, this has already been done for you, and you need only rebase your PR.

In addition, a continuous build has been setup, which will check your PR against the rules for EIP formatting automatically once you update your PR. This build ensures all required headers are present, as well as performing a number of other checks.

Please rebase your PR against the latest master, and edit your PR to use the above format for frontmatter. For convenience, here's a sample header you can copy and adapt:

---
eip: <num>
title: <title>
author: <author>
type: [Standards Track|Informational|Meta]
category: [Core|Networking|Interface|ERC] (for type: Standards Track only)
status: Draft
created: <date>
---