Hero image

Security

The Benefits of Self-Sovereign Identity Authentication Using Blockchain

Home

>

Blog

>

Security

>

The Benefits of Self-Sovereign Identity Authentication Using Blockchain

Published: 2022/12/13

Updated 02/08/2023

9 min read

Digital identity has become a part of everyday life and guarding it should be the utmost priority. In the United States alone, the number of identity theft cases reported to the Federal Trade Commission has significantly increased in the last five years – according to the FTC’s Consumer Sentinel Network (CSN) report. The standard way of using a single login and a password is no longer secure and Single Sign-On (SSO) authentication schemes that allow a user to log in with a single ID also seem increasingly outdated as it stores identity data in a centralized way.  

The rising alternative is the Self-Sovereign Identity (SSI) approach to the identity management, which takes advantage of blockchain technology. What makes it so different and secure, and how exactly does it work?

Holder, verifier and issuer

Self-Sovereign Identity makes it possible to change the identity and credential management model from the standard (centralized) client-server model to a peer-to-peer model that enables decentralization. In addition, blockchain technology guarantees the authenticity of data without storing it, which can significantly affect data security and minimize the risk of identity theft. Thanks to it, credentials such as national IDs and driving licenses can be created digitally by governments. 

A subject involved in the identity management process using SSI, usually a person or organization for whom the relevant credentials have been issued and are held in his digital wallet, is conceptually known as a holder. 

An issuer of the credential provides each credential to a specific entity. Examples of an issuer include government institutions, financial institutions and universities. In addition, each credential must be verifiable by the entity running the verification process, known as a verifier. The role of the verifier is to ask for proof (request proof), which the holder may or may not provide (consent is optional). 

All communication, including the signing of credentials, is done by using a Decentralized IDentifier (DID) protocol.  

The importance of DID

Thanks to SSI, credentials are created by you and stored in the blockchain or distributed network. 

A DID itself is a unique identifier. Here’s an example: 

did:test:2m423rm0gi3g59g3n5g. 

DIDs are longer than regular users’ credentials and are not easy to remember. Their main feature is their ability to show that you control and own it. It is possible, due to the fact the ledger stores the public key, while you hold the private key. 

To connect with different peers, you have to utilize different DIDs so every user may have a lot of them. The keys to connect with one organization or person will be used only once DIDs are registered on a distributed network, private blockchain, or public blockchain and do not have any central registration authority. 

It’s worth noting that a Decentralized IDentifier has four characteristics that have never been accessible for any other identifier in history: 

  • it is a permanent identifier and does not need to be changed, 
  • it can be used to check and get metadata, 
  • it proves who is the DID owner, using cryptography, 
  • it does not require a central registration authority. 

A DID is composed of three parts: method-specific identifier, method specification and scheme. Method specification makes it possible to use a DID with various blockchains and enables the right use of method-specific ID at the end of a given DID. 

Method specification describes the possibilities of reading and writing a DID on the blockchain, which might differ for each network depending on its specification. It also defines how to make CRUD (create, read, update, delete) operations on a DID and DID documents. 

What is a DID document?

It’s a JSON-LD document that describes the entity connected with the DID. It treats blockchain like a key-value store, where the key is the DID and the value is the DID document.  To simplify it, a DID makes it possible to see details of the DID document. 

DID document typically consists of six elements: 

  • Decentralized IDentifier used to describe itself
  • Set of public keys permitting it to be verified
  • Set of auth methods allowing authentication
  • Set of service endpoints that make interaction possible
  • A signature proving that the DID Documents are valid 
  • A timestamp representing the creation date

After presenting a DID to a website, using a dedicated link or QR code, the authentication process starts. The website checks your public key and requests you to sign a challenge with your private key. After positive verification of a private key signature with the public key, it is possible to see the DID document. It is not obligatory to store DID documents on the blockchain but keeping a pointer to the DID document on the blockchain is good practice to keep and use another network as a storage for DID documents.  

To make a DID and decentralized identity work together, three layers are required to establish a connection with two different users. 

The first one is the Edge Layer, for example, an app on a smartphone that acts as a digital wallet. The mentioned app will connect with the second layer, known as the Cloud layer. The Cloud layer contains entities that know how to resolve a DID into a DID document. Communication between entities in the Cloud layer is similar to communication in mail servers. The final layer is the DID layer, a blockchain where DID documents can be found. After establishing a connection with two different users, communication between counterparts may be done peer-to-peer in order to reduce actions involving blockchain which are not necessary when transmission is secure. 

Real-life use case scenarios of SSI authentication

Blockchain authentication has plenty of use cases. These real-life examples will show SSI technology and how credentials are issued, stored and verified. The model described below underlines the organizations needed to make the whole process work properly. 

For the sake of the use case scenario description, let’s pick an organization that sets the standards for the schemes. Ideally, a trusted organization – like a governmental body. After establishing which fields should be in such a scheme, the issuing organization (issuer) should follow this standard to align the certificates issued with the organizations verifying those certificates (verifier). As an illustration, let’s create a university graduation scheme and an employment certificate scheme. 

A student, let’s name him John, applies for a job after completing his studies. The corporation he chose requires proof of graduation. The university issues a graduation certificate based on a scheme set by the government – the graduation scheme. Once the certificate is successfully issued and accepted by John  he saves this data in his digital wallet, which is where it will be stored (using a mobile app). Thus, John assumes the role of credential holder. 

