IDENTITY & CLAIM VERIFICATION

As more and more business and personal transactions move into the online world, users have to undergo an increasing amount of verification procedures. Whether it is signing up for financial service providers like an account with a bank or a trading exchange, public services with the employment bureau, or requesting to take out a loan: users have to verify their identity by producing personal documents like birth certificate, registration form, residence permit, work permit, proof of income, employment contract etc.

Currently, users lack control over what type of data they share, whom they share it with, when, and for what purpose this data may be utilized. Companies on the other hand often invest large sums to utilize this data, without being able to verify its authenticity and validity.

We were commissioned to create an environment where users themselves get back full control over their data, companies in turn can rely on the validity and authenticity of data, as data is verified by Trustcenters, PSD2 or comes from self-sovereign Blockchain solutions like Sovrin/Hyperledger Indy.

After several top-management workshops we narrowed down the core functionality that needs to be provided in order to allow SSI to become a governed standard:

• Connect Issuers
• Equip users with ID
• Develop standardized schemes

At its core our client's platform is a DLT network. Value can be transmitted from one party to another, without needing a central party to execute the transaction. Our client utilized the technology to give users the means for trading and monetizing their very own data and to decide who to share it with. Moreover the blockchain is used to establish DIDs and thus to issue verifiable credentials, which in turn are not stored on the blockchain themselves. Our client itself provides the basic blockchain infrastructure, data store and identity and validation resource management. Third party companies can apply with our client for becoming a channel provider, which means being eligible for building a custom application on top of our client's platform. This channel then utilizes the services and infrastructure the platform offers and adds some custom, use case specific business logic on top.

The graph below depicts the high-level architecture of our client's platform whereas it also describes how channels plug into and extend the platform with their custom applications. The underlying infrastructure is implemented and maintained by out client as a platform that allows third parties to build new applications on top of it.

The main goal of self-sovereign identity solutions is to give back control over data to users and allow for increased privacy by sharing only necessary data exclusively with parties that have legitimate interested. At the same time, verification of identities is to be made easier to allow identity-related activities to be conducted securely and automated in an online environment. These technologies will be explained shortly in the following due to their novelty and significance for core functions of the platform.

Terms and Definitions:

• Decentralized Identifier (DID): A decentralized identifier as defined by the DID Data Model and Generic Syntax specification. An Identity Record is associated with exactly one DID. A DID is associated with exactly one DID Document
• DID Document: A DID descriptor object containing meta data as defined by the DID Data Model and Generic Syntax specification. A DDO is associated with exactly one DID.
• Verifiable Credential: A Credential that includes a Proof from the Issuer.
• Identity Claim: Any data claiming to have a legitimate statement on an identity owner.
• Identity Owner: An Entity who can be held legally accountable. An Identity Owner must be either an Individual or an Organization.
• Identity Issuer: An identity issuer is a party that issues VCs.

The underlying concept needed to realize a decentralized, self-sovereign identity management is described as a decentralized public-key infrastructure (DPKI) in contrast to a traditional public-key infrastructure (PKI). It is illustrated in the figure below as an implementation agnostic example architecture. While a public-key infrastructure generally requires a single root of trust (e.g. provided by certification authorities) a DPKI aims to provide the same level of trust with multiple independent authorities managing the DPKI. To achieve this it combines user issued identities with statements about these identities issued by a wide variety of institutions. The main components of such a systems are decentralized identifiers (DID), DID descriptor objects (DDO), verifiable credentials (VC), zero-knowledge proofs (ZKP) and lastly a distributed ledger. A DID is a uniform resource identifier which can be created by anyone and always needs to be registered together with a DDO. This is realized with a publicly readable distributed ledger, that ensures that every DID is connected to a single DDO and once registered can only be changed by the rightful private key holder. The DDO allows this by specifying the public key, practically transferring a certain DID in the property of the private key holder. Following this setup, publicly known and verified DIDs can exist on the ledger that give statements on other identity owners a certain degree of trust as they are signed. These statements or claims are utilized in a special format called VCs. They can be verified by new parties without them having to have any interaction with the issuer, as they can simply check the signature against a publicly known DID. VCs issued directly to identity owners and stored by specialized wallets or by extended private key management software and not on the ledger. Additionally, VCs can be enriched with ZKPs to allow identity owners to dismember VCs to allow the partial proof of information or to prove facts without revealing any of the original data (e.g. proof of full age without revealing a birthdate).

One project that implements all of these components is the Hyperledger Indy project. While Hyperledger Indy provides its own ledger instance maintained by Sovrin it is completely modular to be implemented with multiple other distributed ledger solutions. For this reason, the platform will build upon the great work conducted by the Hyperledger Indy project and allow the integration of data coming from the Sovrin network. Sovrin is an instantiated ledger of the Hyperledger Indy codebase and the main contributor to its open source project. It provides the basic infrastructure needed for the realization of a DPKI and already integrated 30+ partners that are able to issue identities and help to govern and maintain the network. Building on top of this, the platform will allow the creation of DIDs, VCs and other necessary components in combination with other validation mechanisms on its own permissioned ledger to close the gap of missing issuing institutions on the Sovrin network.

General Workflow

After having described the general architecture the general workflow is outlined from a user perspective including the technical processes unfolding in the background. In this workflow the user registers on the platform, shares information and finally receives compensation for the initial data sharing.

• Sign-up
  Our client is fully responsible for users initial identification which they do via their user interface. Because the platform is designed to work with a variety of identity claim sources it even allows multiple ways of registration, whereas the simplest of all is that the user signs up with our client as they would with any other common online service. The user is not required to share any PII, as long as he is able to prove the validity of his identity claims, for example with appropriate VCs issued through the Sovrin network. Other identity claim sources will automatically include PII, which will be stored securely. The future log-in process for the user will also be dependent on the registration method. The alternatives are traditional email, password and two-factor-authentication, social logins or VC login procedures.

• DID Registration
  Independent of the registration method every user will receive a unique DID, registered on our client's blockchain to establish a pseudonymous identity in the platform. This DID will provide the primary key for all data to connect it to a single identity owner. Additionally, it will be connected to a DDO that includes a public key, its corresponding private key saved in the online wallet, which will also save VCs. Users will have total control over their private keys and VCs to be able to move them to an offline wallet and prove identity claims through other means than our client's platform. Our client and other identity issuers on the platform will be able to utilize this DID for the issuance of new VCs without having to connect it to the identity directly. Data consumers will be able to verify VCs with the public key stored in the DDO.

• Verifiable Credentials Issuance
  After validating identity claims provided by the user, our client issues VCs to confirm the identity claims. The issued VCs will be stored in the user’s online wallet and be under his control.