November 14, 2019

Self-Sovereign Identity: A Distant Dream or an Immediate Possibility?

Rajesh headshot
Rajesh Pakkath Director of Product Management

To help solve the identity problem, enter Self-Sovereign Identity (SSID), which enables users to own, control, and present their identity data as needed all the while enabling service providers to securely validate and trust the identity claim.

Self Sovereign Identity

In today’s digital world, our identities are scattered everywhere, across every app and service we interact with either at home or at work. Most of us have lost track of the countless set of registration forms we have filled and provided our personal identity information with a faint assumption that the provider can be trusted and will secure our data. But this uncontrolled data proliferation and the service provider’s inability to properly secure critical elements of identity have time and again proven to be the root cause of frequent identity breaches. Social Identity providers such as Facebook, Twitter, LinkedIn rushed in to address this issue by centralizing the identity and presenting it to the requesting service upon user consent. Some of these centralized identity providers have become regular and easy targets for hackers to obtain users information from one source rather than scour through multiple providers.

These breaches not only effected our social, professional, and financial lives but also led us to slowly accept the alternative reality that privacy is no longer a social norm or a personal choice. Providers also are subject to liability provisions storing users’ data across geographical jurisdictions and are required to comply with various privacy compliance requirements such as HIPAA, GDPR, CCPA etc. and any breach into their systems could result in significant fines and reputation loss. This makes the identity problem a double-edged sword for the user and the provider and a difficult one to solve.

Enter the world of Self-Sovereign Identity

Now imagine a concept where the digital world no longer requires a user’s personal data but can validate the identity by just accepting a “verifiable credential” issued to the user by competent and trusted identity authorities. A non-digital equivalent of this would be our paper-based passports, driver’s license or birth certificates that are issued by the relevant government authorities that we store in a secure place and present as a proof to services that require them. For instance, each time we (the holder) board an airplane or rent a car we prove our claims by opening our wallet and presenting a trusted authority (the issuer) issued identity card to a person or company who needs to trust the claim (the verifier).

In the digital world, this would be achieved using mathematically derived unique and random identifiers, known as the Decentralized Identity (DID). The user uses a secure wallet app on their trusted device to generate a public/private key pair, store the private key in the device and publish the public key to a SSID powered decentralized ledger (like Sovrin) that would then generate and store the User DID for the public key in its data store. The user then requests a trusted authority (such as Department of Motor Vehicles for Driver’s License, Department of State for Passport etc.) for validated digital identity claims. The trusted authorities issue verified credentials, containing verified personal information/attributes about the user (claims), after signing it with its own DID (known as Issuer DID). The verified credential is then counter-signed by the User DID and stored in a secure wallet app on a device, encrypted and fully in the user’s control. When service providers require user information, users can present the whole claim or only a subset of the claim of the verified credential from their secure wallet (and hence self-sovereign). The claim can also be modified by the user to ensure minimal disclosure of private data (for instance, present Age>18 without revealing the user’s date of birth) without compromising the signature of the original claim. The service provider can validate the authenticity of the identity by verifying the public key signatures of the User DID and Issuer DID on the decentralized ledger and provide the requested service based on the presented claim. Users can also use their wallet to view and track which service providers they granted claims to and revoke them at any time as needed.

This concept is what is referred to as the Self-Sovereign Identity (SSID) which enables users to own, control, and present their identity data as needed all the while enabling service providers to securely validate and trust the identity claim. SSID can also be viewed as a “decentralized, claims based authentication and authorization” of user by the service provider (Claims Verifier) with the public decentralized ledger acting as a smart verifiable contract between the Issuer, Holder and Verifier entities. Blockchain technologies such as Sovrin, Bitcoin and Ethereum are built on decentralized ledger technology (DLT), are immutable by design and qualify as the ideal candidate for solving the concept of SSID.  It’s important to note that users personally identifiable data are only stored on the end user’s device and never on the blockchain ledger. Claims Issuers are also not required to be online during claims verification as verification is performed against the highly available decentralized ledger.


Self Sovereign Identity image1