When applying for a job with a corporation, John presents credentials in their wallet. Once these credentials are accepted, the corporation obtains reliable proof of John’s graduation. 

In this example, John had the role of person proving his skills as a credentials holder (prover). The university was a credential issuer, while the corporation acted as a credentials verifier.   

Another example can be described as a natural course of a student’s life after he gets a corporate job – applying for a mortgage. To do this, he asks the corporation to issue a credential confirming his employment (a certificate of employment). Based on the scheme standard issued by the government – the corporation issues the relevant credentials (an employment certificate scheme), which, once accepted by John, now an employee in a company, stays in his virtual wallet. John already has two credentials in his digital wallet, which can be used depending on what data subsequent organizations will expect from him. 

John presents the required credentials to the bank (both credentials, to be precise). Once accepted, the bank can see John’s degree and the fact that the he is employed, which should greatly facilitate the decision when granting the loan. 

In this example, John also acted as a person proving his skills (credentials holder/prover). The university and the corporation acted as a credential issuer, and the bank acted as a verifier of the submitted data. 

The examples above show how, if schemes are standardized, users can store and use their own credentials in a secure and decentralized manner.

Ebook "How to Reduce Software Development Costs During an Economic Downturn"

Blockchain network and DID – technical explanation 

How does the information exchange between the issuer, holder and verifier work on the blockchain? Through communication between Aries Cloud Agent Python (ACA-Py) agents, which are directly plugged into the blockchain network. Such agents can be covered by any prepared application that supports the REST API (for example, a module developed in Spring Boot). This allows the REST module to expose endpoints that allow interaction with the ACA-Py agent, while listening for asynchronous messages coming from the blockchain network sent by an agent to dedicated endpoints (i.e., webhook). 

A connection is required to properly exchange data between a user (holder) and an organization (issuer). To do so, a link or QR code, for example, is made available on a dedicated webpage. The user, utilizing the appropriate application, activates the generated link, and as a result, AcceptInvitation messages are exchanged between the agents plugged into the blockchain network with the connectionId parameter, which is unique and dedicated to a specific session. 

Once the connection between the two agents (holder and issuer) is properly established, the actual data exchange can proceed, such as requesting the issuance of the appropriate credentials (issue credentials). In the case of John (holder) and a university (issuer), this can be a request for confirmation of graduation, which he may need to apply to another organization (verifier). According to the information given earlier, the verifier must be able to confirm that the provided credentials are correct – this is the exact spot when the communication between the verifier and the issuer takes place. 

Decentralized IDdentities of the future

Thanks to SSI, it is now possible to build new identity frameworks based on the concept of decentralized identities. By ensuring the authenticity of data without storing it, blockchain technology and the SSI authentication approach can significantly improve data security and minimize the risk of identity theft. This faster, more reliable and more secure solution seems to be the identity management technology of the future.  

Software Mind has extensive identity management-related experience and is up to date with the newest security trends and technologies. Our experts will gladly guide you through the world of security solutions. Contact us using this form.

Questions and answers:

What are the main advantages of self-sovereign identity (SSI) authentication using blockchain?

The main advantages of self-sovereign identity (SSI) authentication using blockchain are decentralization and heightened security, complete user control, enabled interoperability and boosted cost efficiency. It’s worth elaborating on these aspects. With SSI, individuals can take control of their identity data and decide what information to share and with whom. This approach is designed to enhance privacy and reduce identity theft risk by allowing users to disclose only necessary attributes while keeping sensitive details safe. The decentralized nature of blockchain technology is another advantage of SSI, as identity data is distributed across a network of nodes, ensuring security by eliminating single points of failure or hacking vulnerabilities. SSI on blockchain also brings interoperability and portability to identity verification, enabling users to seamlessly utilize their identities across various applications and platforms. Additionally, businesses can benefit from cost efficiency with SSI, as it streamlines identity verification processes and eliminates the need for redundant verification and data storage.  

Is self-sovereign identity the same as decentralized identity?

Self-sovereign identity (SSI) is not the same as decentralized identity (DID), although both concepts are related. Self-sovereign identity is an identity concept that enables individuals and businesses to store and manage their data on their devices, allowing them to share their information when required for validation purposes without relying on a centralized database. Decentralized identity is distinct from the self-sovereign concept. With a DID, a user has complete control and authority, and there is no central registry, identity provider, or certificate authority that verifies the data. The concept of SSI is all about giving users control over their identity data and ensuring their privacy. Decentralized identity can also be described as a technical framework that makes SSI possible using blockchain and other decentralized technologies to create, store, and verify DIDs. 

About the authorDaniel Sutkowski

Software Architect and Team Manager

Daniel has more than 10 years’ experience in software development in various fields, including telecommunications, security and payments. He specializes mainly in Java and related technologies geared toward microservices architecture and has experience working with containers and their orchestration using Kubernetes. He is interested in frontend technologies that focus on UX/UI aspects. A contributor to the Software Mind Security Guild. Daniel is a proponent of the KISS principle.

About the authorPaweł Czernicki

Software Engineer and Team Manager

Paweł has over 5 years’ experience in telecom projects at Software Mind, working in both backend and frontend project development. Paweł participated in backend projects using Java, Spring/ Spring Boot and frontend projects in React and Angular. A member of the Software Mind Security Guild, he’s interested in taking on new challenges, and, in his free time, enjoys swimming and rollerblading.

Subscribe to our newsletter

Sign up for our newsletter

Most popular posts