All articles
self-sovereign identity wallet

How To Build a Self-Sovereign Identity Wallet?

Estimated read time: 8 minutes
Aran Davies

Aran Davies

Software ExpertDeveloperWriterPhotographer

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

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 a transcript credential schema and publish 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 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.

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.

Frequently Asked Questions

What is an identity wallet?

An identity wallet is an application that allows users to log into other applications easily. In effect, it allows for a single login for all authorized apps once the persons ID has been confirmed.

What is a good ID wallet app?

• Google Wallet
• ID Wallet
• Venmo

Is there an identity wallet blockchain solution?

There are numerous ID wallets built on blockchain technology. Examples include:
• IBM Blockchain ID solution
• Evernym


Alexey

Alexey Semeney

Founder of DevTeam.Space

gsma fi band

Hire Alexey and His Team
To Build a Great Product

Alexey is the founder of DevTeam.Space. He is among the Top 26 mentors of FI’s ‘Global Startup Mentor Awards’ and is a Band Of Angels Technology Expert.

Hire Expert Developers

Some of our projects

Management Center of Telecommunication Information

Backend, Communication, DevOps, Java, Software

Management Center of Telecommunication Information


Development Team

1 Designer, 2 Developers, 1 QA Engeneer
1 Project Manager, 1 Account Manager
Details
Cryptocurrency Exchange

Blockchain, Ethereum, Fintech, Javascript, React, Smart Contracts, Solidity, Trading, Truffle, Web

Cryptocurrency Exchange


Development Team

3 Developers
1 Project Manager, 1 Account Manager
Details
DDKoin

Blockchain, Ethereum, Fintech, Node.js, Smart Contracts, Solidity, Trading, Truffle

DDKoin


Development Team

3 Developers, 1 DevOps Engineer
1 Project Manager
Details

Read about DevTeamSpace:

Forbes

New Internet Unicorns Will Be Built Remotely

Huffpost

DevTeam.Space’s goal is to be the most well-organized solution for outsourcing

Inc

The Tricks To Hiring and Managing a Virtual Work Force

Business Insider

DevTeam.Space Explains How to Structure Remote Team Management

With love from Florida 🌴

Tell Us About Your Challenge & Get a Free Strategy Session

Hire Expert Developers
banner-img
Get a complimentary discovery call and a free ballpark estimate for your project

Hundreds of startups and companies like Samsung, Airbus, NEC, and Disney rely on us to build great software products. We can help you too, by enabling you to hire and effortlessly manage expert developers.