Is Self-Sovereign Identity the ultimate GDPR compliance tool? (1 of 3)

Core concepts and key objectives

Photo by Jaromír Kavan on Unsplash

Few topics are as popular right now as the European Union’s new data protection law, the General Data Protection Regulation (the “GDPR” or “Regulation”), perhaps with the exceptions of self-sovereign identity (“SSI”) and blockchain. Likewise, few topics are as misunderstood or oversimplified. In an attempt to dispel some of the mythology and encourage a more nuanced approach to the conversation, this is the first in a series of posts to assess SSI through the lens of the GDPR.

In Part 1 of this 3-part series, we introduce the core concepts of self-sovereign identity (SSI) and the specific example of Sovrin, a global public utility for self-sovereign identity. We then provide an overview of the GDPR and discuss the compatibility between its key objectives and those of SSI.

In Part 2, we examine how the Sovrin approach to SSI advances the core data protection principles set out in Article 5 of the Regulation and how Sovrin meets the privacy by design and default requirements of Article 25.

In Part 3, the final part in this series, we look at the rights of individuals under the GDPR and examine how each one is supported by Sovrin’s approach to SSI.

Self-Sovereign Identity

SSI is the newest of the three models of digital identity. In the oldest model, known as the traditional or “siloed” model, a centralized organization issues or licenses a digital credential to an individual to access its services. The individual needs a unique set of credentials for each entity that she interacts with, making for a poor overall user experience. This hassle led to the emergence of a second model known as the “federated model”. In this model, a third-party identity provider (“IDP”) provides the individual with digital credentials for signing on or logging into various other services through a “single sign-on” or “social log-in” button. The IDP then “federates” this login to the particular entity or service that the individual is trying to access (e.g. “login with Facebook” or “login with Google”). While this approach solves some of the customer experience problems associated with the siloed approach, it requires the need to trust the IDP as a middleman between the individual and the organization whose services she is trying to access.

SSI is often described as the third-generation of digital identity, which might imply that it is merely an evolution of what came before. But SSI cannot be compared apples-to-apples with earlier models of digital identity because it is qualitatively different. In the SSI model, the individual sits in the middle of her data ecosystem and exerts sovereign or individual control over each transaction or exchange of personal data relating to her. Moreover, rather than concentrating control of data stores and silos in the hands of a few large corporates, in the SSI model, data collection, storage, and processing are decentralized across a flat data ecosystem. This is in stark contrast to the hierarchy created by the siloed and federated models of identity, where the individual depends on a middleman (the organization or IDP) to access her data and to participate in any identity-related transactions. This is anything but self-sovereign.


Although SSI is agnostic in the sense that it does not require any specific company, technology, or solution to achieve, there are a handful of comprehensive and concerted efforts underway to make SSI a reality. For purposes of this post, we’ll focus on the version designed and espoused by the Sovrin Foundation (“Sovrin”) in the form of a global public utility for self-sovereign digital identity. In Sovrin’s approach, digital identities can be created for an individual person or organization (an “Identity Owner”) as well for an animal, natural object, or digital object (a “Thing”).

The technical architecture that enables the Sovrin version of SSI and the creation and use of these digital identities is made up of three key layers of technology:

  1. Digital “Wallets” that hold Credentials (as defined below) and certain other cryptographic materials;
  2. A unique peer-to-peer communications protocol facilitated by pieces of software called “Agents” that form an “Agency Layer”; and
  3. A public permissioned distributed ledger (the “Sovrin Ledger”).

Each Identity Owner or Thing (a “Sovrin Entity”) has a Wallet that contains or holds digitally-signed verifiable credentials (“Credentials”) containing certain information, e.g. claims or attributes, about that Sovrin Entity that have either been issued by an “Issuer” or self-issued by the Sovrin Entity. The Sovrin Entity who is the subject of a Credential held in its Wallet is known as the “Holder” of that Credential.

A Credential contains cryptographic proof of:

  1. the Issuer, i.e. who issued it;
  2. the Holder, i.e. to whom it was issued;
  3. its status, i.e. whether it has been modified or altered;
  4. its validity, i.e. whether it has been revoked since it was issued.

A Wallet also stores private keys, master secrets, and other sensitive cryptographic key material and potentially other private data relating to the Sovrin Entity who controls the Wallet. The Wallet can run on a local device (an “Edge Wallet”) or remotely on a server or cloud hosting service (a “Cloud Wallet”).

