Attestation Issuers Management List
ERC-1388, titled "Attestation Issuers Management List," proposes a smart contract interface for managing a list of attestation issuers. This is particularly useful in scenarios where attestations to a user's identifier or abilities are required. For example, a real estate agent might require users to provide an attestation that they are a resident of a particular country.
The ERC envisions a model where the effort to manage the list of qualified issuers is outsourced to a list. Anyone can publish a list of issuers, and only the most trusted and carefully maintained lists get popular use.
The 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.
The ERC introduces a ManagedListERC contract with a List struct that includes the name, description, capacity, issuerContracts, and expiry. It also introduces several functions, including addIssuer, removeIssuer, and getIssuerCorrespondingToAttestationKey.
The rationale behind this ERC is to provide a flexible and trustless way to manage attestations, reducing the need for smart contracts to explicitly trust an attestation issuer.
Video
Original
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 fulfill 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 to see an example implementation of this ERC
Related ERC's
#1387 #1386
Adopted by projects
Not miss a beat of EIPs' update?
Subscribe EIPs Fun to receive the latest updates of EIPs Good for Buidlers to follow up.
View all