A Probe into the Trusted Identity Model

It is difficult to establish a credit system in the cryptocurrency world: identity creation and destruction are so convenient that no one in the transaction is trustworthy. Therefore, decentralization attempts such as lending, custody, authorization, etc. are difficult to develop.

The purpose of this paper is to introduce the concept of identity and claim, to explain how to make a transaction between two parties without a trust base through a trusted third party, and to provide a basic framework for the implementation of the claims system in the real world.
Entity, assertion, and identity

• Analyst: There is a callback expectation on the BTC weekly
• US SEC rulemaking does not harm the encryption startup encryption technology but is beneficial
• Is Bitcoin "revived"?

An entity is something that needs information to describe it. People are the most common kind of entity, in addition to computer programs (including smart contracts), tangible assets (houses, art), logical assets (obsessed with cats, equity certificates, product prototypes), legal entities (companies, trusts) And so on are entities.

An assertion is a statement that provides information to one or more entities. For example, here are some assertions related to Iris:

Iris's birthday is January 1, 1970.

Iris is a US citizen

John and Iris are married.

Iris likes the rock band "Kings of Leon"

It is important to note here that the assertion does not provide information about the process by which the entity (in other words, the assertion initiator) issues an assertion, nor does it self-certify its authenticity.

A collection of assertions associated with an entity can be considered their identity. For example, Iris's identity may include her name, date of birth, nationality, employment status, family information, personal performance, and so on.

– Figure 1: Identity of Iris –
Forging identity is effortless (any entity can make assertions about itself and create identity), but only an identity made up of credible assertions is useful. There is no doubt that trust is a tricky issue, as we will discuss in more detail below.

Requester

An entity that wants to obtain identity information can be considered a requester. The appeal for the value of this information is quite different. It may be an invitation to interest ("I have more than one ticket for the Kings of Leon concert, which acquaintance wants to go together"), or it may be a strict restriction ("If you are American Citizen, I can't let you buy tokens").

The easiest way to get information is to ask questions directly. If Rob (as a requester) wants to know the age of Iris (an identity), he can follow the simple process:

Rob asks Iris about her age

Iris generates an assertion and replies to Rob

The following picture depicts this process:

– Figure 2: Get the assertion directly –
This simple process is no problem if Rob believes Iris or even if Iris lie without serious consequences. But in many cases, Rob shouldn't trust Iris's response to his own information. For example, if Rob is selling a concert ticket to Iris and the cost she is paying is related to her age, obviously shouldn't be Directly trust Iris's response.

So how does he trust Iris's information if Rob doesn't believe in Iris? In order to solve this problem, we have to introduce a concept: "authority."

The so-called "authority" is the entity that generates assertions. Any entity can become an authority by generating assertions, and most entities are authoritative about their own assertions.

Authority is essential in scenarios where the accuracy of assertions needs to be assessed. Taking the assertion of Iris's date of birth as an example, assertions from herself and her family, employers, and government agencies are given different weights depending on the scenario in which the information is used. More than one entity will generate assertions of Iris birthdays, such as relatives, employers, social networking sites, and government agencies. If the assertion is used to verify that Iris is eligible to enter the bar, the bar owner should take the assertion from the government department; and if the assertion is only used to receive a free birthday cake in the restaurant, the restaurant owner from social media, Iris family, or even It is enough for Iris to get an assertion.

At this point, Rob's information acquisition has a new choice: he can trust an authority, specifically an officially issued certificate (such as a government-issued ID card containing Iris birthday information). This process is expressed as follows:

Authority (the government in this case is named "Grace") issues a certificate containing the date of birth to Iris

Rob asks about the age of Iris

Iris responds with government-issued credentials

– Figure 3: Authoritative Iris related information verification process –
Most of the current reality-electronic identity verification procedures use the above processes or improvements based on this process. However, the problems there are far more than one and a half.

First and foremost is the problem of information leakage. For example, in the case of a government-issued ID card, information such as home address, signature, etc., which are included in the ID card, are indiscriminately exposed to Rob's line of sight. In addition, Rob only needs to confirm the age of Iris, but he gets the date of birth of Iris, and the credentials provide more information than the requester needs. After the above information is obtained by Rob, it may be illegally stored, reused or even sold.

Another major flaw in the traditional information verification process is the existence of a chain of trust. Also in the example above, Grace (or its agent) may be untrustworthy, and in some cases it may provide credentials with incorrect information. In addition, Iris is not credible. She can modify the voucher, provide false information, or hold multiple voucher containing different information (possibly obtained through illegal means), and then provide the one that is most beneficial to her according to the needs of the scene. Share.

The third flaw in the above verification process is that Iris needs to hold the certificate physically or electronically. The utility of the voucher brings the value of the voucher, which at the same time attracts the thief's attention. If the voucher is stolen or lost, Iris can't prove his age until he gets the new voucher.

The last drawback is that Rob may not be able to recognize that the credential file provided by Iris is true. For example, Rob is not familiar with the government that issued the credential, and is unable to determine whether the credential can be accepted in the current scenario.

Authority itself cannot solve the above problems, and their way out is to become a provider.

provider

An authority that is willing to interact directly with the requester can be considered a provider. They retain identity information and provide it as a assertion to the requester.

It's important to note that although in some cases the assertion is exactly the same as the information, the assertion is usually derived from the information. For example, a provider may maintain a date of birth for an identity, sorted in descending order of information directivity, and may derive the following assertions:

Date of birth of an identity

Age of an identity

Whether an identity is greater than a given age

The more specific the assertion, the harder it is to reuse it in other scenarios. Going back to the previous example, if the ticket seller is willing to offer a discount to young people under the age of 21 and receives one of the above assertions, he can do the following information reuse:

If the assertion includes the date of birth of the identity, the ticket seller gets all the information about the age of the identity.

If the assertion contains the age of the identity, the ticket seller only gets some age information that can be reused in the future (if the age of the ticket is 18 when the ticket is bought, then 19 years after one year, 20 years after two years, etc. ).

If the assertion only determines that the identity is under 21, the ticket seller has the least amount of reuse information (they can only determine that the identity is greater than 21 years after 21 years).

While satisfying the requirements of the requester, it is necessary to protect the interests of the identity affiliation, and the provider should generate as much assertive as possible to reduce potential information leakage and reuse. By introducing a provider, the requester can obtain trusted information. In the current ticketing scenario, there are some providers that maintain Iris age information, as well as some trusted providers that Rob trusts. Therefore, Rob and Iris can select a provider from the intersection of the two as a third party to ensure that Rob can receive a credible answer.

– Figure 4: Finding the right provider (in yellow) –
The basic process is described as follows:

Rob asks Iris about which providers know her age

Iris sends a list of providers who know their age to Rob

Rob asks the provider of one of the lists (in this case "Peter") about the age of Iris

Peter replies to Rob's age to Rob

The flow chart is expressed as follows:

– Figure 5: Get trusted information –
Iris no longer needs to carry credentials, and Rob can also obtain trusted information about Iris age without trusting Iris.

The revolution has not been successful

There are still some problems with the above process. The most important thing is who will provide the transaction fee (who pays for this service?), information sovereignty (Can Rob get her age information if Iris does not agree?), information ownership (Who is going to stop Rob from selling the information he got from Peter)? In the future, I will write on the above questions, discuss in detail, seek solutions, and propose a complete identity system.

Source: Ethereum fans

We will continue to update Blocking; if you have any questions or suggestions, please contact us!