add eip 1386, 1387 & 1388

EIPS/eip-1386.md

@@ -0,0 +1,88 @@
+---
+eip: 1386
+title: Attestation management contract
+author: Weiwu Zhang <[email protected]>, James Sangalli <[email protected]>
+discussions-to: https://github.com/ethereum/EIPs/issues/1386
+status: Draft
+type: Standards Track
+category: ERC
+created: 2018-09-08
+---
+
+### Introduction
+
+Very often, we will need to use Attestations like "Alice lives in Australia" on the blockchain; that is issued by a valid issuer off chain for privacy reasons and is revokable inside a smart contract.
+
+An issuer can create a smart contract where he revokes multiple attestations in one go by building a bloom filter of all the hashes of the revoked attestations.
+
+An issuer can also put the validation method in their smart contract that can be called by other smart contracts who need to validate attestations issued by them. This allows each attestor to update their attestation format separately.
+
+### Purpose
+
+This ERC provides an interface for attestation issuers to manage their attestation signing keys and the attestations that are issued off chain for actions such as revocation and validation.
+
+In our draft implementation we include functions to hold cryptographic attestations, change the issuing contracts of attestations, revoke attestations and verify the authenticity of a cryptographic attestation.
+
+### Example use cases
+
+Let's say that our friend, Alice, wants to buy a bottle of wine to consume with her friends. She wants to do the order online and have it delivered to her home address whilst paying for it with Ether.
+
+Alice has a cryptographic attestation from her local road and maritime services who attests to her age, date of birth, country of residence and ability to drive.
+
+Alice is able to split up this attestation (see merkle tree attestations ERC [here](https://github.com/alpha-wallet/blockchain-attestation/blob/master/ethereum/lib/MerkleTreeAttestation.sol)) and provides only the leaf that states she is over the age of 21.
+
+Alice goes to buy the wine through the wine vendors smart contract and feeds in the merkle tree attestation proving that she is above 21 and can thus buy the wine, whilst attaching the appropriate amount of ether to complete the purchase.
+
+The issuer smart contract is able to validate her attestation, check that the issuer contract is valid and capable of performing such an attestation to her age. In this case it would have to be from someone like a driver's licence authority, as attestations to age from a school ID are not of a high enough capacity.
+
+The wine vendors smart contract validates the attestation, checks the payment amount is correct and credits Alice with the wine tokens she needs to complete the sale and deliver the wine.
+
+When the wine vendor shows up to her apartment with the wine, there is no need to prove her age again.
+
+### Draft interface
+```
+/* each attestation issuer should provide their own verify() for the
+ * attestations they issued. There are two reasons for this. First, we
+ * need to leave room for new attestation methods other than the
+ * Merkle Tree format we are recommending. Second, the validity of the
+ * attestation may depend on the context that only the attestor
+ * knows. For example, a ticket as an attestation issued on a
+ * successful redemption of an American Express credit */
+
+contract Issuer {
+  struct Attestation
+    {
+        bytes32[] merklePath;
+        bool valid;
+        uint8 v;
+        bytes32 r;
+        bytes32 s;
+        address attestor;
+        address recipient;
+        bytes32 salt;
+        bytes32 key;
+        bytes32 val;
+    }`
+  /* Verify the authenticity of an attestation */
+  function verify(Attestation attestation);
+  function addattestorKey(address newAttestor, string capacity, uint expiry);
+
+  /* this should call the revoke first */
+  function replaceKey(address attestorToReplace, string capacity, uint expiry, address newAttestor);
+
+  /* this revokes a single key */
+  function removeKey(address attestor);
+
+  /* if the key exists with such capacity and isn't revoked or expired */
+  function validateKey(address attestor, string capacity) returns (bool);
+
+  /* revoke an attestation by replace the bloom filter, this helps preserve privacy */
+  function revokeAttestations(Bloomfilter b);
+
+}
+```
+
+Please click [here](https://github.com/alpha-wallet/blockchain-attestation/blob/master/ethereum/example-james-squire/james-squire.sol) to see a draft implementation of this interface
+
+### Related ERC's
+#1388 #1387

EIPS/eip-1387.md

@@ -0,0 +1,49 @@
+---
+eip: 1387
+title: Merkle Tree Attestations with Privacy enabled
+author: Weiwu Zhang <[email protected]>, James Sangalli <[email protected]>
+discussions-to: https://github.com/ethereum/EIPs/issues/1387
+status: Draft
+type: Standards Track
+category: ERC
+created: 2018-09-08
+---
+
+### Introduction
+
+It's often needed that an Ethereum smart contract must verify a claim (I live in Australia) attested by a valid attester.
+
+For example, an ICO contract might require that the participant, Alice, lives in Australia before she participates. Alice's claim of residency could come from a local Justice of the Peace who could attest that "Alice is a resident of Australia in NSW".
+
+Unlike previous attempts, we assume that the attestation is signed and issued off the blockchain in a Merkle Tree format. Only a part of the Merkle tree is revealed by Alice at each use. Therefore we avoid the privacy problem often associated with issuing attestations on chain. We also assume that Alice has multiple signed Merkle Trees for the same factual claim to avoid her transactions being linkable.
+
+## Purpose
+This ERC provides an interface and reference implementation for smart contracts that need users to provide an attestation and validate it.
+
+### Draft implementation
+```
+contract MerkleTreeAttestationInterface {
+    struct Attestation
+    {
+        bytes32[] merklePath;
+        bool valid;
+        uint8 v;
+        bytes32 r;
+        bytes32 s;
+        address attester;
+        address recipient;
+        bytes32 salt;
+        bytes32 key;
+        bytes32 val;
+    }
+
+    function validate(Attestation attestation) public returns(bool);
+}
+
+```
+### Relevant implementation examples
+[Here](https://github.com/alpha-wallet/blockchain-attestation/blob/master/ethereum/lib/MerkleTreeAttestation.sol) is an example implementation of the MerkleTreeAttestationInterface
+[Here](https://github.com/alpha-wallet/blockchain-attestation/blob/master/ethereum/example-james-squire/james-squire.sol) is an example service which would use such a merkle tree attestation
+
+### Related ERC's
+#1388 #1386

EIPS/eip-1388.md

@@ -0,0 +1,87 @@
+---
+eip: 1388
+title: Attestation Issuers Management List
+author: Weiwu Zhang <[email protected]>, James Sangalli <[email protected]>
+discussions-to: https://github.com/ethereum/EIPs/issues/1388
+status: Draft
+type: Standards Track
+category: ERC
+created: 2018-09-08
+---
+
+### Introduction
+
+In smart contracts, we will need methods to handle cryptographic attestations to a users identifier or abilities. Let's say we have a real estate agent, KiwiRealtors, that provides an "expression of interest" function though a smart contract and requires the users to provide an attestation that they are a resident of New Zealand or Australia, as a legal requirement. This has actually happened in the New Zealand property market and it is the perfect example of a need to handle such attestations.
+
+However, it is not practical for a smart contract to explicitly trust an attestation issuer. There are multiple issuers who can provide an attestation to a person's residency - a local Justice of the Peace, the land title office, local police, passport authority etc. We envision a model where the effort to manage the list of qualified issuers is practically outsourced to a list.
+
+Anyone can publish a list of issuers. Only the most trusted and carefully maintained lists gets popular use.
+
+### Purpose
+This ERC provides a smart contract interface for anyone to manage a list of attestation issuers. A smart contract would explicitly trust a list, and therefore all attestations issued by the issuers on the list.
+
+### Draft implementation
+  ```
+    /* The purpose of this contract is to manage the list of attestation
+     * issuer contracts and their capacity to fulfil requirements
+     */
+ contract ManagedListERC
+    {
+      /* a manager is the steward of a list. Only he/she/it can change the
+       * list by removing/adding attestation issuers to the list.
+
+       * An issuer in the list is represented by their contract
+       * addresses, not by the attestation signing keys managed by such a
+       * contract.
+       */
+      struct List
+      {
+	      string name;
+	      string description; // short description of what the list entails
+	      string capacity; // serves as a filter for the attestation signing keys
+	  /* if a smart contract specifies a list, only attestation issued
+	   * by issuers on that list is accepted. Furthermore, if that
+	   * list has a non-empty capacity, only attestations signed by a
+	   * signing key with that capacity is accepted. */
+
+	    address[] issuerContracts; // all these addresses are contracts, no signing capacity
+	    uint expiry;
+      }
+
+      // find which list the sender is managing, then add an issuer to it
+      function addIssuer(address issuerContractAddress) public;
+
+      //return false if the list identified by the sender doesn't have this issuer in the list
+      function removeIssuer(address issuerContractAddress, List listToRemoveIssuerFrom) public returns(bool);
+
+      /* called by services, e.g. Kiwi Properties or James Squire */
+      /* loop through all issuer's contract and execute validateKey() on
+       * every one of them in the hope of getting a hit, return the
+       * contract address of the first hit. Note that there is an attack
+       * method for one issuer to claim to own the key of another which
+       * is mitigated by later design. */
+       //loop through the issuers array, calling validate on the signingKeyOfAttestation
+      function getIssuerCorrespondingToAttestationKey(bytes32 list_id, address signingKeyOfAttestation) public returns (address);
+
+       /* for simplicity we use sender's address as the list ID,
+	 * accepting these consequences: a) if one user wish to maintain
+	 * several lists with different capacity, he or she must use a
+	 * different sender address for each. b) if the user replaced the
+	 * sender's key, either because he or she suspects the key is
+	 * compromised or that it is lost and reset through special means,
+	 * then the list is still identified by the first sender's
+	 * address.
+      */
+
+      function createList(List list) public;
+
+      /* replace list manager's key with the new key */
+      function replaceListIndex(List list, address manager) public returns(bool);
+
+    }
+```
+
+Click [here](https://github.com/alpha-wallet/blockchain-attestation/blob/master/ethereum/trustlist/ManagedList.sol) to see an example implementation of this ERC
+
+### Related ERC's
+#1387 #1386