Identity Management with Hyperledger Indy

Introduction

Digital identity refers to the data about you which uniquely identifies who you are online. It is an extension to your physical identity documents like passport, driving license etc.

Existing Identity management models

First let us see which models are used currently for identity management and why there is need for different solution for solving this age old problem of proving identity on the internet.

Existing models:

1. Centralized Identity: In this model user registers with various services that he would like to avail and uses username/ passwords to access them. Eg: creating account with Google.
2. Third Party Identity Provider: In this model user creates a single account with identity provider & then uses it with other services to login. Eg: Social logins with Google, Facebook, LinkedIn etc.

Challenges:

• Usernames/ Passwords are difficult to track across different services.
• It becomes easy target for hackers as users use same usernames/passwords. So if one identifier is disclosed then other services will also be compromised.
• Users personal data can be divulged with phishing attacks. Website impersonating some other website can use this users personal data for monetary purposes.
• Unwanted correlation occurs since users use common identifiers like email ID across various services.
• These identifiers are controlled by central authority. Like email ids used are provided by central authority like Google which can be taken away by them.

Solution:

The one of the solution for these challenges is to use self sovereign identity(SSI). SSI makes user owner of the identifiers they use to access various services and puts credentials in his control so he can decide on what data can be shared.

Now let us see how Hyperledger Indy can provide identity management solution using SSI.

Identity management with Hyperledger Indy

Actors involved in Hyperledger Indy:

1. ISSUER: They are responsible for generating and issuing digital credentials.
2. HOLDER: They store and share credentials.
3. VERIFIER: They verify credentials received from holder.

Note: Credential owner can be all three i.e. Issuer, Holder and Verifier

Features of Hyperledger Indy:

• Verifiable credentials: These are digital proofs which contains credential attributes issued to identity owner which then can be cryptographically verified using public keys from ledger.
• Decentralized Identifiers(DID):DID’s are user generated unique identifiers which are associated with public key and resolvable through ledger.
• Zero knowledge proof (ZKP): Claim can be selectively disclosed using ZKP without actually disclosing credential attribute value. Eg: proving age to be above 18 years without actually giving out date of birth.

Verifiable Credential Workflow:

Inorder to understand this verifiable credential workflow let us take an example of Alice(Holder) who wants to apply for VISA and needs to share passport document with VISA office(Verifier) issued by Passport Office(Issuer).

So before any organization can issue or verify credentials there are some prerequisite steps for onboarding as described below:

Network setup:

• For network setup indy pool network must be setup with pool of nodes which handles ledger
• For any issuer, verifier or holder to connect to the network for sending write request (like schema, credential definition write request) it must have genesis file.

Entities setup:

• Issuer in this case passport office must publish its DID (Verinym) and public key (verkey) to immutable ledger so that verifiers in this case VISA office can verify credentials issued by issuer without actually contacting issuer.
• Issuer also needs to publish credential schema on ledger.
• Once schema is setup next step for issuer is to publish their credential definition.

Once these network and entities setup is done issuer, holder and verifier are ready to issue, hold, verify the credentials. Issuer-verifier workflow is described below.

Issuer-Verifier workflow:

Fig: Issuer- Verifier workflow

Issuer-Holder Interaction:

When passport office issues a credential following process takes place. Passport office(issuer) and Alice(holder) creates a connection using pairwise DID which is not committed on the ledger and this connection remains private between the issuer and holder.

1. Passport office creates credential offer and shares it with Alice once connection is setup between them using pairwise DID.
2. Alice then creates credential request containing received credential offer.
3. Once passport office receives this credential request from Alice it cryptographically signs credentials and sends to Alice.

Alice finally stores these credentials securely in her wallet.

Above 3 steps can be visualized with an university example where university sends out an email that its providing degree certificates which can be mapped to credential offer then student have to actually go to university website and apply through registration form which is credential request step and finally student receives degree certificate through post which is issuance step.

Verifier-Holder Interaction:

4. In this step holder also known as prover can send proof offer to the verifier.

5. VISA office(verifier) sends proof request requesting some claims from passport credential after creating another pairwise connection with Alice(holder).

6. Alice generates proof for requested claims

Verifier then verifies this proof with issuer public keys from the ledger.

In the above described issuer-verifier flow step1: issuer sending credential offer is optional but step2: holder sending credential request is mandatory. Similarly in verifier-holder interaction proof offer is optional.

Conclusion:

• With Hyperledger Indy identity management problems can be solved.
• DID prevents unwanted correlation because separate pairwise DID are used to establish secure private connection with each service.
• Since DIDs are created by users they are the owners of those identity and does not rely on any central authority for providing identifiers.
• Different identities can be used across various services and users can choose which claims to share.
• Removes dependency of verifier on issuer in verification process since credentials are verified through ledger.