ESC proposal (#8)

EIPS/.#eip-status-codes.md

@@ -0,0 +1 @@
+expede@Latte.local.30400

EIPS/EIP-X-authorisations-nickjohnson.md

@@ -0,0 +1,57 @@
+## Preamble
+
+    EIP: <to be assigned>
+    Title: Generalised authorisations
+    Author: Nick Johnson <nick@ethereum.org>
+    Type: Standard track
+    Category: ERC
+    Status: Draft
+    Created: 2018-03-12
+
+## Abstract
+This EIP specifies a generic authorisation mechanism, which can be used to implement a variety of authorisation patterns, replacing approvals in ERC20, operators in ERC777, and bespoke authorisation patterns in a variety of other types of contract.
+
+## Motivation
+Smart contracts commonly need to provide an interface that allows a third-party caller to perform actions on behalf of a user. The most common example of this is token authorisations/operators, but other similar situations exist throughout the ecosystem, including for instance authorising operations on ENS domains. Typically each standard reinvents this system for themselves, leading to a large number of incompatible implementations of the same basic pattern. Here, we propose a generic method usable by all such contracts.
+
+The pattern implemented here is inspired by [ds-auth](https://github.com/dapphub/ds-auth) and by OAuth.
+
+## Specification
+The generalised authorisation interface is implemented as a metadata provider, as specified in EIP-X-metadata-nickjohnson. The following mandatory function is implemented:
+
+```
+function canCall(address owner, address caller, address callee, bytes4 func) view returns(bool);
+```
+
+Where:
+ - `owner` is the owner of the resource. If approved the function call is treated as being made by this address.
+ - `caller` is the address making the present call.
+ - `callee` is the address of the contract being called.
+ - `func` is the 4-byte signature of the function being called.
+
+For example, suppose Alice authorises Bob to transfer tokens on her behalf. When Bob does so, Alice is the `owner`, Bob is the `caller`, the token contract is the `callee`, and the function signature for the transfer function is `func`.
+
+As this standard uses EIP-X-metadata-nickjohnson, the authorisation flow is as follows:
+
+ 1. The callee contract fetches the provider for the `owner` address from the metadata registry contract, which resides at a well-known address.
+ 2. The callee contract calls `canCall()` with the parameters described above. If the function returns false, the callee reverts execution.
+
+Commonly, providers will wish to supply a standardised interface for users to set and unset their own authorisations. They SHOULD implement the following interface:
+
+```
+function authoriseCaller(address owner, address caller, address callee, bytes4 func);
+function revokeCaller(address owner, address caller, address callee, bytes4 func);
+```
+
+Arguments have the same meaning as in `canCall`. Implementing contracts MUST ensure that `msg.sender` is authorised to call `authoriseCaller` or `revokeCaller` on behalf of `owner`; this MUST always be true if `owner == msg.sender`. Implementing contracts SHOULD use the standard specified here to determine if other callers may provide authorisations as well.
+
+Implementing contracts SHOULD treat a `func` of 0 as authorising calls to all functions on `callee`. If `authorised` is `false` and `func` is 0, contracts need only clear any blanket authorisation; individual authorisations may remain in effect.
+
+## Backwards Compatibility
+There are no backwards compatibility concerns.
+
+## Implementation
+Example implementation TBD.
+
+## Copyright
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

EIPS/EIP-X-metadata-nickjohnson.md

@@ -0,0 +1,73 @@
+## Preamble
+
+    EIP: <to be assigned>
+    Title: Address metadata registry
+    Author: Nick Johnson <nick@ethereum.org>
+    Type: Standard track
+    Category: ERC
+    Status: Draft
+    Created: 2018-03-12
+    Dependencies: https://github.com/ethereum/EIPs/blob/master/EIPS/eip-165.md
+
+## Abstract
+This EIP specifies a registry for address metadata, permitting both contracts and external accounts to supply metadata about themselves to onchain and offchain callers. This permits use-cases such as generalised authorisations, providing token acceptance settings, and claims registries.
+
+## Motivation
+An increasing set of use cases require storage of metadata associated with an address; see for instance EIP 777 and EIP 780, and the ENS reverse registry in EIP 181. Presently each use-case defines its own specialised registry. To prevent a proliferation of special-purpose registry contracts, we instead propose a single standardised registry using an extendable architecture that allows future standards to implement their own metadata standards.
+
+## Specification
+The metadata registry has the following interface:
+```
+interface AddressMetadataRegistry {
+  function provider(address target) view returns(address);
+  function setProvider(address _provider);
+}
+```
+
+`setProvider` specifies the metadata registry to be associated with the caller's address, while `provider` returns the address of the metadata registry for the supplied address.
+
+The metadata registry will be compiled with an agreed-upon version of Solidity and deployed using the trustless deployment mechanism to a fixed address that can be replicated across all chains.
+
+## Provider specification
+
+Providers may implement any subset of the metadata record types specified here. Where a record types specification requires a provider to provide multiple functions, the provider MUST implement either all or none of them. Providers MUST throw if called with an unsupported function ID.
+
+Providers have one mandatory function:
+
+```
+function supportsInterface(bytes4 interfaceID) constant returns (bool)
+```
+
+The `supportsInterface` function is documented in [EIP 165](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-165.md), and returns true if the provider implements the interface specified by the provided 4 byte identifier. An interface identifier consists of the XOR of the function signature hashes of the functions provided by that interface; in the degenerate case of single-function interfaces, it is simply equal to the signature hash of that function. If a provider returns `true` for `supportsInterface()`, it must implement the functions specified in that interface.
+
+`supportsInterface` must always return true for `0x01ffc9a7`, which is the interface ID of `supportsInterface` itself.
+
+The first argument to all provider functions MUST be the address being queried; this facilitates the creation of multi-user provider contracts.
+
+Currently standardised provider interfaces are specified in the table below.
+
+| Interface name | Interface hash | Specification |
+| --- | --- | --- |
+
+EIPs may define new interfaces to be added to this registry.
+
+## Rationale
+There are two obvious approaches for a generic metadata registry: the indirection approach employed here, or a generalised key/value store. While indirection incurs the cost of an additional contract call, and requires providers to change over time, it also provides for significantly enhanced flexibility over a key/value store; for that reason we selected this approach.
+
+## Backwards Compatibility
+There are no backwards compatibility concerns.
+
+## Implementation
+The canonical implementation of the metadata registry is as follows:
+```
+contract AddressMetadataRegistry {
+  mapping(address=>address) public provider;
+  
+  function setProvider(address _provider) {
+    provider[msg.sender] = _provider;
+  }
+}
+```
+
+## Copyright
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).