DevTeam.Space Product Development Blog

Explore our in-depth product development tutorials and new technology announcements published by our software development experts

All articles

How To Build a Self Sovereign Identity Wallet?

When you signed up for a Facebook account, it was free. Or, was it, really? As you can read in “The Facebook and Cambridge Analytica scandal, explained with a simple diagram”, Cambridge Analytica harvested raw data of 87 million Facebook users using a loophole in the Facebook application programming interface (API).

That‘s a high price to pay! In today‘s world, centralized companies manage your digital identity, and you have no control over it. If this remains the established practice, such massive data breaches will continue to happen.

You need a self sovereign identity that you own, control and decide when and how much information you should share with another entity. In this guide, I will describe how to build a self sovereign identity wallet.

Contents

Limitations of today‘s centralized digital identity management:
What is Self “Sovereign Identity”?
Make a self sovereign identity wallet with Hyperledger Indy
Building a self sovereign identity wallet with Indy: project overview
Alice‘s interactions with Faber college for sovereign identity:
Setting up trust anchor credentials for Faber, Acme, Thrift, and the government:
Connect to the Indy nodes pool:
Get the ownership of Stewards‘ Verinym:
Steward onboards different entities:
Set up credential schema and credential definition:
Alice gets her transcript from the Faber college:
Job application using the transcript credential:
Cost of creating a blockchain self-sovereign identity wallet:

Limitations of today‘s centralized digital identity management:

The concept of identity has three components, as follows:

  1. Claims: A person or a business makes an assertion of an identity claim.
  2. Proofs: A document providing evidence for the claim.
  3. Attestation: A third-party validates that the claim is correct according to their record.

Read more about the concept of identity in “A gentle introduction to self-sovereign identity”.

However, managing these 3 components is increasingly harder in the current digital age. You face following issues with centralized digital identity management:

  1. You never really own your identity, and the websites and apps own them.
  2. This system isn‘t efficient, besides chances of fraud and invading your privacy are high.
  3. Identity is managed in siloes, and with billions accessing the Internet a fragmented approach can only lead to problems.
  4. Your usernames and passwords are scattered over possibly hundreds of websites and apps, along with your personal information!
  5. Hackers utilize weak passwords and data breaches to steal your identity information.
  6. Centralized companies managing your digital identity have a massive amount of user data and are prime targets of hackers. Their costs of protecting your data increase with every passing day.
  7. High-profile data breaches are common news now, and many online users worry about engaging in the online world. Over a longer-term, this will adversely impact

Read more about these issues in “Evernym – Private Sovrin Self-Sovereign Digital Identity Blockchain?”.

What is Self “Sovereign Identity”?

“Self Sovereign Identity” (SSI) is the answer to the above issues. SSI has the following characteristics:

  1. You own and control it fully.
  2. Another person or entity can read it only with your consent.
  3. No one can use it without your consent.
  4. It‘s mathematically proven, hence, trustless, no one can decline the claims you made using your SSI.
  5. SSI is permanent, no hacker can destroy it.
  6. It‘s portable, you carry it on you.

Read more about it in “Evernym – Private Sovrin Self-Sovereign Digital Identity Blockchain?”.

Make a self sovereign identity wallet with Hyperledger Indy

In this guide, I will describe the process to build an SSI wallet using Hyperledger Indy. Indy is one of the several Hyperledger consortium projects in various stages of development.

Hyperledger consortium is a group or major industry players like IBM, Cisco, American Express, etc. that works on developing enterprise blockchain. Read more about Indy in the Hyperledger Indy webpage.

Indy is a distributed ledger, designed specifically for decentralized identity. The project provides tools, libraries, and reusable components to create blockchain-based digital identities.

Evernym, a blockchain company working specifically on digital identity space, has created a blockchain-based platform named Sovrin. It’s a platform to create a decentralized digital identity. Evernym has donated their code to Indy.

Building a self sovereign identity wallet with Indy: project overview

I will explain the process using a sample project. In this case study, a fictitious college student graduates from a fictional college and applies for a job at a fictional company.

She then applies for a car loan in a bank. The student intends to use her college transcript as a proof of her education when she applied for the job. She would then use her employment details to prove herself creditworthy for the car loan.

As things stand today, she will find this process slow, complex, and invading her privacy. She will also notice how the process isn‘t secure. Read about the case study in “Getting Started with Libindy”. Throughout this guide I will refer to it multiple times for commands and code snippets, hence, let’s call it the “Reference case study”.

