Exploring Hyperledger Indy through indy-dev Example

Overview

In the digital world, we cannot live without identity. The way to prove my identity (I am who I claim to be) is mainly implemented as simple username and password, and sometimes we use advanced mechanism like multi-factor authentication or biometrics. This does not change the reality that we have too many siloed identity, and situation is only getting worse. Federated identity service, in which some identity provider serves as a single point for accessing multiple services helps a lot from user perspective. However our access to multiple services becomes too centralized to one or two big companies. They hold my identity, and too many identities also make them a good target of attack.

Storyline

We first take a look on the storyline of this example.

  • Faber College: credential issuer
  • Acme Corp: credential verifier
  • Faber College and Acme Bank: credential issuers
  • Thrift Bank: credential verifier

Run The Example

Before we go into detail how the storyline is implemented, we will give some highlights on the files of this repository and how to run this example.

$ git clone https://github.com/sovrin-foundation/indy-dev.git
$ cd indy-dev
$ sudo make build
$ sudo make start
After make start we will be in a shell of indy-dev
Two docker containers are running after make start
$ cd python
$ python3 getting_started.py
After executing the python code, we see detail log of the story (truncated)
Last several lines when the python code is completely executed
Exit the shell

Implementation: Setup

The storyline above is something happening in real life. Let’s see how it is implemented in Hyperledger Indy.

Indy Nodes: Source of Trust

First, we need a source of trust, which holds the necessary information that helps to build trust in the whole network. Distributed Ledger Technology (blockchain) is a good source of trust, given that data stored is secured against tampering and with good traceability. Hyperledger Indy comes with a permissioned blockchain in order to provide the trust required for the whole system. The blockchain is Indy Plenum.

Steward

In this example the first actor is called the Steward. Steward can onboard new actors in the system and assigns role to them. All the organizations mentioned in the storyline are “created” by Steward with the role Trust Anchor before they can perform all activities.

Steward Creates All Actors

Once created, Steward is responsible of creating other actors (Government, Faber College, Acme Corp and Thrift Bank). Two steps are needed before an actor can perform the tasks in the storyline.

Steward creates the actors with Trust Anchor Role

Storyline Implementation

Step 1: Government creating schemas

Government creates schemas
Faber College and Acme Corp create credential definition based on schemas issued by Government
Relation between Schemas and Credential Definitions
  1. Faber College creates and sends a Credential Offer to Alice.
  2. Alice retrieves the “Faber Transcript Credential Definition” from the ledger, and creates a Credential Request and sends it to Faber College.
  3. Faber College creates the Credential for Alice. Inside the Credential it contains the values of items listed in the “Faber Transcript Credential Definition” (and Transcript Schema), plus the required proof that Alice can use later when requested by Acme.
  4. Alice now receives the Credential and stores it in her wallet.
Alice gets credential from Faber College
  1. Acme Corp creates a Proof Request, which lists the items and the condition required. In this case Acme requires proof of degree, status and ssn from Faber College, and the average is over 4.
  2. Alice receives this Proof Request, and creates a Proof based on the credential she obtains from Faber College. The Proof contains information such that the requirement of Acme’s Proof Request can be satisfied.
  3. Acme Corp receives the Proof from Alice. Inside the Proof, Acme Corp sees the information and condition required, and verifies that they are coming from Faber College.
  4. Acme Corp accepts this Proof.
Alice creates proof with the credential to Acme Corp
  1. Alice retrieves the “Acme Job-Certificate Credential Definition” from the ledger, and creates and sends a Credential Request to Acme Corp.
  2. Acme Corp creates the Credential for Alice. Inside the Credential it contains the values of items listed in the “Acme Job-Certificate Credential Definition” (and Job-Certificate Schema), plus the required proof that Alice can use later when requested by the bank.
  3. Alice now receives the Credential and stores it in her wallet. Now she has two credentials in the wallet.
Alice gets credential from Acme Corp
  1. Thrift Bank creates two Proof Requests, which list the items and condition required. In this case Thrift Bank requires proof of employment status as Permanent, salary is over 2,000 and experience of more than 1 year. Also as KYC process she is asked for name and SSN.
  2. Alice receives both Proof Requests, and creates Proofs based on the credentials she obtains from Faber College and Acme Corp. The Proof contains information such that the requirement of Thrift Bank Proof Requests can be satisfied.
  3. Thrift Bank receives the Proofs from Alice. Inside the Proofs, Thrift Bank sees the information and condition required, and verifies that they are coming from both Faber College and Acme Corp.
  4. Thrift Bank accepts this Proof.
Alice creates proof with the credentials to Thrift Bank

Some Observation

What is in the Ledger?

If we walk through the whole example, items recorded in the ledger are

  • Schemas, which defines the structure of items referred by both credential definitions and credentials
  • Credential Definition, which is built on top of a schema, plus the issuer’s information for proof creation

Personally Identifiable Information (PII) Not in the Ledger

Then where is the PII? Over the story, we see some PII for Alice, such as her name, employment status, salary, year of graduation, etc. However this information is never exposed in the ledger, and therefore not readily accessible by anyone. This information is communicated via peer connections, such as Alice-to-Faber, Alice-to-Acme, and Alice-to-Thrift. And these connection is secured, through authenticated encryption, and information shared between is only known to the two parties. Therefore no PII is disclosed to the public, while the information in public (in ledger) provides the strong trust on the proof.

Alice’s Identity

So how is Alice identified in this network? We first do not see a single party containing all Alice’s information. In fact Alice has different DID when she is communicating to other organizations.

Closing

SSI is a very interesting topic. I hope this article provides a first step to understand what SSI is through indy-dev a real life example. For those who are interested, you can go to the indy repository, or begin with some good videos from SSI Meetup.

Visit http://www.ledgertech.biz/kcarticles.html for all my works. Reach me on https://www.linkedin.com/in/ktam1/ or follow me @kctheservant in Twitter.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store