IDENTITY ACCESS MANAGEMENT

As most business transactions are already moved into the online world, users have to undergo an increasing amount of verification procedures, need to create accounts and passwords. Commonly, users within enterprises lack Identity and Access Management (IAM) solutions that allow them to use all internal services, such as Sharepoint, SAP, Wikis, ARIS, etc. with one single login.

In order to realise a production-ready solution, we started by jotting down the following project steps:

AS-IS-ANALYSIS:

• Definition of organisational units most critical to be involved in a PoC
• Structured interviews, system audits and documents collection
• Evaluation

TARGET SOLUTION:

• Identifying to-be requirements
• Requirements documentation
• Definition of required interfaces
• Implication approval by management

PROCESS MODULATIONS:

• Process workshops
• Designing the to-be processes
• Running alignment sessions with departments involved
• Sign-off

AS-IS-ANALYSIS:

• Definition of organisational units most critical to be involved in a PoC
• Structured interviews, system audits and documents collection
• Evaluation

TARGET SOLUTION:

• Identifying to-be requirements
• Requirements documentation
• Definition of required interfaces
• Implication approval by management

PROCESS MODULATIONS:

• Process workshops
• Designing the to-be processes
• Running alignment sessions with departments involved
• Sign-off

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. 

This is the general technical architecture as well as the channel architecture:

• 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 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.

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).

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.

• Data Storage
  At the same time, the provided data will be categorized into public and private data and stored accordingly in the different storage systems. Additionally, the data will be supplied with metadata like trust scores and more granular categorization information.