What is Self-Sovereign Identity
Self-Sovereign Identity (SSI) is an emerging Identity Management paradigm. This privacy-respecting model represents a leap towards a more user-centric digital identity architecture.
Christopher Allen defines SSI as follows:
“…The user must be central to the administration of identity. That requires not just the interoperability of a user’s identity across multiple locations, with the user’s consent, but also true user control of that digital identity, creating user autonomy. To accomplish this, a self-sovereign identity must be transportable; it can’t be locked down to one site or locale. A self-sovereign identity must also allow ordinary users to make claims, which could include personally identifying information or facts about personal capability or group membership. It can even contain information about the user that was asserted by other persons or groups.”
Christopher Allen. “The path to self-sovereign identity”. In: Life with Alacrity (2016).
There are ten defining principles of an SSI system. The following are these principles.
Existence: Entities (e.g. users) must have an independent and real-world existence.
Control: Users must be able to control their identity data. They should have the ability to share it with whomever and under the condition, they decide. Note that this does not stop an entity from making claims about other entities.
Access: Users must have easy access to their identity data. There must be no gatekeepers or filters without the prior knowledge and consent of the identity owner.
Transparency: The algorithms, procedures, and processes involved in the identity model should be visible to the users. Free, well-known, and open-source frameworks are a logical solution to this criterion. opening the system to public examinations, evaluation, and avoiding vendor lock-ins.
Persistence: Identity data should be long-lived and persistent until they are explicitly revoked or removed by the issuer or user. There are many cases where identity data may need to be updated or discarded. These operations should be with the approval of the user.
Portability: The users should have the ability to seamlessly transport their identity data. This is a necessary process for the longevity of the data. The data should not be locked-in with a specific third-party entity if that party has the best intentions of the identity owner.
Interoperability: The identity data should be usable by other entities within the SSI ecosystem. Depending on the use case the data could be consumable by entities across boundaries and jurisdictions. This criterion supports the availability and durability of identity attributes.
Consent: The user should have a clear understanding of how their identity data is used by the service providers. Users should provide their consent and approval on how their data is used. Considerations need to be made to ensure users are not bombarded by unnecessary consent requests, which may lead to consent fatigue.
Minimization: The user should be able to disclose the minimum necessary amount of data with the service providers. Relevant concepts include selective disclosure, progressive trust, range proofs, and zero-knowledge proof.
Protection: SSI places users in the center of its architecture. The right of the users must be preserved at all times. In situations where there is a conflict between the users and the network, the network should attempt to err on the side of preserving the rights of the users. Moreover, the SSI architecture should be orchestrated in a decentralized model to avoid potential censorship activities and monopolies.
More detailed explanation of SSI can be found in [1] and [2].
Some Questions about Self-Sovereign Identity
While SSI brings forth tremendous potential, it introduces many challenges (read research opportunities). Addressing these challenges paves the way for the rapid growth and mass adoption of SSI.
Consistency around Data Management and Wallet experience: Standard practices and policies around the user experience and the way user data is managed should be investigated.
While SSI supports an open ecosystem, there is value in having consistent data management policies, user interactions, and user experience. Regardless of how these practices are done, they should meet the regulatory (e.g. GDPR) and Privacy by Design requirements.
Key Management: In more traditional identity management models, the identity providers accept some of the liability and risk to safeguard users’ identity data. Conversely, in the SSI model, this responsibility and its associated risks are placed on the shoulders of the users themselves. There have been numerous instances of users losing their secret cryptographic keys, resulting in the loss of valuable data and unrecoverable funds. Is voluntary reliance on third-party data custodians (e.g. agencies and data hubs) the only option? How effectively can privacy-respecting and decentralized key management protocols and biometrics help with secure backup and recovery of secret keys [3]?
Consent: As stated by Article 4 of General Data Protection Requirement (GDPR), the consent given by the user must be meaningful, well-formed, unambiguous, specific, and freely given, specifying clear decision. This process is not easy to implement and sometimes hard to identify in the current identity models.
On the other hand, prompting users for consent too often for every data-sharing occurrence has led to what is known as consent fatigue. This is when the users are bombarded with consent notifications. Standards around consent management, presentation, and its enforcement are valuable.
Ideas such as smart wallets that perform automated decisions based on prior user decisions should be entertained.
Access: The backbone of many SSI systems is the distributed ledger technology (DLT) or blockchain. Certain DLT systems are public, allowing any entity to read or write to the ledger, while others are permissioned which permit only a selection of entities to add new records into the ledger. If not carefully designed the permissioned model could be vulnerable to the risk of centralization, or an oligopoly among a few entities. On the other hand, the permission-less and public model may be vulnerable to attacks common in various DLT architectures, including the Sybil attack or the 51% attack in which a single entity can take control over the correct state of the ledger.
Some SSI implementations require rapid interaction with the DLT to register and retrieve records – such as registering a new DID – and because a user may have multiple DID addresses. Questions around the scalability and the cost of operating the SSI network should be clearly evaluated. Second layers solutions that improve DLT performance (such as the Lightning Network for Bitcoin) are interesting ideas to investigate.
Accountability and Governance: What are the policies and procedures around addressing dishonest behaviors or misconducts within the SSI system? And what is the best governance model?
Will placing the stability and enforcement of policies in the hands of a select few trusted nodes (i.e. guardians) a good approach? Would this approach introduce new attack vectors against these nodes, making them the weakest point of the system?
On the other side of the spectrum solutions such as Decentralised Autonomous Organizations (DAO) that rely purely on blockchain smart contracts to provide completely decentralized governance models have also shown to suffer from various flaws.
It is important to realize and articulate the correct degree of decentralization that will support the vision and requirements of the SSI. Certain operations such as trusted identity issuance, identity lookup, and secure storage of data may rely on some degree of centralization and use of select intermediaries. Efforts to determine the correct balance between centralization and decentralization is an important topic.
Trust in Data: While there may be trust in the underlying SSI network as a secure, stable, and decentralized platform, there are valid questions around how an SSI entity is able to recognize and trust the claims it receives from the users. How will consumers (i.e. online service providers) trust the claims they receive. How will the consumers form trust with issuers? What rule does the Trust Framework play in this scenario?
Adoption of New Technology: As a new identity model, SSI requires some modification to the existing system architecture of service providers. A crucial step towards the success of SSI is the discussions and formation of guidelines around the suitable technology stacks, deployment practices, and operational procedures.
Particular attention must be given to the user experience, including the software interactions from the operators’ point of view.
Investment and Commercialization: As a relevantly new venture with a growing ecosystem, but with limited knowledge on the revenue model, known (yet growing) user acceptance and utilization, and unknown risks, each entity within the SSI system must design a strategic plan that supports the investment and the risks involved in the deployment, operation or participation in the SSI network. The SSI economic model may lead to the chicken and egg problem where mass user adoption depends on the support of the service providers and vice versa.
The above list is only a subset of questions on SSI, and there are ongoing efforts to address many of them.
I believe addressing the above questions necessitates objective and unbiased research, discussions, and experiments among all stakeholders in an iterative and collaborative approach.
What do you think about the above questions? Share your thoughts.