In the spirit of SSI, a Sovrin Entity sits at the center of its data universe and interacts with other entities orbiting it by forming unique, direct, and encrypted peer-to-peer connections (each, a “Connection”) with other Identity Owners and Things. All identity-related transactions and interactions with those Connections are directly authorized through the use of a software program known as an “Agent.” Just as with Wallets, an Agent is classified as an “Edge Agent” when it runs locally or a “Cloud Agent” when it runs remotely. Together, these Edge Agents and Cloud Agents form the Agency Layer that allow Sovrin Entities to securely communicate and exchange Credentials with other entities. Agents are provided by “Agencies” — commercial, non-profit, or governmental service providers who make the software that acts on behalf of individuals and enterprises (agency software can also be self-hosted, just as individuals can choose to host their own email or web servers).

To form a Connection, each peer mutually authenticates the other through their respective Agents by exchanging a unique key pair from cryptographic materials held in their respective Wallets. At the time the Connection is formed, a unique decentralized identifier (“DID”) is auto-generated on each peer’s Edge Agent, which will become the way for each peer to authenticate each other in the context of their unique pairwise Connection. DIDs​ are a type of identifier designed for verifiable digital identity that is fully under the control of the Identity Owner​ and not dependent on a centralized registry, IDP, or certificate authority. This method of generating a DID (“DID Method”) is unique to Sovrin and does not require the use of a public ledger, which means that the vast majority of Sovrin DIDs are private or only discoverable in the context of a specific pairwise relationship (“Private DID”). Moreover, for each Connection formed, a “Microledger” is created to provide a transparent record of Credentials exchanged between the peers to that pairwise relationship. This Microledger is also private to the specific pairwise relationship and not discoverable by others.

The third and final piece of Sovrin’s SSI-enabling technical architecture is the Sovrin Ledger, a public permissioned ledger governed by the Sovrin Foundation and a global network of organizations who operate the individual nodes that maintain the ledger (each, a “Steward”).

The Sovrin Ledger is a thin layer of technology used for the limited purpose of storing four things:

  1. Public DIDs (as defined below);
  2. the data types and formats used to make up Credentials (“Schema”)
  3. “Credential Definitions” that reference the relevant Schema, the Issuer who published it and the signature types used; and
  4. “Revocation Registries” (also as defined below).

“Public DIDs” are discoverable DIDs that belong to organizations or entities (rather than individuals), and act as primary or initial connection points for unconnected Sovrin Entities. For example, an organization that wants to encourage potential customers to connect using Sovrin will have a Public DID that they are able to disseminate openly. Once a Connection is made with a prospective customer, the relationship can move to a pairwise one using Private DIDs. “Revocation Registries” are cryptographic numbers maintained on the Sovrin Ledger by Issuers of revocable digital Credentials that use zero knowledge cryptography to confirm or deny whether a given DID is within or outside of a set of DIDs that have been revoked by a given Issuer. This allows a party who wants to rely upon a Credential (a “Verifier”) to ascertain whether the Credential is still valid or has been revoked without revealing that status to parties without a need to know.

In addition to the technical features outlined above, and the robust global marketplace for digital Credentials that Sovrin will foster, Sovrin has a unique legal architecture. Core to this architecture is a “Trust Framework” — a body of standardized agreements on the business, legal, and technical policies for issuing digital Credentials in a given ecosystem (often called the “BLT sandwich”). In the Sovrin model, there is a base-level or foundational Trust Framework that is generally applicable to all parties who interact with or utilize the Sovrin Ledger in one form or another (the “Sovrin Trust Framework”) as well as higher-level “Domain-Specific Trust Frameworks” that address the unique needs of a specific industry, community, or domain. These Trust Frameworks help address some of the key legal challenges to SSI adoption, including in relation to the GDPR.

Overview of the GDPR

The GDPR is concerned with the protection of natural persons with regard to the processing of personal data where “personal data” means “any information relating to an identified or identifiable natural person.” Thus, the material scope of the Regulation is limited to data about individuals and does not extend to data about corporations, organizations, or other entities or things. The territorial scope of the Regulation is much broader and applies to processing within the context of an “establishment” within the geographic or territorial scope of the EU and on the basis of “activities” directed at EU persons, including the offering of goods or services to persons in the EU (irrespective of whether a transaction ever occurs) and the monitoring of their behavior (as in the context of online behavioral advertising). This broad territorial reach is the reason why the GDPR is top of mind for companies and organizations around the world.

