Identity management models: A snapshot
A digital ID is different from a physical ID such as a passport or driver's license in that it uses advanced technology to provide digital proof of legal identity for in-person and remote transactions.
As cryptographer Christopher Allen noted in his seminal 2016 blog, the idea of digital ID has been evolving for a few decades now, from centralised identities to federated identities to user-centric identities to self-sovereign identities.
There was no concept of ‘digital ID’ in the pre-internet era. Users would operate multiple ‘accounts’, both within and across organisations — for instance, an enterprise user would have a separate LAN-ID and email-ID, and depending on their responsibility, maybe even a separate user-ID for payroll systems, HR systems, network management systems, database administration, etc. This approach of using access-control lists (ACL) — in which users authenticate themselves using a unique identifier (username) and security token (password) — was one of the earliest forms of digital ID management.
It was against this backdrop that centralised (or siloed) ID management systems came into being on the internet. In centralised systems, administrative control is exercised by a single authority that can confirm or deny access to a user. Examples include certificate authorities (CAs), domain name registrars, and individual websites.
Eventually, the internet saw a flurry of activity and a simpler way had to be found to authenticate users on websites. What started with Microsoft Passport (1999) and became popular with social login constitutes the second phase of identity management, also known as federated ID management.
In federated systems, administrative control is exercised by multiple federated authorities that enable users to utilise the same ID on multiple sites by exchanging shared secrets over secure channels. However, the digital identity or persona is still owned by companies like Google, Facebook, Twitter, etc. putting the company, and not the user at the centre of the federation.
The next phase in this evolution offered the user some level of control on the sharing of identity data (through consent) and brought them to the centre of the identity process. The IIW community referred to this as User-Centric ID in order to shift focus from the server-centric model of centralised authorities.
In user-centric systems, administrative control is distributed across multiple authorities without the need for a federation. User-centric designs brought in two key elements — user control and interoperability. But true user control of identity needed an additional element, autonomy!
Self-Sovereign Identity (SSI)
The origin
Verifiable credentials are one of the conceptual building blocks of SSI (we look at others in ‘The architecture’). Every credential contains a set of claims made by the issuer of the credential about the holder of the credential. The verifier can use the credential to obtain cryptographic proof about both the claim and the holder. The relationship between the issuer, holder, and verifier is often referred to as the trust triangle. In all three identity management models described above—centralised, federated, user-centric—the exchange of verifiable credentials is essentially controlled by the issuer.
The fundamental objective of SSI is to transfer control of verifiable credentials from the identity issuer to the identity holder.
Self-Sovereign is a just inventive term used to refer to the autonomy and control of the identity holder. In fact, the words 'sovereign' and 'identity' were perhaps used together for the first time in this 2012 blog titled What is Sovereign Source Authority?.
The vision
At its core, SSI is attached to the expression of individual autonomy and control. The vision for SSI is to correct the power imbalance between the identity issuer and identity holder (individual), recentre identity around the individual, enable them to deepen the relationship with their data, and determine their interactions with society.
In 2005, Kim Cameron, one of the foremost global experts on digital identity wrote about an identity metasystem that can offer the internet the identity layer it needs. SSI has the potential to be that universal identity layer for the internet.
The architecture
Drummond Reed, co-author of the W3C draft of the core architecture and data model of Decentralised Identifiers (DIDs) considers there to be seven constituent parts of SSI—verifiable credentials, the trust triangle, decentralised identifiers (DIDs), digital wallets, digital agents, blockchains and governance frameworks.
We have already discussed verifiable credentials and the trust triangle. We shall now discuss (arguably) the most important component of SSI architecture—decentralised identifiers (DIDs).
DID is a new type of identifier that enables verifiable, decentralised digital ID. Unlike federated identifiers, DIDs are designed such that they can decouple from centralised authorities and operate on any decentralised network to avoid a single point-of-failure.
Think of DIDs as the IP address (internet protocol address, something we are all familiar with) of an identity holder. Though its structure is different from an IP address, just as two devices with distinct IP addresses can use TCP/IP to exchange data, two identity holders with DIDs can use an SSI protocol to form a cryptographically secure connection and exchange data.
Advantages and challenges
There is no doubt that SSI offers many advantages, but equally, its adoption path is dotted with many challenges. As is the case with any emerging technology, a selectively optimistic view would not serve SSI well over the long-term.
Major advantages include:
- DIDs create an interoperability bridge between the worlds of centralised, federated and decentralised identities.
- As identity holders are in complete control of how much to share (data minimisation), who to share with, and for how long to share, and as it is no longer necessary for identity providers to store users’ identity data, SSI reduces the likelihood of data breaches and identity frauds.
- SSI reduces data management costs and increases the efficiency of the identification process at the organisational level.
Challenges include:
- Though SSI implemented over a decentralised network like blockchain offers a broad guarantee of modularity, transparency and security; with 100% administrative control of digital IDs vested in individuals, it is hard to guarantee security at the user-level.
- According to a McKinsey study, by 2025 the global datasphere will grow to 163 zettabytes (one zettabyte is a trillion gigabytes), SSI is nowhere near ready for large-scale population-level usage.
- In order to access SSI, decentralised apps use unique identifiers (DID) and asymmetric encryption, i.e., a cryptographic key-pair. When an identity holder establishes a secure connection with an identity issuer, a pair of public and private keys is generated. As participants in a blockchain network, both holder and issuer create unique DIDs, attach their public keys and write them to the blockchain. Private keys are necessary to execute transactions to and from the blockchain address associated with the public keys. It is hard for individuals to store private keys. Moreover, individuals need access to a trusted execution environment for secure key management. Such environments are vulnerable to attacks from malicious actors. If a user loses the private key, they have to generate a new key pair and update the blockchain. In summary, it is hard to reset cryptographic keys that have been lost, stolen, or corrupted in DID systems.
Real world examples
It has been suggested in the wake of COVID-19 that SSI can be used voluntarily by individuals to easily and securely demonstrate verifiable immunity credentials in a way that can scale across regions and countries and revive the travel, hospitality and entertainment industries, globally.
As we had pointed out in an earlier article, online purchase and delivery of liquor require an individual to prove that they are of legal drinking age. Instead of sharing a physical ID for age verification–which would also expose their name, address and other personal details–SSI would allow individuals to create and share ‘verifiable credentials’ that simply prove that they are of legal drinking age without getting into specific and ‘linkable’ details like date of birth, etc.
Car rental is another, more conventional use-case for SSI. The car rental company, customer and the vehicle (seen as an entity) can generate a DID, write it to the blockchain, and then request issuers for verifiable credentials such as the registration certificate and insurance policy, driver’s licence, and car’s licence plate number. After issuers provide verifiable credentials to the identity holders, the holders can provide consent, and selectively or fully disclose information to the verification service providers.
Similarly, SSI solutions would also work well in high-trust, multi-stakeholder industries and applications such as financial services, healthcare and government.
Interplay with data protection regulations
There are two relatively recent phenomena that have necessitated the development of a privacy-preserving form of digital ID. One is the overproduction of personal data. The other is rising awareness about the individual and institutional costs of large-scale data breaches like Equifax and Cambridge Analytica. Interestingly, in Christopher Allen’s personal view, while institutions can somehow still bear penalties and costs, individuals cannot and should not have to bear the cost of someone else’s negligence.
In some sense, SSI and data protection regulations like PDPB and GDPR have a shared vision of the future. While the regulations aim to protect the privacy-related interests of the individual, SSI sees the individual as the sole gatekeeper of their identity.
From a techno-legal perspective, data protection regimes like PDPB and GDPR regulate the processing of personal data—which has a broad and evolving definition. An authoritative paper on the subject classifies SSI data components into four categories — DIDs, credentials, revocation of credentials and hashes (relating to the first three).
Of the four, credentials and revocation of credentials have characteristics of personal data — credentials convey some information about the identity holder; besides, it is easy for issuers and verifiers in the ‘trust triangle’ to trace them back to the identity holder (incidentally, revocation does not mean deletion of credentials).
Things are a little more complicated in the case of DIDs and hashes. DIDs are not created by a centralised authority but by the identity holder or data principal (refer PDPB definitions).
In a decentralised network like blockchain, DIDs are stored on-chain; since the identity holder is the one writing to the blockchain, from a PDP perspective the holder is both a data principal (because the DID pertains to the holder’s personal data) and data fiduciary (as the holder is the one writing to the blockchain at the transaction-level) — however, the obligations of a data fiduciary as mentioned in PDPB may not apply to the identity holder. In the case of hashes, the determination works on a case-to-case basis and is outside the purview of this analysis.
Conclusion
In summary, traditional identity management models do not always consider the user as the principal stakeholder; hence, SSI is the next logical step in the evolution of digital IDs. Without SSI, users’ personal data will continue to be scattered across multiple centralised entities.
With the introduction of data protection regulations such as PDPB, there is a new lens to view personal data and digital ID rights. Incidentally, there is alignment between SSI and data protection regulations on the subjects of user autonomy and interoperability. A case-by-case analysis of specific applications is required to determine what data components of SSI constitute personal data and might be subject to strict regulation.
When storing data on the blockchain, there are a set of operating constraints that we have enumerated earlier in this series. There are a few questions to consider before the concept of SSI can become mainstream. For governments — when will SSI be ready for population-level usage? For companies — what are the merits of adopting SSI as the primary identity management model? For individuals — when will enough entities and individuals start using SSI for it to matter?
References and Additional Reading
- Chistopher Allen's Blog: The Path to Self-Sovereign Identity
- Podcast: Blockchain and SSI, Arwen Smit
- World Bank: Digital ID and the Data Protection Challenge
- Manning Publications: Self Sovereign Identity, Drummond Reed & Alex Preukschat
- Hackernoon: GDPR and Self-Sovereign Identity: What Lies Ahead
- Paper: Self-Sovereign Identity on the Public Blockchain and GDPR
(Disclaimer: The views and opinions expressed in this article are those of the author and do not necessarily reflect the views of YourStory.)
Link : https://yourstory.com/2020/11/self-sovereign-identity-context-data-protection-privacy
Author :- Kartik Mandaville ( )
December 03, 2020 at 12:39PM
YourStory