How to Build a Self-Sovereign Identity Wallet?

Wondering how to build a self-sovereign identity wallet? In this guide, I will describe the process to build an SSI wallet using Hyperledger Indy.

In this article

1. What is self-sovereign identity?
2. What is a self-sovereign identity wallet?
3. Building a self-sovereign identity wallet with Indy: project overview
4. How to build a self-sovereign identity wallet: 9 steps
5. Cost of creating a blockchain self-sovereign identity wallet
6. Frequently Asked Questions on self-sovereign identity wallets

Before we start discussing how to build a self-sovereign identity wallet with Indy, let’s quickly go over two important terms — self-sovereign identity and self-sovereign identity wallet.

What is self-sovereign identity?

Self-sovereign identity (SSI) is a digital identity model that gives people complete control over their personal information and how they share this information. SSI typically uses blockchain or distributed ledger technology to enable secure, decentralized verification of credentials. 

What is a self-sovereign identity wallet?

A self-sovereign identity wallet, or an SSI wallet, is a digital tool that helps people manage their verified credentials and personal data. SSI wallets combine several functions, including storage of digital credentials, control, and authentication.

Self-sovereign identity wallets can take different forms such as mobile apps, desktop apps, browser extensions, or even physical devices.

Building a self-sovereign identity wallet with Indy: project overview

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.

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

Get a complimentary discovery call and a free ballpark estimate for your project

Get Started

Trusted by 100x of startups and companies like

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.

How to build a self-sovereign identity wallet: 9 steps

1. 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 detail 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.

2. 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:

• Public keys;
• Service endpoints;
• Credential schemas;
• Credential definitions.

Identity records are linked to one unique ’decentralized identifier‘ (DID), which the distributed ledger resolves 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.

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

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

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

6. 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 a transcript credential schema and publish a credential definition for it. Also, Acme needs to create a job certificate credential schema.

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

8. 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 it. 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.

9. 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 from a reputed software development company like DevTeam.Space.

DevTeam.Space is an innovative American software development company with over 99% project success rate. DevTeam.Space builds reliable and scalable custom software applications, including advanced blockchain-based solutions.

DevTeam.Space supports its clients with business analysts and dedicated tech account managers who monitor tech innovations and new developments and help our clients design, architect, and develop applications that will be relevant and easily upgradeable in the years to come.

Frequently Asked Questions on self-sovereign identity wallets