The world of cryptocurrencies has a major issue with trust: it is simple to create and abandon identities, so neither party in a transaction can be trusted. As such, decentralised services for lending, custody, authority etc. are very difficult.

This article is an introduction to the idea of identities and claims, explains how information from a trusted third party allows two parties without mutual trust to be able to transact, and provides a basis for building a real-world claims system.

Entities, claims and identities

An entity is something about which information is required. The most common type of entity is a person, but entities can also be computer programs (including smart contracts), physical assets (a house, a work of art), logical assets (a cryptokitty, a share certificate, a product model), legal entities (corporations, trusts) etc.

Claims are statements that provide information about one or more entities. Some example claims involving Iris are:

• Iris’ date of birth is 1st January 1970
• Iris is a citizen of the United States of America
• John is married to Iris
• Iris likes the rock band “Kings of Leon”

Note that a claim by itself says nothing about the entity making the claim (known as the “claimant”), nor does it provide any guarantees as to the truthfulness of the claim.

A set of claims about an entity can, in aggregate, be considered their identity. For example, Iris’ identity might include claims about her name, date of birth, nationality, employment status, familial relationships, personal preferences, etc.:

Identities are cheap to create (any entity can create a claim about itself and so form an identity) but to be useful they need to consist of claims that can be trusted. Trust is, of course, a tricky issue and is addressed in more detail below.

Requesters

A requester is an entity that wants to obtain information about identities. There are many reasons why the information might be useful, from a passing interest (“I have a spare ticket to a Kings of Leon gig, I wonder if anyone I know would like to go?”) to a strict requirement (“I cannot let you purchase tokens if you are resident of the United States of America.”).

Obtaining information directly

A naive way to obtain information from an identity is to ask them directly. If Rob (a requester) wants to know the age of Iris (an identity) he can follow the simple process below:

1. Rob asks Iris for her age
2. Iris responds to Rob with a self-generated claim about her age

This process is shown graphically below:

This works if Rob trusts Iris or there are no consequences if Iris lies to Rob. But there are many situations where Iris cannot be trusted to reply truthfully with her own information, for example if Rob is selling Iris a ticket to a concert and the price she pays depends on her age.

How can Rob trust information provided about Iris when he does not trust Iris herself? One answer to this question can be found in the concept of “authorities”.

Authorities

Authorities are entities that make claims. Any entity can become an authority by making claims, and most entities will be their own authority for personal claims.

Authorities are important as they allow claims to be weighted in the eyes of those assessing them. Claims about Iris’ date of birth from Iris herself, Iris’ family, Iris’ employer and government agencies all have different weight depending on the situation in which the information is required. Multiple authorities might create claims about Iris’ date of birth: relatives, employers, social media sites, government departments etc. If the claim is used to give Iris admission to a bar then the bar owner might only accept claims made by government departments. If the claim is used to obtain a free cupcake at a restaurant for her birthday the restaurant owner might be happy with the claim coming from a well-known social media provider, a family member or even Iris herself.

Obtaining authoritative information

Rob now has a new way to obtain information: he can trust an authority, or more specifically a certificate from an authority (e.g. a government-issued ID card containing Iris’ date of birth). The process now becomes:

1. an authority (in this case the local government “Grace”) issues Iris with a certificate which asserts Iris’ date of birth
2. Rob asks Iris for her age
3. Iris presents Rob with the certificate

This, or a variation of it, is how most physical and electronic verification of personal information occurs today. There are, however, a number of problems with this approach. 

The first is information leakage. Certificates, for example government-issued identification cards, often have information about the holder’s residence, their signature, and more besides that is not needed by Rob but present nonetheless. Also, although Rob only needs to confirm Iris’ age he in fact receives her date of birth, which is again more information than he requested. This is all information that once Rob receives he can retain, reuse or sell.

The second problem is the chain of trust this process requires. Grace (or one of Grace’s representatives) might not be trustworthy, willing to issue Iris with certificates containing incorrect information. Or Iris herself might not be trustworthy. She could alter the certificate presented to provide incorrect information. Or she might carry around multiple certificates (obtained legally or not), each containing different information, and present the best one in any given situation.

The third problem is the requirement for Iris to physically or electronically hold the certificate. As the certificate has utility it also has value, making it a target for theft. And if the certificate is stolen or lost it deprives Iris of her ability to prove her age until a replacement is obtained.

The final problem is that Rob might not have the knowledge or ability to confirm that the certificate presented by Iris is genuine. It might be that the government which issued the certificate is one with which Rob is unfamiliar, resulting in Rob being unsure if the certificate can be considered authoritative enough for his purposes.

Authorities are not enough by themselves to solve these problems; to do so they need to become providers.

Providers

Providers are authorities willing to interact directly with requesters. They hold information about identities and serve it to requesters as claims.

Note that although claims and information can be the same thing it is common that claims are derived from information. For example, a provider might hold an identity’s date of birth. Some claims that can be provided, in decreasing order of specificity, are:

• the identity’s date of birth 
• the identity’s age
• if the identity is older or younger than a given age

The more specific the claim the less likely it can be reused for other purposes. Continuing with the above example, if a ticket seller offers concessions for those under 21 and receives a claim certifying this in one of the above forms they can reuse the information as follows:

1. if the claim contains the identity’s date of birth the ticket seller has full information about the identity’s age
2. if the claim contains the identity’s age the ticket seller has partial information about the identity’s age that can be reused in future (if the identity’s age is 18 at a given point in time it is known they will be 19 one year later, 20 one year after that, etc.)
3. if the claim contains an assertion that the identity is under 21 the ticket seller has minimal information about the identity’s age that can be reused in the future (all they can ascertain from the claim is that 21 years after it has been issued the identity will be over 21)

It is in the identity’s interest that provider-issued claims are as specific as possible to reduce potential information leakage and re-use, whilst meeting the requester’s needs.

Obtaining trusted information

With the introduction of providers requesters can now obtain information that they trust. In this scenario Iris is aware of a number of providers that know her age and Rob is aware of a number of providers that he trusts to respond truthfully to requests for information. Rob and Iris can between them select a third party that fits both criteria to ensure that Rob receives an answer he trusts.

The basic process is now as follows:

1. Rob asks Iris for a list of providers who know Iris’ age
2. Iris sends a list of matching providers to Rob
3. Rob asks one of the providers (in this example “Peter”) for Iris’ age
4. Peter responds to Rob with Iris’ age

This process is shown graphically below:

Iris no longer needs to carry certificates, and Rob no longer needs to trust Iris in order to trust the information about her age.

Remaining issues

Questions about the above process remain, foremost transaction costs (who pays for the services provided?), sovereignty (can Rob obtain information from Peter without Iris’ permission?) and ownership (what is to stop Rob from selling the information provided by Peter)? A future article will discuss these questions in more detail and provide complete mechanisms for an identity system.