In the case study, the name of the student is Alice, the name of her college is Faber college, the company is Acme Corp, and the name of the bank is Thrift bank. We will refer to these names in this guide. Also, since I want to show the process of creating the SSI wallet, I will describe commands used in the SDK and not screens of the app.

Alice‘s interactions with Faber college for sovereign identity:

Alice gets to know that her college is offering digital transcripts, and interacts with the college as follows:

  1. She logs into the college website and requests a transcript by clicking “Get transcript”.
  2. Faber college uses Indy and has already built an SSI for her. I will describe this aspect in more details later.
  3. The college recommends an app to Alice for the SSI, and as part of “Get transcript” workflow, it will install automatically.
  4. While clicking “Get transcript”, Alice also downloads a file that has an Indy connection request. This allows Alice to connect to another party in the distributed ledger, which is Faber college in this case.
  5. When Alice launches the app, it will ask whether she will accept a connection request with Faber college.

Read more about these interaction steps in the reference case study.

Setting up trust anchor credentials for Faber, Acme, Thrift, and the government:

The case study uses ’Libindy‘, i.e. the software development kit (SDK) for Hyperledger Indy. You can read more about Libindy in “Indy SDK” GitHub material for Hyperledger Indy.

The Indy distributed ledger stores ’identity records‘, which contain the following:

  1. Public keys;
  2. Service endpoints;
  3. Credential schemas;
  4. Credential definitions.

Each identity records are linked to one unique ’decentralized identifier‘ (DID), which the distributed ledger resolves it without any centralized authority. An identity owner can own multiple DIDs.

The case study uses two types of DIDs, also called NYMs, as follows:

  1. Verinym: It‘s the legal identity of the ID owner.
  2. Pseudonym: a blinded ID to maintain privacy.

The Indy ledger is public permissioned, and if you want to publish DIDs, you need to become a ’Trust Anchor‘ on it. This signifies a facilitator role where the ledger already knows about a trust anchor.

In our example, ’steward‘ roles were already set up, and the different entities need to contact the steward.

Connect to the Indy nodes pool:

The next step in self sovereign identity wallet development is to connect to the Indy nodes pool. After you have received the proper role, you need to connect to the nodes pool to read the ledger or write to it.

You first need to set up a pool configuration, using ’genesis transactions‘. Pool configurations have a pair of pool configuration name and JSON. The JSON file has the path to the file with the list of genesis transactions, you need to get this path correct.

You can use ’create pool‘ and ’open pool‘ commands to create a named pool configuration and connect to it. Check the commands in the reference case study.

Get the ownership of Stewards‘ Verinym:

To enable you to learn easily, in this example project, the ledger already stores some steward Verinyms. You also have the seed values to generate keys for these NYMs. Using these you can restore signing values for those DIDs, and get the DID ownership.

Libindy enables you to create wallets where you can store DIDs, keys etc. You need to create a named wallet by using the ’create wallet’ command and open it with the ’open wallet‘ command.

You can now create DID and store it in the wallet by issuing ’create and store my DID‘ command. Refer to the reference case study for commands.

Steward onboards different entities:

The next step in creating a blockchain based self-sovereign identity wallet is the onboarding of entities. Faber, Acme, Thrift, and Government need to now establish their individual connections with the steward.

Each connection is a pair of DIDs that only the two parties in the connection know, but no one else. ’Onboarding‘ is this process of setting up connections.

The entities need to do the following:

  1. Establish a contact outside the ledger, for e.g. over the phone, or fill up a form on the website;
  2. The steward creates a new DID and stores in the wallet for one entity;
  3. Steward sends the transactions to the ledger;
  4. Steward creates the connection request;
  5. The connection request is sent to the entity, for e.g. Faber, and Faber accepts it;
  6. Faber now creates a new DID record in their wallet, for using it with the steward only;
  7. Faber then creates the connection response;
  8. They then ask the ledger for verification of stewards‘ DID;
  9. Faber anonymously encrypts the connection response with the Stewards‘ key;
  10. They then send it to the steward, who decrypts it;
  11. Steward authenticates Faber by comparing the hash;
  12. Now, steward sends the NYM transaction for Faber‘s DID to the ledger.

Faber is now connected to the steward. Other entities need to follow the same process. Read more about the code in the reference case study.

