-
Notifications
You must be signed in to change notification settings - Fork 5.8k
Description
EIP: <to be assigned>
Title: ERC: Ethereum Claims Registry
Author: Joel Torstensson <oed@consensys.net>
Type: Standard
Category: ERC
Status: Discussion
Created: 2017-11-29
Abstract
This text describes a proposal for an Ethereum Claims Registry (ECR) which allows persons, smart contracts, and machines to issue claims about each other, as well as self issued claims. The registry provides a flexible approach for claims that makes no distinction between different types of Ethereum accounts. The goal of the registry is to provide a central point of reference for on-chain claims on Ethereum.
Motivation
On-chain claims is becoming increasingly relevant as lots of different smart contracts might want to verify certain attributes about its users. However that is only one out of a very large space of use cases for on-chain claims. By providing a central repository for claims, developers are equipped with a common ground for experimentation. A standardized registry also makes claim lookup simple and gas efficient. Third party contracts only need to make one external call, no need for adding logic for verifying signatures, lookup identity signing keys, etc.
Specification
The ECR is a contract that is deployed once and can then be commonly used by everyone. Therefore it's important that the code of the registry has been reviewed by lots of people with different use cases in mind. The ECR provides an interface for adding, getting, and removing claims. Claims are issued from an issuer
to a subject
with a key
, which is of type bytes32
. The claims data is stored as type bytes32
.
Claim types
The key
parameter is used to indicate the type of claim that is being made. There are three ways that are encuraged for use in the ECR:
- Standardised claim types use syntax borrowed from HTTP and do not start with
X-
. The key is the hash of the claim type (eg,keccak256('Owner-Address')
) - Private types not intended for interchange use the same syntax, but with X- prefix. The key is the hash of the claim type (eg,
keccak256('X-My-Thing')
) - Ad-hoc types use 32 random bytes for the key, enabling allocation of new globally used keys without the need for standardisation first.
Standard claim types
New claim types can be added by making a PR to modify this table.
Claim type | Description |
---|---|
ERC780Example |
This is an example |
Registry specification
The ECR provides the following functions:
setClaim
Used by an issuer
to set the claim value
with the key
about the subject
.
function setClaim(address subject, bytes32 key, bytes32 value) public;
setSelfClaim
Convenience function for an issuer
to set a claim about themself.
function setSelfClaim(bytes32 key, bytes32 value) public;
getClaim
Used by anyone to get a specific claim.
function getClaim(address issuer, address subject, bytes32 key) public constant returns(bytes32);
removeClaim
Used by an issuer
to remove a claim it has made.
function removeClaim(address issuer, address subject, bytes32 key) public;
Type conversions
The value
parameter was choosen to have the type bytes32
. This in order to make the registry entries as general as possible while maintaining a very simple code base. However it is likely that usecases where other types such as address
and uint
etc. will emerge. Support for this can be added in various ways. We suggest that a library is implemented that can covert between various solidity types. This means that the registry itself keeps its simplicity. Contracts that need specific types can use such a library to convert the bytes32
into their desired type and back.
Deployment
After some discussion on the design of the registry contract it will be deployed and its address should be written in this document. This should include the addresses for the ropsten, rinkeby, and kovan testnets as well.
Updates and governance
In the future there might be new features needed in the registry. In order for such an event to be as transparent as possible the new features should be proposed and approved in a new EIP that contains the new contract code as well as a way of migrating any old claims if deemed necessary.
Appendix: Registry implementation
contract EthereumClaimsRegistry {
mapping(address => mapping(address => mapping(bytes32 => bytes32))) public registry;
event ClaimSet(
address indexed issuer,
address indexed subject,
bytes32 indexed key,
bytes32 value,
uint updatedAt);
event ClaimRemoved(
address indexed issuer,
address indexed subject,
bytes32 indexed key,
uint removedAt);
// create or update clams
function setClaim(address subject, bytes32 key, bytes32 value) public {
registry[msg.sender][subject][key] = value;
emit ClaimSet(msg.sender, subject, key, value, now);
}
function setSelfClaim(bytes32 key, bytes32 value) public {
setClaim(msg.sender, key, value);
}
function getClaim(address issuer, address subject, bytes32 key) public view returns(bytes32) {
return registry[issuer][subject][key];
}
function removeClaim(address issuer, address subject, bytes32 key) public {
require(msg.sender == issuer);
delete registry[issuer][subject][key];
emit ClaimRemoved(msg.sender, subject, key, now);
}
}