This paper proposes the concept of building a decentralized identification system that allows each participant to perform the role of both an identity object and an identity provider, regardless of their technical and legal capabilities. The main parameter of significance in the system is the level of trust toward the subject by the other participants of the platform and external IDs information consumers. This maintains the ability to fully manage the account and associated PII for their owner through the use of a cryptographic signature mechanism: changes to key data, PII and identifiers can be made at any time. The proposed system does not change the existing model of trust for large providers of identification services, but it allows to increase the objectivity of information about identifiers and PII of their owners by the possibility of verification of a separate identifier to each of the participants of the platform, followed by recording the results of verification in the chain of blocks. The use of blockchain technology and a consensus-reaching mechanism make it possible to synchronize the sequence of events in the system. The described global digital identity system positions itself as a source of information about global entities of specific subjects, and related personal data sets and established identifiers, while allowing the end-user of information to make independent conclusions about the level of trust of these identifiers based on related transactions. The system described is compatible with the digital asset management infrastructure and current identification tools. Thus, the system accomplishes a number of important tasks: reducing the threshold for using digital identifiers, allowing their ubiquitous use; the ability to verify the identifier and prove its compliance without the need to build a trusted infrastructure (only cryptography and other participants` votes); reducing the likelihood of certificate substitution attacks; increase the objectivity of information about the identifiers used.
Copyright © 2020 for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
Today, the usual point is the independent verification of user credentials by each system individually (or by an organization to which the system owner has entrusted user identification). Very often, these methods are not very different from each other: users transmit the same set of personal data, confirm registration using traditional methods (mail, phone, etc.), as a result of which they receive a “local” identifier that is valid only within the boundaries of the selected system.
The main disadvantage of this approach is that the user must go through the same identification and registration process again and again, even if an identical data set is provided. In addition to the resource costs of these processes, this entails that identifiers obtained in different systems are in no way interconnected: information about identifiers and PII confirmations is not synchronized between identity providers, which in some cases can lead to the use of different identifiers to manipulate user permissions. Moreover, at the same time, the data is not stored in a single unified format and is not signed by the user when they are transferred, which entails the difficulty of finding the custodian of certain data and the inability to confirm their integrity and authenticity.
Global services such as Google [
The global digital identification system involves binding all user`s PII and his public key (as an option - a set of keys) to a unique global identifier. Where it leads: • All information about confirmations of personal data is stored in a single system.
Using mechanisms of digital signature and linking transaction sets to each other will ensure the authenticity of specific PII confirmations with time-bound events; • The integrity and authenticity of the data binded to the account is checked exclusively by cryptographic methods (control root hash value); • The management of personal data is completely controlled by its owner, all other participants in the system can only confirm a user-defined data set. To obtain personal data about a particular participant in the system, an identity provider must contact him directly and obtain either the necessary data set or permission to receive this data from another identity provider. 2
A global identifier is a unique entity within the identification system that represents a specific subject and is associated with information identifying this subject. The identifier is bound to: the public key of the owner of the identifier, a set of hash values from the identifiers of other accounting systems, as well as a set of hash values from PII, which is tied to the account owner. All of the listed data is linked into one structure an account (see Fig. 1).
“Account (global) identifier” is an immutable and unique value within the identification system, represented as a byte string. This value is generated when the identity provider creates the new user`s account. The main requirement is the uniqueness of this value within the system (this can be either randomly generated or not randomly selected).
“Public key” is a public key value, with the private key of which all transactions initiated by a particular account are signed.
“Readable identifier list” is a set of hash values from identifiers in other systems, such as email address, facebook id, etc. Also, each hash value is associated with a specific set of confirmations from other network members that they checked that the account owner owns the specified email, facebook_id, etc., which correspond to the specified hash values.
“Merkle Root for main data” is the root value from the user's main set of personal
data [
“Main data confirmation list” consists of a set of records consisting of the identifier of the provider and information about the set of main data they have verified.
“Merkle Root for additional data” is the root value of an additional set of user personal data. It is assumed that the values that are included in this set will change, and correspond to confirmations more often than the main set.
“Additional data confirmation list” consists of a set of records consisting of the identity of the provider and information about the set of additional data they have verified.
“Recovery providers list and recovery power” determine the set of identity providers (and their amount) needed to restore access to the account and change the public key. 3
The global digital identification system provides that each participant (who has an
account) can send a transaction to the network. Transactions are stored as an ordered
set of blocks (see Fig. 2), each of which contains a cryptographic hash value of the
previous one [
A transaction, in turn, consists of a set of defined operations. There are four main types of operations: the operation of creating an account; the operation of changing / adding data associated with a specific global identifier; confirmation operations of data associated with the identifier; the operation of restoring access to the account (changing the public key and the set of parties for recovery).
The account creation operation can be initiated by any existing account. As a result of the operation, a new account is created in the identification system and its identifier and public key are determined (you can additionally define fields containing hash values of personal data and their confirmations).
Data change operations include operations whose purpose is to change / add main and additional personal data of the user, as well as change the values of identifiers associated with external systems. Such transactions can only be signed by the account owner and verified using the public key value specified in the account. In fact, each user personally determines the data set that he wants to associate with the global identifier; identity providers, in turn, have the right only to confirm the data set by the user.
Data verification operations include operations whose purpose is to confirm main and additional personal data. Such transactions can be sent by identity providers (in fact, by any member of the network) in relation to a particular account. Such a transaction contains information about the identifier of the account to which the confirmation is carried out, about the value of Merkle Root, to which the data verified by it belongs, as well as about the set of data itself that has been verified.
The operation to restore access to the account can only be signed by the owners of
the identifiers that were defined by the user at the time of creating or updating the
account. In fact, the user personally determines the set of trusted parties (and their
required number), which can confirm his identity and sign the transaction to update
the public key of the account. In fact, carrying out all types of operations described
constitutes the life cycle of the account (see Fig. 3).
In order to create an account in the global digital identity system, the user needs to
contact with identity provider. This can be either a separate independent entity, or tied
to a specific accounting system. The registration process may differ depending on the
individual provider (this can be either the personal presence of the user or remote
registration), but it is worth identifying its main features [
Also, the user needs to generate a key pair (private and public keys) and confirm ownership of the specified email address (or other identifier, depending on those specified in the account). The account creation process is shown in the following diagram (see Fig. 4). 1. The user sends the identity provider a set of personal data that must be confirmed, the Merkle Root value for the entire personal data set, Merkle Branch as evidence that the personal data set is included in the root hash value, public key, email address and the generated identifier value. The user also defines a list of accounts that can change the value of the public key and restore access to the account. 2. The identity provider checks the provided personal data and checks their relation to the root value. 3. The registrar sends a e-mail confirmation to the client (not necessary e-mail, another channel can be used). The confirmation contains Merkle Root (proof that the data received by the provider was not modified), the received public key (also that it was not modified), identifier, list of trusted providers and Nonce value. All values are signed by the provider's key; accordingly, an attack on message modification during transmission is excluded. 4. The user receives a mail, checks that all the data is valid, then signs the Nonce value with his own private key (as proof that he owns the public), and then sends the signed value to the provider. 5. The registrar verifies the signature, after which it initiates the creation of the account: it fills out the necessary fields, generates a global identifier and sends the corresponding transaction. 3.2
After the user account has been created, the user determines the set of personal data that will be associated with his account (if he did not define it during creation). He collects the data in the structure of the Merkle tree and puts the root value in the account. As we noted earlier, the account contains two Merkle Root values: for a set of basic data and additional. This approach will leave the master data confirmed, even if the additional ones are changed.
After the user has determined the personal data, he needs to receive confirmation of this data from identity providers. It is important to note that the user may not want the provider to gain access to the entire set of his personal data. This property can be provided by using Merkle trees. In this case, in the process of confirming personal data, the user must not transfer their entire set so that the provider checks their integrity and authenticity, but only the data necessary for verification and the Merkle Branch value to prove that they are in the root value (see Fig. 5).
When the identity provider receives the data set and Merkle Branch from the user, he checks that the received data matches the root hash value specified in the account, and then checks the received data. If the provider agrees with the data received, it forms a transaction, which indicates that it has confirmed a specific set of personal data that relates to a specific account identifier and a specific Merkle Root value.
If the user decides to update part of the data for a full set, in this case, the value of Merkle Root will completely change. As a result, a previously sent transaction that confirms the data for a particular Merkle Root becomes invalid. That is why the structure of the account implies dividing the data into main and additional: if the user has confirmed the basic data set (and does not change it), then regardless of whether the additional data has been updated, the basic data will remain confirmed. 3.3
An important feature of such a system is the independent decision-making regarding the identifier by the consumer of information. There is no information in the system that directly determines the validity of a particular identifier: there are only accounts and votes confirming the data of these accounts. Thus, the issue of trust is submitted entirely to the client side. In this case, he can personally determine the methodology, which will be described when calculating the level of trust.
One of the methods for determining trust is the number of identifier confirmations
by other network participants. However, it should be borne in mind that this method is
subject to a Sybil attack - one of the account can create a large number of other
accounts that confirm the identity of one of the participants in the system [
The second approach is to trust only a specific provider (several providers). For example, being a client of a bank, I trust its identification mechanisms and can set up my site in such a way as to trust only those accounts that have been verified by the said bank. Although this scheme is somewhat centralized (if the number of providers that the user trusts is small), it will be quite effective and expected, most used due to its simplicity.
In the third case, if the objectiveness of the result is really important for the network member, he can build complex verification algorithms that evaluate both the level of trust for providers who confirmed a specific account and providers who confirmed accounts with a specified provider (thus up to a large number of verification levels).
It is important to note that whichever way the consumer uses identification results, the system provides the ability to fully customize the verification algorithm, which lies solely on the client side. 4
In order to meet the GDPR policy, it is necessary that PII users are transferred and
processed only with the permission of their owners [
Since the provider that stores PII users cannot distribute this data without first obtaining permission to do so, this permission must be provided by the user. Such permission must contain the date and time of its formation, the identifier of the PII owner’s account, the set of data that is allowed to be transferred to the second party, as well as the identifier of the recipient side. Note that the request must be signed with a private key that is tied to the user's account.
If the registrar receives a similar request from the user, he checks the signature value of the request using the public key that is specified in the user’s account. If the signature is valid, then he looks at what set of personal data is requested, and if he really has the required set of personal data, then he sends them and the Merkle Branch value to the requesting party (they must first establish a secure channel). The requesting party carries out a procedure similar to that described in 3: it checks that the received data is in the root hash value, and then confirms the personal data.
The timestamp in the request is necessary to ensure the confidentiality of the updated PII. If the user has updated his personal data set and does not want the party that previously received permission to access the old set to be able to receive updated data for the same permission. Therefore, when checking permission, the registrar compares the time of sending the transaction with the updated data and the time for obtaining permission, and if the time for obtaining permission is shorter, then access to personal data of users is not provided. 5
Using a native currency for the network to motivate validators and using proof-ofwork / proof of stake mechanisms for reaching consensus is not the best solution, since the quality of identification information and the reliability of the system, as practice has shown, will completely depend on the “value of this currency” [12; 16]. Moreover, a completely anonymous environment is not the most suitable for the construction of an identification system, where the level of confidence of the identification will depend on the processing power or the size of the stack of registrars, which does not exactly indicate their competence in issues of user identification.
It is not worth changing the model of trust relations to specialized providers of identification services, but you only need to expand it by combining these providers into a single network, which will contain information about issued identifiers and their confirmations. At the same time, leading identity providers will act as public sources of information about confirmed data, which will in no way affect the change in attitudes towards them. In other words, trusting the identification of a particular organization, you also continue to trust it, however, it no longer acts as an identifier provider for a specific local field, but as an identifier provider in the global system, which automatically expands the user area of activity. Thus, having confirmed the identifier with several major suppliers, the user gets rid of additional identification in local systems that trust these providers.
The most suitable model for achieving consensus for this system is the FBA
algorithm [
The key issue at this stage is protection against spam attacks [
Existing public key infrastructures were the first step in digitizing interactions
between Internet users, which involved providing basic information services [
The implementation of the identification system functioning scheme described in
the document does not imply a mandatory abandonment of the existing X.509
infrastructure. Moreover, the simple integration of existing certificates is supposed by
adding them to the account structure. The key idea of such a system consists precisely in
transferring control of data into the hands of their owners and unifying access to
various services through the use of cryptographic methods [