Let’s see how this works with a use case. John Smith needs to rent a car for his personal travel. Typically, he would need to individually sign up with all his personal details at car rental websites to prove his age (provide his date of birth) and provide proof of a valid driver’s license (upload a copy of his Driver’s License) before he can complete the booking. The below diagram represents how he will present his present his SSID to complete this transaction.


Self Sovereign Identity Image2

In the above use case, John (the holder of the verifiable credential aka Digital Identity) is only required to provide his personal information to prove his identity with the trusted identity provider, Department of Motor Vehicles, obtain a validated, verifiable credential that is signed by the Issuer DID that is previously registered in an de-centralized data store (Verifiable Data Registry). This signed credential/claim can be securely stored in his trusted mobile device and be associated with a unique digital identity (User DID) that is also registered in the de-centralized data store. Once this is established, he can choose to present only a subset of the digital identity attributes that is required by the car rental company without invalidating the signature of Department of Motor Vehicles. The car rental company can then verify the authenticity of the identity and claim by verifying the User and Issuer DID signatures (contained in the claim) against the verifiable data registry, validate that John meets the legal age requirement to drive and has a valid driver license before completing the booking. The transaction would not have gone through if his driver's license has expired as per the rules (Expiry date) defined against the verifiable credential schema setup by the Department of Motor Vehicles. If he must make a reservation at a hotel or book his airline tickets, all that is required by John is to share this verified digital identity without needing to register with his personal information in each of these service provider websites.

Challenges to Self-Sovereign Identity

There are a few real-world use cases that indicate the rapid advancement and usage of blockchain for digital identity. However, industry standards for digital identity definitions and its interoperability mechanisms are just evolving, primarily driven by World Wide Web Consortium (W3C), and would need to be finalized to enable holders, issuers, and verifiers to securely transact using digital verifiable credentials.

Self-sovereign also does not mean you have full rights to verify your own identity. There is still reliance on trusted authorities to validate and issue verified credentials. Users are still required to obtain such verified credentials from multiple trusted authorities and store it in a secure wallet on their device before they can transact with today’s digital world. The scenario of how users can move their verified credentials from one device wallet to the other or when they lose their trusted device is another challenge worth noting.

Then comes the important challenge of the right to be forgotten. Though the presented claims are not expected to be persisted by the service provider, there can be several instances where they would want to store user attributes in their own data store for seamless and continued service. For instance, an on-line shopping retailer will require name, address, phone number to deliver an item ordered by the user. Even though they may have obtained this data upon express consent of the user, they may decide to store it in their own datastore for continued service or marketing needs. The data then is outside the self-sovereign identity realm which then breaks the very fundamentals of de-centralized identity and the concept of owning and controlling your own data. When the user decides to revoke the previously granted claim, all that he has to do is request the claim be removed and forgotten by the service provider. There are no automated processes or standards in place to fulfill this right to be forgotten scenario, which could then lead to data breaches that self-sovereign identity was conceived to address.

Closing thoughts

As governments and compliance agencies tighten the user privacy requirements, there is no doubt that the self-sovereign identity has great potential to change the way our digital data is verified, stored and shared. Though there is a great deal of enthusiasm around SSID with ecosystem and standards rapidly evolving, we are still very far away from an ideal world where we can truly own, control and transact with our self-sovereign identity.

Rajesh Pakkath

Rajesh headshot
Director of Product Management

Rajesh Pakkath is Director of Product Management at Idaptive, responsible for driving the product strategy and roadmap for Idaptive's Next Gen Access Cloud platform that secures access for everyone, everywhere and on every device.

Prior to this, Rajesh was a Senior Principal Product Manager at Oracle Corporation, where he led the development and delivery of the company’s on-prem, cloud identity and mobility products.

With more than 20 years of experience in designing, developing and delivering software, Rajesh has leveraged his deep technical, domain and consulting background to develop innovative products and solutions in the Identity and Access Management space.

Rajesh graduated from Coimbatore Institute of Technology, India with a degree in Applied Sciences and is an Associate Member of Institution of Engineers, India.