“Trust, but Verify” a popular quote that was frequently used by the former American President, Ronald Reagan when discussing U.S. relations with the Soviet Union. Trust is such a valuable factor in any ongoing relationship and is even more important when it comes to establishing the identity itself that is seen as a fundamental aspect to begin and develop any relationship. Identity cannot be easily proved without the sharing of personal data by the parties involved but doing so might lead to compromising the user’s privacy. The advent of technologies solves this underlying security problem by enabling trust when establishing connection between the parties, at the same time preserving the individual’s privacy. This is accomplished by the concept of “Self-Sovereign Identity” (SSI). Enterprises and Governments are gradually adopting this identity technology; however, these SSI solutions need to follow several best practices and extensive assessment before a successful deployment. Hence a correct implementation and comprehensive verification of the overall solution are very important and that is the crux of this paper.
Identity and its Evolution
There are many detailed references that discusses about the digital identity and its evolution. One of the best references to understand them is the blog written by Christopher Allen on “The Path to Self-Sovereign Identity”. Not just the generations in identity, but the blog also briefs about the principles of Self-Sovereign identity, which we will look into shortly. Throughout this paper, we are referring to the digital identity. A digital identity is information on an entity used by computer systems to represent an external agent. That agent may be a person, organization, application, or device (ISO/IEC 24760–1).
The figure above is a good snapshot of the evolution in the Identity Management (IdM) Solutions. Centralized identity is where it all started in which the centralized authorities helped in proving the authenticity of the information coming from different entities. There was plethora of benefits but there were challenges too. The power associated with these authorities including other issues like security and scalability made the researchers come up with the Federated identity solution where the user’s identity could be shared with different service providers, however most of the issues associated with centralization still remained including the privacy risks since the identity is still controlled by a central authority.
User-centric identity solutions seemed to be a better alternative in addressing the challenges with centralization by putting the user in the center and giving more control to the user on their identity, but it still required the user to select the existing powerful identity organizations that involves the user’s personal data for the identity management. Self-Sovereign identity (SSI) looked much more promising than the other three. The key characteristics of user-centric approach were properly defined, and a full sovereign control of that identity is determined by the individual who owns the identity. Finally, a true decentralization of trust could be achieved without involving any central authority in the identity process.
Core concepts in the SSI Solution
We need to understand the core concepts that make up an SSI solution. Let us start with the definition of an important concept, the Decentralized Identifier also called DID. DID establishes the certainty of an individual’s ID without revealing their Personally identifiable information (PII) data. DIDs do not require registration with a central authority and are cryptographically verifiable so that the DID owner can prove the ownership of their identity. These DIDs are used in a Verifiable Credential (VC) which is a digital claim used by the holders. It is the issuer that issues a credential that can be cryptographically verified making it a VC. Verifiable credentials can be used to build Verifiable Presentations (VP). Presentations are the data from the VC issued by issuer and shared with verifier but when this information is tamper-evident such that the authorship of data can be trusted after a cryptographic verification, then it is called a Verifiable Presentation. Another concept is the Wallets that are used by the holders to store all the private information and they are digitally signed. Data schemas also referred to as Schema in short are useful while enforcing a specific structure on a given collection of data and are issued and verified by the respective parties.
Finally, from a concept perspective, it is important to understand the Verifiable Data Registry (VDR) as it maintains the identifiers and schemas. There are many types of VDR that can be used including a distributed ledger. Blockchain is a type of distributed ledger. The SSI concept could be confidently implemented with the introduction of Blockchain. Choosing Blockchain as the VDR helps with a number of benefits for the parties involved including immutability, finality, security, the distributed consensus on the state of the ledger, etc. The Self-Sovereign Identities (SSI) are recorded as DIDs in the Blockchain. Also, it is good to understand and learn about the actors involved. Starting with Issuers, who are the qualified authorities that attests identity data. Holders have the authority to operate the identity data and can selectively share the identity data with the required service providers. Verifiers are the service providers who have an already established trust with the Issuer of the identity and based on that trust, the verifiers provide the service to the holders. Based on the role of the Issuer, there is an optional Examiner role. The primary responsibilities of the Examiner include gathering, examining, and validating the data to perform attestation.
Implementation of SSI Solutions
“A picture is worth a thousand words”. The figure above describes the core actors and the information flow in the credential verification process, implemented in a Permissioned implementation of SSI solution. There are two major implementations of SSI. The Permissioned and Permissionless implementations. There are a few other SSI solutions as well but the adoption of uPort and Sovrin have been on the rise.
· The uPort SSI solution is a Permissionless blockchain implementation, built on the Ethereum.
· The Sovrin SSI solution is a Permissioned blockchain implementation, built on Hyperledger Indy.
Based on the type of implementation, there are many components in each of the solution that has got be understood and analyzed in greater detail. Considering the agenda of this paper, we are not getting into the details of the implementation and its types.
Integrity of SSI Solutions
What is Integrity? Going by the fundamental definition in the English language, “Integrity is the practice of being honest and showing a consistent and uncompromising adherence to strong moral and ethical principles and values.” This integrity is extremely important when developing any software solutions and this integrity must be practiced by Self-Sovereign Identity Solutions as well. How? — Developers should make sure that there is absolute Integrity in following the principles, techniques and approaches that are recommended for SSI solutions. Additionally, verification and auditing aspects should make sure that these SSI solutions are completely adhering to the recommended best practices. From that perspective, there are 4 different areas that we can think about to measure the Integrity of the SSI solutions.
a) Principles of SSI
There are several resources which detail the laws of identity and principles of Self Sovereign Identity. These SSI principles fall into the major categories of core properties, user controllability, and security aspects. All these principles help in safeguarding the individual’s privacy and implement the concept of decentralized identity. It is important that these aspects must be completely verified in SSI solutions once implemented.
Let us study couple of examples. The first example is from the perspective of user controllability, where the users have complete control of their identities. That means, the decision to share the identity data to a particular entity is up to the individual. The SSI system must properly implement this principle by getting the consent of the user while sharing their data with another organization. It could be in the form of a notification that makes a user accept or reject such a kind of identity being shared or other different ways by which the consent is clearly sought from the user.
Secondly, from the perspective of the security category of SSI principles, persistence is an important quality to have in the SSI solutions. Going by the definition of persistence principle, identity could be disposed by the user, if they wish to do so and claims could be modified. This is often misunderstood; identity must be disposed but not deleted. Also, when identity is assigned, claims are assigned along with it. It should be noted that the identity and claims are separate. This means, the users must be able to successfully modify the associated claims but not the identity itself. So, there is a firm separation between claim and identity. Changing the claims helps in changing the identity’s associations. That way the user is able to dispose an identity when there is a need. All the above aspects must be clearly understood and designed in the SSI solution and thoroughly verified to make sure that the identity and claim are not tied forever.
Every principle of the SSI must be thoroughly looked into using the same approach. There might be possibilities where the principles could have been implemented but not fully or a weak implementation leading to compromise of privacy or not implementing the concept of decentralization properly.
b) Components of SSI
The components used in an SSI solution are completely dependent on the type of implementation of SSI. Based on the business requirements, one might choose to go with uPort or Sovrin SSI solution (the two most widely adopted by the industry). Now each of this solution has its own architecture and so the technological components used in them are different. For example, the use of Smart Contracts is specific to Ethereum based solutions which are followed in the Permissionless SSI implementations. When smart contracts are used, (say) when registering an identity, the code must be thoroughly tested for functionality or security bugs. Same is the case when protocols like the Inter-Planetary File System (IPFS) are used for storing and sharing data in a distributed file system, where a complete assessment is highly recommended.
There are some other components that are common to both the SSI implementations. Some of them being the use of the Wallet for storage of PIIs, keys, etc, use of Agents, that are a software program used to interact with another entity or DIDcomm the messaging protocol, used by entities for exchanging credentials.
When we apply the lenses of Integrity to DIDcomm, then, all the properties of DIDcomm must be carefully implemented — During any kind of peer-to-peer message exchange, DIDcomm implementation should follow all the security and privacy considerations, also it should be completely flexible to work on any underlying infrastructure, thereby making it interoperable. Also, DIDcomm specifications would be mostly implemented in json (though there could be other implementations as well), a through security review of the json protocol during any agent-to-agent communication is a must. All these are just a snapshot of what one needs to do for DIDcomm, but one must follow the complete guidelines recommended by the DIDcomm messaging specification from the identity foundation. Similar to how we analyzed the DIDcomm protocol, we have to apply the best practice during the designing and implementation of other components like the Wallet, Agent, the off-chain databases, etc in the overall SSI solution.
c) Lifecycle of SSI
There are three important SSI objects that form the foundation for a success identification of an individual in an SSI system — They are the key, identifier, and credential. It is essential to understand the lifecycle of these SSI objects and ensure they are implemented properly. The first SSI object is the key and Lifecycle of key deals with many aspects right from the creation to storage and deletion of the key. At first, this looks to be a very generic one with any security system, but the key pairs have an important role in the creation of the identifier itself. The user makes use of their public key for registering a DID on the Blockchain. This could be verified from the DID Document Object (DDO) that has all these details including the public key, the DID, claims describing the entity, etc.
It is important to note that, from a secure communication perspective, a user does not have only one public key, but the user creates a new public key for every party that they are interacting with so as to form a bilateral relationship. This means a new DID Document is created for every new entity that they establish a connection with. If an entity decides to end such a relationship with another, then the identity would be disposed. This can be accomplished by revoking the DID, or not updating the DID whenever the public key is rotated, etc. All these deal with the lifecycle of the identifier. The complete lifecycle aspects right from creation to revocation including all security and cryptographic principles must be well implemented. The third SSI object which is the lifecycle of credentials, must also be implemented by following the principles recommended for it.
d) Regulations for SSI
Solutions that implement SSI are an amalgamation of many technological components. The SSI implementations have some recommended regulations to be adhered to both from the perspective of the overall solution and individual components used to build them. Let us see an example in both the categories. When it comes to an individual component, we have seen that Blockchain has a major role in the infrastructure of the SSI system. The International Standards Organization (ISO) has been working on a standard for Blockchain and Distributed Ledger Technologies (DLT) which is the ISO/TC 307. A large part of this is under development but in future we will have a clearer picture on the mandatory requirements to be followed. Many aspects of the deployment and configurations of the interoperability, security, privacy, identity aspects, and the smart contracts of Blockchain will have a regulatory requirement.
From an overall SSI solutions standpoint, there are a few regulations that we may have to consider namely the data protection requirements, privacy related requirements, etc. The privacy regulations could vary based on the geography of the customer base, we have Personal Information Protection and Electronic Documents Act (PIPEDA) in Canada, California Consumer Privacy Act (CCPA) for California, etc. The data protection requirements would deal with the uniqueness of the electronic signatures of the individual using it, the association between the electronic signature and electronic document, etc. Global Data Protection Regulation (GDPR) is one that mandates these requirements. Some of the other requirements that GDPR mandates include accessing the individual’s personal data only after proper consent, individual’s right to erase the data when they are no longer needed for any processing purposes, etc. It is recommended that these regulatory requirements are incorporated into the design and configured, in addition to performing a regulatory audit which verifies if the solution is adhering to all of the mandatory points.
The SSI solution could be a subset of a bigger solution interoperating with other existing solutions. These may include registration services, admin services, interoperable with other platforms, APIs that are being exposed, the web and cloud platforms where these services are launched, and many others. The future of SSI based solutions are going to be exciting with more and more enterprises developing these solutions, specific regulations being identified for easy adoption by the businesses and consumers and different variants in the solution implementations. But with all these developments, it is important that the complete solution is well designed by incorporating all the requirements, fully reviewed, and verified so that the integrity of the solution is intact and truly self-sovereign.
Some of the links which I have referred to during the course of writing this paper and other useful article to explore this topic.
6. “Design-Pattern-as-a-Service for Blockchain-Based Self-Sovereign Identity”, Article in IEEE Software · May 2020
7. “Self-Sovereign Identity Specifications: Govern Your Identity Through Your Digital Wallet using Blockchain Technology”, Article in 2020 8th IEEE International Conference on Mobile Cloud Computing, Services, and Engineering (Mobile Cloud)
Integrity of Self-Sovereign Identity Solutions was originally published in DataDrivenInvestor on Medium, where people are continuing the conversation by highlighting and responding to this story.