Set up credential schema and credential definition:

This is a base schematic structure that specifies the list of attributes that a credential can have. You can’t update an existing schema if the attributes change then you need to create a new schema.

Any trust anchor can create and save a credential schema in the ledger. They do it by issuing the ’create schema‘ command.

When issuers sign credentials, they use keys defined in the credential definition and must satisfy a credential schema. Like schema, you can‘t alter a credential definition either. If the keys need to change then you need to create a credential definition.

Any trust anchor can create a credential definition. Consult the reference case study for details of commands you need to use, for creating credential schemas and credential definitions.

In our example, Fabre needs to create transcript credential schema and publishes a credential definition for it. Also, Acme needs to create a job certificate credential schema.

Alice gets her transcript from the Faber college:

A college transcript is a credential and has some information about the identity of the student. In our example project, Alice needs to get this credential, and the Faber college needs to issue it to her.

Faber college establishes a connection with Alice and has a credential offer for her, to issue her the transcript. As you can understand, Faber college is a credible issuer for this credential, and Alice needs it to prove claims about her education. They will need to communicate, and their messages in Indy are encrypted using an authenticated-encryption scheme.

Since the credential conforms to a credential schema, Alice can see the generic attributes of the credential in the distributed ledger.

However, she needs to create a master secret to receive her own transcript. A master secret combines data from multiple credentials and is unique to an entity. Alice creates a master secret and stores it in her wallet, using the commands specified in the reference case study.

However, Alice is requesting a credential that has a specific credential definition, and she needs that too, to request for her transcript. She combines this and her master secret and makes a request for her transcript.

Faber college creates both raw and encoded values for each attribute for Alice‘s transcript, and then sends the transcript to Alice. Alice received it and stores in her wallet. You can see the commands in the reference case study.

Job application using the transcript credential:

In the next phase of our project to explore self sovereign identity using blockchain, Alice is applying for a job with the Acme Corp. She visits their website and clicks the job application link, and as a result, an Indy connection request is downloaded into the browser. Alice establishes a connection, using the same process I have described above.

Alice will now have to respond to Acme for the job application proof request. In this example, the request has some verifiable attributes such as degree and graduation status. It also has some that need no verification such as first name and phone number.

Alice segregates the request into three categories of attributes:

  1. Attributes for which she will reveal the values;
  2. Attributes for which she won‘t reveal the values;
  3. Attributes requiring no verification.

She has her transcript credential already, which provides her with the values for the verifiable attributes. Now, she needs to get the credential schema and definition like she did before while applying for her transcript. She sends her response to the job application proof request.

Acme now receives her application, and they need to verify. They also must get the credential schema and credential definitions for all credentials Alice has supplied, and then they are ready to verify her application. Check the commands in the reference case study.

Car loan application using the job certificate and college transcript:

In our project to explore blockchain self-sovereign identity, we will now see Alice applying for a car loan citing the proof of having a job with Acme Corp. For this, Alice needs to apply for a job certificate from Acme Corp.

The process is similar, where she needs to check the credential schema and definitions and apply for a job certificate credential. Acme Corp. issues her a job certificate credential, following the process I have described earlier, and Alice stores it in her wallet.

Alice will apply for a car loan with the Thrift Bank, and they need to see proof that she is employed, and meets a certain salary level requirement. Hence, she first establishes an Indy connection via their website loan application screen.

In our example, the Thrift Bank car loan application requires two categories of proofs:

  1. Employment status and salary level to prove eligibility for a loan;
  2. ’Know Your Customer‘ (KYC).

Alice segregates her credential information in her wallet and sends the employment proof only to the Thrift Bank first, to prove her eligibility. Upon verification by the bank of her eligibility, she sends her KYC credentials. For the KYC proof, Alice uses her college transcript.

Alice uses a process like the one she had used while proving her academic credentials to Acme Corp. See the commands in the reference case study.

This completes the example project to create a self sovereign identity wallet. You can view the Indy SDK code in their GitHub repository.

Cost of creating a blockchain self-sovereign identity wallet:

The example project I mentioned has only a few functionalities and a limited number of entities. Your self sovereign identity wallet development project could be more complicated, and your cost will vary depending on the manpower cost in your geography.

Blockchain is a new technology, and Hyperledger Indy is very new too. While you may have UI/UX developers and testers in your team already, blockchain developers charge a high price, because it‘s a niche skill. Consider getting professional help.