The Regulation emerged in — and still contemplates — a world of traditional, centralized data models and certainly did not anticipate an innovation like SSI. The first draft of the GDPR dates back to 2012 and was the first comprehensive look at EU data protection/privacy laws since its predecessor — the Data Protection Directive (the “Directive”) — was adopted in 1995. While the Big Data landscape changed dramatically in those seven years, the changes since have been exponentially more dramatic with the advent of things like augmented and virtual reality, virtual assistants like Amazon’s Alexa, myriad smart devices, blockchain and DLT, as well as advances in computing and cryptography. These technological developments, along with shifts in our attitudes towards personal data and privacy, mean that we are in a very different world from the one contemplated in the GDPR.

Competing data models

The GDPR assumes a tri-party data model whereby any transaction in personal data has three key parties known as the:

  1. data subject;
  2. controller;
  3. processor.

The “data subject” is an identified or identifiable natural person who is the subject of the personal data. The “controller” is a “natural or legal person which, alone or jointly with others, determines the purposes and means of the processing of personal data.” A “processor” is a “natural or legal person, public authority, agency or other body which processes personal data on behalf of the controller.” One or more parties can act as co-controllers or co-processors in respect of the same personal data. This model sets out a hierarchy whereby the aptly-named controller in fact has the most control over the use of personal data relating to the data subject, as well as over the activities of any data processors acting on its behalf. The data subject is also aptly named in this model because she is indeed very much subjugated to the other parties in the data ecosystem and, in that respect, is anything but self-sovereign.

As noted above, SSI sets out a fundamentally different data model that is flat, decentralized, and peer-to-peer. In the case of Sovrin, the Identity Owner sits at the middle of her data ecosystem and interacts directly with other Sovrin Entities as peers. It is plain to see how this set-up challenges the structural assumptions of the GDPR’s tri-party data model. Moreover, roles in the context of SSI are dynamic. That is to say, the data subject and controller are not fixed or predetermined roles but can only be identified in the context of a single identity-related interaction or transaction. An in-depth analysis of the controller-processor roles and relationships in the context of the blockchain or ledger-based features of SSI will be the subject of a forthcoming post.

For purposes of this post, we assume a prototypical exchange of Credentials whereby an Identity Owner wants to use a Credential that it has obtained from an Issuer to access a service provided by a Verifier. We assume that the Identity Owner already has the Credential in her Wallet and the Verifier has made a request for the information from the Identity Owner (a “Proof Request”). Further, we assume that the Identity Owner who is the subject of the Credential is the data subject, the Verifier requesting it is the controller, and all other parties to the exchange are either processors or sub-processors.

Compatability on key objectives

While the GDPR is almost always characterized as a law aimed at enhancing individual privacy, the GDPR is actually a dual-purpose Regulation. Its first objective is indeed enhanced data protection for natural persons and aims to give natural persons more control over their own personal data. But its second objective, of equal importance, is to enable the free movement of personal data across the EU. While this second objective often gets lost in the conversation, it provides an important lens by which to view the GDPR — namely as an economic bargain or a commerce-enabling tool (the right to data portability is a prime example of this bargain). Specifically, the Regulation is concerned with stimulating economic growth by creating the trust that will allow the digital economy to develop.

SSI, and Sovrin’s approach in particular, is perfectly aligned with both objectives. The primary purpose of SSI is to give individuals control over their identity attributes and the exercise thereof. From the Sovrin point of view, the first test of true SSI is the extent to which identity is, and will always be, under the control of the Identity Owner. A second and important objective of Sovrin’s approach is to enable and expand the exchange of Credentials between Identity Owners and other entities in the data ecosystem in large part by facilitating a high degree of trust. Hallmarks of this approach include the Sovrin Trust Framework and Domain-Specific Trust Frameworks. In this way, Sovrin mirrors the dual purposes of the GDPR. In Part 2, we will dive into an analysis of each of the core data protection principles in GDPR and explain how they are advanced by SSI.


In this part, we have introduced the core concepts of self-sovereign identity (SSI) and the specific example of Sovrin. We then provided an overview of the GDPR and discussed the compatibility of its key objectives with those of SSI.

Continue reading

Part 2 — Key data protection principles. We will first examine how the Sovrin approach to SSI advances the core data protection principles, and secondly, how Sovrin meets the privacy by design and default requirements.

Part 3 — Data subject rights. We’ll look at the rights of individuals under the GDPR and examine how each one is supported by Sovrin’s approach to SSI.


¹ The Sovrin ecosystem is an open source project that is under continual development by the Sovrin Foundation as well as multiple stakeholders in the community. As such, all of the technical and design details described herein are subject to change. For purposes of this analysis, we have taken a snapshot of the ecosystem at time of publication.