Popular Science | A Preliminary Study on the Trusted Identity Model
Editor's note: This article is from Ethereum enthusiasts (ethfans), translated & proofread by Anzi Clint & A Jian; the original text comes frommedium(picture from
(picture fromPhotonet）
This article is Jim McDonald's introduction to identity systems. In this article, he introduced different roles and different identity system solutions in the identity system from the shallower to the deeper, and moved towards a more ideal solution step by step. While this is still not the ultimate solution, it is at least a good start.
It is difficult to establish a credit system in the cryptocurrency world: identities are created and destroyed so easily that neither party in the transaction can be trusted. Therefore, attempts to decentralize operations such as lending, custody, and authorization are difficult to carry out.
secondary title
Entities, Assertions and Identity
An entity is something that needs information to describe it. People are the most common type of entity, in addition to computer programs (including smart contracts), tangible assets (houses, artwork), logical assets (cat fetishes, proof of stake, product prototypes), legal entities (companies, trusts) etc. are all entities.
An assertion is a statement that provides information about one or more entities. For example, here are some assertions related to Iris:
Iris' 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 an assertion does not provide information about the process by which the entity (in other words, the assertion originator) made the assertion, nor does it self-prove its authenticity.
image description
-Figure 1: Identity of Iris-
secondary title
Requester
An entity that wants to obtain identity information can be regarded as a requester. The appeals that give value to this information vary widely, ranging from solicitations of interest (“I have an extra ticket to the Kings of Leon concert, does anyone I know want to go with you”) to strict constraints (“If you are an American Citizen, I can't let you buy tokens").
The easiest way to get information is to ask questions directly. If Rob (as the requester) wants to know the age of Iris (an identity), he can follow this simple process:
Rob asks Iris her age
Iris generates an assertion and replies to Rob
image description
- Figure 2: Get Assertion Directly -
Such a simple process is fine in situations where Rob trusts Iris or there are no serious consequences if Iris lied. But in many cases, Rob should not trust Iris's reply about his own information. For example, if Rob is selling a concert ticket to Iris, and the price she needs to pay is related to her age, then obviously he should not Trust Iris' reply directly.
So how does Rob trust Iris' message when he doesn't trust Iris? In order to solve this problem, we have to introduce a concept: "authority".
The so-called "authority" is the entity that generates the assertion. Any entity can become an authority by generating assertions, and most entities are authorities on their own assertions.
Authority is crucial in scenarios where the accuracy of assertions needs to be assessed. Still using the example of Iris' date of birth assertions, assertions from herself and from her family, employers, and government agencies are weighted differently depending on the context in which the information is used. More than one entity will generate the assertion of Iris' birthday, such as relatives, employers, social networking sites, government departments, and so on. If the assertion is used to verify that Iris is eligible to enter the bar, then the bar owner should accept the assertion of the government department; and if the assertion is only used to receive a free birthday cake in the restaurant, the restaurateur can get it from social media, Iris' family, and even Getting the assertion from Iris herself is enough.
At this point, Rob has a new choice for information acquisition: he can trust an authority, to be precise, a certificate issued by an authority (such as an ID card issued by the government that contains Iris' birthday information). This process is expressed as follows:
The authority (in this case the government named "Grace") issues Iris a credential containing her date of birth
Rob asks Iris' age
image description
-Figure 3: Iris-related information verification process based on authority-
Most of the current reality-electronic identity information verification processes use the above-mentioned process or an improved solution based on this process. However, there are far more problems than just one and a half.
First and foremost is the issue of information leakage. Taking the government-issued ID card as an example, information other than the date of birth contained on the ID card, such as home address, signature, etc., is exposed to Rob without distinction. Also, Rob really only needs to confirm Iris' age, but instead he gets Iris' date of birth, the credential provides more information than the requester needs. After the above information is obtained by Rob, it may be illegally preserved, reused or even sold.
Another major shortcoming of the traditional information verification process is that there must be a chain of trust. Still in the above example, Grace (or its agent) may not be trusted, and in some cases it may provide credentials with wrong information. In addition, Iris herself is not trustworthy. She can modify the credential, provide false information, or hold multiple credentials (possibly obtained through illegal means) containing different information at the same time, and then provide the one that is most beneficial to her according to the needs of the scenario. share.
A third flaw in the verification process described above is that Iris needs to hold the credential either physically or electronically. The utility of the credential brings the value of the credential, but at the same time attracts the attention of thieves. If the credential is stolen or lost, Iris will not be able to prove her age until she gets a new credential.
The last flaw is that Rob may not be able to identify the authenticity of the credential file provided by Iris. For example, Rob is not familiar with the government that issued the credential, so that he cannot be sure whether the credential can be accepted in the current scenario.
Authorities themselves cannot solve the above problems, their way out is to become providers.
provider
Authorities willing to interact directly with requesters can be thought of as providers. They hold identity information and serve it as assertions to requesters.
Note that assertions are often derived from information, although in some cases assertions are identical to information. For example, the provider may keep the date of birth of a certain identity, and according to the descending order of information directivity, the following assertions can be derived:
an identity's date of birth
a certain age
Whether an identity is older than a given age
The more specific an assertion is, the harder it is to reuse it in other contexts. Going back to the previous example, if the ticket seller is willing to give discounts to young people under the age of 21 and receives one of the above assertions, he can perform the following information reuse operations:
If the assertion includes the identity's date of birth, the ticket seller has all the information about the identity's age.
If the assertion includes the age of the identity, the ticket seller only captures part of the age information that can be reused in the future (if the age submitted at the time of ticket purchase is 18, then one year later it will be 19, two years later it will be 20, etc. ).
If the assertion only determines that the identity is under 21, the ticket seller has the least information to reuse (they can only determine that the identity is older than 21 years later).
While meeting the requester's needs, it is necessary to protect the interests of the identity owner, and the provider should generate assertions that are as directional as possible to reduce potential information leakage and reuse. By introducing providers, requesters can obtain credible information. In the current ticketing scenario, there are some providers who keep Iris' age information, and there are also 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 a suitable provider (indicated in yellow) -
The basic process is described as follows:
Rob asks Iris which providers know her age
Iris sends Rob a list of providers who know her age
Rob asks the provider of one of the lists ("Peter" in this case) for Iris' age
Peter replies to Rob with Iris' age
image description
-Figure 5: Obtaining trusted information-
question
question
There are still some problems in the above process, the most important ones are who will provide transaction fees (who pays for this service?), information sovereignty (can Rob obtain Iris’s age information without her consent?), information ownership (Who is going to stop Rob from selling the information he got from Peter)? In the future, I will write an article on the above problems, discuss them in detail, seek solutions, and propose a complete identity system.
