Fidelity, Provenance, and Trust

In a recent thread on Twitter, Steve Wilson, Tim Bouma, Josh Geno, and I had a nice discussion about the use of the word "trust" to describe credential exchange.

Steve suggested the words "fidelity" and "provenance". I like those. I wrote the following to use them in describing credential exchange in the SSI Stack. Note that I didn't get rid of the word "trust" completely, but it moved from being a catch-all descriptor to a result.

The SSI Stack
The SSI Stack (click to enlarge)

Verifiable credentials contain claims about attributes. Credential issuers provide credentials containing claims to credential holders who use them to prove things about themselves to credential verifiers. For example, my employer may provide me with an employment credential that I hold and present to my bank when applying for a loan to prove to them that I've been employed three years and have a salary greater than a certain amount.

The identity metasystem (orange box) provides assurances about the fidelity of the credential: the identifier of the issuer and that the credential was issued to the holder who is presenting it, hasn't been tampered with, and hasn't been revoked.

The verifier is also concerned with the credential's provenance: who issued it (not just their identifier) and on what authority they issued it under? Provenance depends on the design of the context-specific identity system (blue box). The verifier may ascertain the provenance of the credential in any way that satisfies them. In some cases, they may know about the issuer directly (e.g. many banks would know about local employers). In other cases, they may rely on things the business can prove about itself (e.g. I can determine if a business is a legally registered entity and other information from credentials they can present such as a business registration credential). Still further, the business may be part of a larger, formal organization that governs how they operate (e.g. an accredited university or a regulated bank).

The fidelity provided by the identity metasystem, combined with the credential provenance provided by the context-specific identity system operating on top of it, provides the basis for trusting the information that the holder has conveyed through credential exchange.

Self Sovereign is Not Self Asserted

passport validation

From time to time, I run across the idea that self-sovereign identity (SSI) systems like Sovrin are necessarily self-asserted. This is the myth: that SSI means that the person gets to say anything they want and the relying party just has to accept it. This is NOT what SSI means.

Sovrin is an identity metsystem based on the exchange of verifiable credentials. The verifiable credential pattern is shown in the figure below.

Verifiable Credential Exchange
Verifiable Credential Exchange (click to enlarge)

There are three parties: the credential issuer, the credential holder (identity owner), and the credential verifier. So, imagine that a company (issuer) has given Alice (holder) an employment credential. Alice can then present information from that credential to her bank (verifier). In this example, the information Alice is presenting to the bank is not self-asserted. Rather, Alice's employer is asserting it.

Why does the bank trust it? They might not. The verifier is free to determine whether or not to trust the credential. In making that determination, there are two kinds of evidence the bank needs. First, the bank needs to trust that the exchange process is secure. Specifically, they are interested in determining that the credential was issued to the presenter, that is hasn't been tampered with, and that it hasn't been revoked. These properties can be validated cryptographically.

Second, they are interested in who issued the credential and whether they trust the issuer. The issuer can be identified in a trustworthy way in the credential. But whether the bank trusts that it's a real employer is not a crypotographic question. They might know the employer through other means or they might need to have the employer prove things about themselves. But either way, they have to have a process for determining whether or not to trust the issuer.

In Sovrin, people hold numerous credentials from a variety of issuers, just like we do in the physical world. They use those credentials to prove things about themselves to relying parties. They may, as part of the interaction, self assert information when that's acceptable to the relying party. But they also have the means of bringing trustworthy evidence from other parties to the interaction. This is not easy to do online using current identity systems. But that changes when when people can use credentials from multiple issuers to prove things about themselves.

Photo Credit: Passport Stamp from Max Pixel (CC0)

Life-Like Identity: Why the Internet Needs an Identity Metasystem

Friends Eating

Imagine you are planning to meet a friend for lunch. You arrive at the restaurant on time and she’s nowhere to be found. You go to the hostess to inquire about the reservation. She tells you that your reservation is correct, and your friend is already there. She escorts you to the table where you greet your friend. You are seated and the hostess leaves you with a menu. Within a few moments, the waitress arrives to take your order. You ask a few questions about different dishes. You both settle on your order and the waitress leaves to communicate with the kitchen. You happily settle in to chat with your friend, while your food is being prepared.

In this scenario, you, your friend, the host, and waitstaff recognized, remembered, and interacted with people, places, and things countless times--that is “identity”. And this happened without anyone being aware that there was an identity system in play.

In the physical world, we effortlessly use identity to enable countless daily interactions. These interactions might be trivial or profound, temporary or permanent. We do this without any intervening administrator, without permission, without significant effort, and usually without much thought.

Identity just works--until you go online. Imagine this same scenario, helpfully curated by digital assistants.

You arrive at the restaurant after installing the FoodFinder app this restaurant uses to allow itself to be located. Of course, you have to create an account and log in. Once you find the place, you don’t see your friend, but then you recall you’re in the Alpha system and she’s Bravo, so you have to install the MeetWithFriends app that works in both. Once you open that app and log in, she is now visible, and you exchange greetings. After several minutes of explanation of the steps that she took to get to the table, you realize that you need to interact with what used to be the hostess station. It’s now a kiosk with a digital tablet. You attempt to sign in, but they’ve recently updated to HappyHostess from their previous system. Unfortunately, HappyHostess doesn’t have the data from the old system, so after you install the app, you are a new customer again and all your dining points have vanished. Oh well. The app gives you on screen directions to your table. After several wrong turns, due to unfamiliarity with the new app, you finally see your friend and can be seated. But you still can’t order or even talk to your friend at the table without logging into the restaurant’s LunchForYou app!

Unfortunately, we aren’t too far from this scenario now. In Alistair MacTaggart’s testimony before the Senate Commerce Committee in October, 2018, he described his experience at the local Super Cuts which required that he register with his email address and cell phone number at a kiosk in order to get a haircut. Frequent air travelers now encounter iPads at the restaurant tables in airports, so their order can go directly to the kitchen without human intervention. Unfortunately, it’s almost impossible to ask questions or have some special request. Your payment details go into the main system to correlate with whatever other information they have about you in order to “serve you better.”

Unfortunately, we are making identification in the offline world more like the complicated and messy digital world. Rather we should be building digital systems that mimic the natural and seamless interactions we have in the physical world.

The Problems with Digital Identity

Digital identity is broken because the Internet was built without an identity layer.

We say this so often it’s become cliché. The idea was made famous by a New Yorker cartoon that says, “On the Internet, nobody knows you’re a dog.”

But the reality is far from funny. The missing identity layer has resulted in a mishmash of one-off identity systems because every web site, service provider, and application has solved the problem in a unique way. As a result, people and organizations who use the Internet are subject to cognitive overload, friction, increased costs, loss of privacy, and even outright fraud.

Fixing the Internet’s identity problem is hard. There have been numerous systems, protocols, and standards proposed over the past 20 years. While most of them have provided improvements and fixed specific problems, none have offered a holistic solution.

To see why digital identity is so hard, let’s explore some specific problems that the online world presents that make identity different from the physical world1.

Proximity - Because we're not interacting with people physically, our traditional means of knowing who we're dealing with are useless. None of the familiar signals of the physical world are present. Consequently, it is difficult to reliably recognize and remember people and organizations online. Organizations have built so-called “administrative” identity systems to serve their own needs in recognizing and remembering their customers, but people don’t have the same capabilities. Consequently, we’re mired in myriad, incompatible systems built for narrow purposes.

Autonomy — Each of these administrative systems is built for the convenience of the organization who controls it. Design choices for these systems are made to maximize the legibility of people to the organization for its purposes. The balance of power is severely skewed toward one party over the other. Consequently, people have very few natural rights and little leverage online. Current online identity systems significatly reduce individual freedom and autonomy.

Privacy — No one will be surprised to learn that computers are very good at pattern matching. But a consequence of this is that online identity has very different implications for privacy than physical-world interactions. When you hand your driver’s license to the bartender to establish your legal age, you would be surprised if she could remember all the detailed information it contains, like your address, and do that for every patron she encountered. Computers, on the other hand retain a perfect memory of all the information they are presented with until they are told to forget.

Anonymity — Anonymity is closely related to privacy. In real life, we do without identity systems for most things. You don't have to identify yourself to the movie theater to watch a movie or log into some system to sit in a restaurant and have a private conversation with friends. Our interactions in the physical world are naturally anonymous. The ticket taker at a movie theater does “identify” you momentarily for purposes and checking your ticket, but that connection is ephemeral and thus anonymous for most purposes. Many online interactions could make use of ephemeral relationships as well in support of better privacy.

Flexibility — Closely related to the autonomy problem is one of flexibility. Current online identity systems are built for very narrow purposes. But real life is messy with billions of use cases. People are innovative and infinitely diverse. None of us presents the same picture of ourselves to everyone and everything—how we recognize, remember, and interact is highly dependent on the context.

Interoperability — A consequence of myriad identity silos is that we are unable to carry context from system to system. Your friend in one system might have a different identifier in another. The means you have for recognizing and remembering varies from system to system.

Scale — There are billions of people online. Each of them has dozens, even hundreds of relationships. The Internet of things promises to increase that by several orders of magnitude. Consequently, a general-purpose identity system needs to account for trillions of relationships between the many billions of people, organizations, and things that make up the online world.

An Identity Metasystem

Solving these problems requires building something more abstract and general than the one-off, context-specific identity systems of the past. The Internet is a monument to abstraction and generality. Rather than being a communications system like the telephone, the Internet is a communications metasystem. That is, the Internet is a system for building communications systems. Every new protocol changes the kinds of messages that the Internet can communicate and thus changes its nature.

Similarly, an identity layer for the Internet must be a metasystem that provides the building blocks and protocols necessary for others to build identity systems that meet the needs of any specific context or domain. An identity metasystem is a prerequisite for an online world where identity is as natural as it is in the physical world. An identity metasystem can remove the friction, decrease cognitive overload, and make online interactions more private and secure.

In 2005, Kim Cameron, Microsoft’s Chief Identity Architect, published the Laws of Identity (PDF), a paper that laid out seven important principles for how digital identity should work. In that paper, Kim describes an identity metasystem—a collection of interoperable identity systems—that can provide the missing identity layer:

...different identity systems must exist in a metasystem. It implies we need a simple encapsulating protocol (a way of agreeing on and transporting things). We also need a way to surface information through a unified user experience that allows individuals and organizations to select appropriate identity providers and features as they go about their daily activities. The universal identity metasystem must not be another monolith. It must be polycentric (federation implies this) and also polymorphic (existing in different forms). This will allow the identity ecology to emerge, evolve and self-organize.

From Kim’s description, we can identify several important features of an identity metasystem:

Encapsulating protocol—Protocols describe the rules for a set of interactions. An encapsulating protocol, then, describes the kinds of interactions that can happen without being overly prescriptive about the nature or content of those interactions. Thus, the encapsulating protocol enables a flexible set of interactions that can be adapted for specific contexts and needs. Protocols are the foundation of interoperability and allow for scale.

Unified user experience—Part of the beauty of natural identity systems is that we don’t have to switch apps or learn an entirely new way of interacting for each context. A unified user experience doesn’t mean a single user interface. Rather the focus is on the experience. As an example, consider an automobile. My grandfather, who died in 1955, could get in a modern car and, with only a little instruction, successfully drive it. Unified user experiences let people know what to expect and so they can intuitively understand how to interact in any given situation regardless of context.

User choice—By allowing people to select appropriate service providers and features, a metasystem allows for autonomy and flexibility. No single system can anticipate all the scenarios that come up as people live their lives. A metasystem allows for context-specific scenarios to be built and even supports ad hoc interactions that no one anticipated.

Modular—An identity metasystem can’t be a single, centralized system with limited pieces and parts. Rather, the metasystem will have interchangeable parts, built and operated by various parties. Protocols and standards enable this. Modularity supports substitutability, a key factor in autonomy and flexibility.

Polycentric—An identity metasystem is decentralized to enable autonomy and flexibility. No single system can anticipate all the various use cases. And no single actor should be allowed to determine who uses the system or for what purposes.

Polymorphic—The information we need to recognize, remember, and interact with various people, organizations, places, and things is context dependent and varies widely with the situation. The content that an identity metasystem carries must be flexible to support these.

The Laws of Identity

Kim follows this description of the metasystem with seven laws of identity that are designed to ensure that the metasystem is sufficiently respectful of autonomy, privacy, and security.

User Control and Consent—Technical identity systems must only reveal information identifying a user with the user’s consent.

Minimal Disclosure for a Constrained Use—The solution which discloses the least amount of identifying information and best limits its use is the most stable long-term solution.

Justifiable Parties—Digital identity systems must be designed so the disclosure of identifying information is limited to parties having a necessary and justifiable place in a given identity relationship.

Directed Identity—A universal identity system must support both “omni-directional” identifiers for use by public entities and “unidirectional” identifiers for use by private entities, thus facilitating discovery while preventing unnecessary release of correlation handles.

Pluralism of Operators and Technologies—A universal identity system must channel and enable the inter-working of multiple identity technologies run by multiple identity providers.

Human Integration—The universal identity metasystem must define the human user to be a component of the distributed system integrated through unambiguous human-machine communication mechanisms offering protection against identity attacks.

Consistent Experience Across Contexts—The unifying identity metasystem must guarantee its users a simple, consistent experience while enabling separation of contexts through multiple operators and technologies.

These laws describe outcomes without prescribing implementation. But they constrain architectural choices to ensure that the universal identity metasystem is not just usable, but also safe and secure.

Architecting a Universal Identity Metasystem

A universal identity metasystem must allow people to not only self-assert information but also bring to bear information that other parties know about them in any identity transaction.

The metasystem architecture has three primary features that allow it to be used as the basis for any context-specific identity system that is needed:

  1. Relationships—the architecture must allow people, organizations, and things to have relationships with each other.

  2. Messaging—the architecture must support messaging between the parties to those relationships.

  3. Trustworthy Attribute Exchange—parties to relationships must be able to reliably exchange information about attributes (often called claims by identity professionals).

The architecture for the identity metasystem supplies these features using layers that build on each other as depicted in Figure 1.

The Sovrin SSI Stack
Figure 1: The Sovrin SSI Stack (click to enlarge)

Relationships are created using a system of peer-to-peer agents in Layer 2. These agents exchange decentralized identifiers (DIDs) to create a relationship2. Because DIDs are cryptographic artifacts tied to public-private key pairs, this exchange provides the agents with the means to perform mutual authentication and create an encrypted channel. Agents use a messaging protocol called DIDComm to exchange messages.

DIDs exist in two forms, public and peer, which correspond to Cameron’s “omnidirectional” and “unidirectional” identifiers in the law on Directed Identity. Public DIDs can be universally resolved to reveal the public key and service endpoint of the owner. Peer DIDs are exchanged between parties to create relationships.

Agents exchange attributes over the channel created in Layer 2 using a flexible, decentralized system of credential exchange illustrated at Layer 3 in Figure 1. In credential exchange there are three parties: the credential issuer, the credential holder (sometimes called the identity owner), and the credential verifier (also known as the relying party).

A credential is a collection of claims (i.e. attributes) that is signed by the issuer and held by the identity owner. Credentials conform to the Verifiable Credential specification. While the word “credential” conjures images of formal documents, almost anything that can be represented in JSON can be attested using a credential. So, while things like passports and driver’s licenses fit this bill, so do things like membership cards, boarding passes, school report cards, invoices, purchase orders, and store receipts.

To see how credential exchange works, suppose Alice (the identity owner) is applying for a loan at her local bank (the credential verifier). The bank requires proof that Alice is employed and makes at least $70,000 per year. As shown in Figure 2, Alice’s employer (the credential issuer) has issued an employment credential that includes her employment status and her current salary. It might also include many other attributes related to Alice’s job. Alice holds the employment credential and can present it to prove to the bank that she is employed and makes more than $70,000.

Verifiable Credential Flow
Figure 2: Verifiable Credential Flow (click to enlarge)

When Alice proves her employment status to the bank, she doesn’t present the entire credential since doing so would reveal more information than is necessary. Instead, Alice presents just the information the bank needs using a cryptographic technique known as “zero knowledge proof.” The ability to limit the information presented from a credential is important to maintain privacy through the principle of minimal disclosure.

Trust and Accountability

For the identity metasystem to be useful, it has to trustworthy. Privacy can't come at the expense of accountability. For the metasystem to be trustworthy, Alice’s bank needs two levels of trust: first it needs to trust the mechanism of credential exchange provided by the metasystem. Specifically, the bank wants to know:

  1. Who issued the credential,

  2. That the credential was issued to Alice,

  3. That the credential hasn’t been tampered with, and

  4. That the credential hasn’t been revoked.

Trust in the metasystem is dependent on the ledger shown in Layer 1 in Figure 1. Alice’s bank can verify these four properties by looking at the credential definition on the ledger, retrieving the public DID and associated DID Document of the issuer from the ledger, and using the public key in the DID Document to check the signature of the credential to ensure it hasn’t been tampered with. The bank can also cryptographically verify that it was issued to Alice. As part of making her proof from the credential, Alice also proves that it has not been revoked by referencing the revocation registry, which is also available on the ledger. And, thanks to the ledger, the bank can do all of this without contacting the employer helping preserve Alice’s privacy.

The second level of trust depends on whether the bank can trust employer. The metasystem cannot supply this second level of trust. The bank wants to know that the identifier in the credential is associated with a legitimate business, the details of that business, and whether Alice really works there. The bank has several options for making these determinations depending on their internal policies. They could use an out of band method to validate the identifier of the issuer by, say, looking up the public DID of the issuer on their web site.

But in many cases, something more formal is required. This level of trust is provided by Layer 4 in Figure 1, context-specific governance and trust frameworks. Businesses, for example, are subject to regulation by the state they are located in. The regulatory framework for how businesses are registered constitutes the governance for a specific trust framework for legal businesses in that context. Figure 3 shows the credential flow from Figure 2 augmented with a governance framework.

Context-specific trust frameworks are numerous and varied. In most cases, they already exist because different domains have already established them for their own purposes. Defining credential schema and use cases, along with creating associated trust frameworks, is how identity systems are created on top of the identity metasystem.

Governance Frameworks in a Credential Flow
Figure 3: Governance Frameworks in a Credential Flow (click to enlarge)

A Universal Trust Framework

Relationships and interactions require trust. All new relationships have a "trust gap" that separates a place of certainty from something that is unknown. Some force has to help us "make the leap" from certainty to uncertainty and that force is trust3.

Traditionally, we've relied on local trust that is based on knowing someone—acquired knowledge or reputation. In a village, I know the participants and can rely on personal knowledge to determine who to trust. As society got larger, we began to rely on institutions to broker trust. Banks, for example, provide institutional trust by brokering transactions—we rely on the bank to transfer trust. For example, I don't need to trust you to take your credit card.

But institutional trust is problematic in the digital age. Trying to use ever-larger institutions to create trusted online interactions is what has gotten us into the current privacy mess, exemplified by security breaches and surveillance capitalism.

The identity metasystem represents a third way—a universal trust framework. A trust framework provides the structure necessary to overcome the trust gap and make the leap from the known to the unknown. Trust frameworks are all around us, but they are one-offs, too specialized to be universally applicable. For example, AirBnB is a trust framework, but the platform can only be used by AirBnB for trust transactions between hosts and guests. We can easily imagine AirBnB (or the next sharing platform) engineering their system to use the identity metasystem instead4.

The identity metasystem represents a universal trust framework because its trust model has five important characteristics:

  1. Credentials are decentralized and contextual—There is no central authority for all credentials. Every party can be an issuer, a holder (identity owner), or a verifier. Verifiable credentials can be adapted to any country, any industry, any community, or any set of trust relationships.

  2. Credential issuers decide on what data is contained in their credentials—Anyone can write credential schemas to the ledger. Anyone can create a credential definition based on any of these schemas.

  3. Verifiers make their own trust decisions about which credentials to accept—There's no central authority who determines what credentials are important or which are used for what purpose. The metasystem supplies the technical underpinnings for cryptographic trust, upon which context-specific trust frameworks can operate.

  4. Credential verifiers don't need to have any specific technical, contractual, or commercial relationship with credential issuers—Verifiers do not need to contact issuers to perform verification.

  5. Credential holders are free to choose which credentials to carry and what information to disclose—People and organizations are in control of the credentials they hold (just as they are with physical credentials) and determine what to share with whom. This is sometimes referred to as self-sovereign identity (SSI).

These characteristics mirror how credentials work in the offline world. Rather than imagining a single identity or a single overarching institution—two models that represent the way digital identity has been done previously—the metasystem flexibly supports autonomy by allowing for as many interoperable trust frameworks as are needed to meet the myriad contexts in which humans find themselves.

Too much of our online (and physical world) interactions have come to rely on what Yuliya Panfil and Christopher Mellon call “monument credentials.” Monument credentials are the foundational documents upon which most of us build our formal identity, things like birth certificates, property titles, and passports. Monument credentials suffer from two primary challenges: access and accuracy.

An identity metasystem can provide an alternative to monument credentials in many situations. Panfil and Mellon call these “tapestry credentials.” Tapestry credentials are built from the data trails that we all leave as we navigate the digital world. these many credentials can provide a tapestry of new evidence that can be trusted for things we’ve relied on monument credentials for in the past. Taken together, they can be more accurate than a single monument credential. And because their based on many small interactions, they are more immediately available to many, especially under-documented populations.

Metasystems accelerate innovation and reduce engineering complexity by providing standard ways of doing things. Thus, universal solutions solve previously intractable problems and make new applications more broadly available. A trust framework with the characteristics listed above changes how we live our digital lives. The Internet changed the world because it provided a universal means of communicating. An identity metasystem changes the world by providing a universal means of trusting.

The real world is messy and unpredictable. Creating an identity system that is flexible enough to support the various ad hoc scenarios that the world presents us with can only be done using a general purpose metasystem. An automobile accident is one such complicated, real-life scenario. Dealing with an automobile accident entails multiple, independent credentials in a complex situation that involves a number of parties and plays out over several days or even weeks. I wrote about the power of an identity metasystem in these kinds of situations in an earlier post.

Solving the Problems

The identity metasystem solves the problems of digital identity discussed earlier. Let's see how:

Proximity—The metasystem solves the proximity problem through two primary mechanisms:

  1. First, DIDs provide the means of reliably identifying the party you are interacting with and the cryptographic means to trust those relationships.

  2. Second, credentials allow trusted third parties to attest to facts about the parties you interact with.

These enable trust to be built up over time and not be lost, the same way it is in the physical world.

Autonomy—Autonomy is at the heart of the metasystem’s architecture. Every party in credential exchange makes their own decisions. Every person and organization controls their relationships (i.e. private keys) and makes independent decisions about who to trust. Furthermore, the underlying protocols and standards allow for choice in tools and platforms.

Privacy—Privacy is the complement of autonomy: there is no privacy without autonomy and no autonomy without privacy. The metasystem incorporates privacy into its architecture through the support of peer DIDs, zero knowledge proofs, and many other features designed to protect people and organizations from unwanted correlations.

Anonymity—The metasystem allows people to retain their anonymity in online interactions. In many relationships, they can remain “nameless” by limiting the data that is disclosed. The metasystem removes the need for a centralized administrative system that can surveil activity. The metasystem also supports ephemeral relationships for short-lived interactions (e.g. with the ticket taker at the movie theater or bartender at the bar).

Flexibility—The metasystem can be used to construct identity systems for any purpose by designing a credential system to address the context-specific issues. The metasystem can be flexibly employed in ad hoc situations to bring credentials to bear from multiple contexts.

Interoperability—The underlying standards and protocols of the metasystem ensure that credential exchange is interoperable across contexts and between independent identity systems. The open-source nature of the reference code base for the metasystem ensures that multiple parties can bring interoperable solutions to market.

Scale—The metasystem scales for individuals through a consistent user experience which reduces cognitive load for people managing digital relationships. The peer-to-peer nature of the agent layer of the metasystem, combined with the widespread use of peer DIDs and decentralized nature of credential exchange, ensures that the metasystem can scale to support the trillions of relationships and credential exchanges necessary to provide an identity layer for the world’s economy.

While Obeying the Law

Simultaneously with solving the problems, the metasystem architecture must obey the laws of identity.

User Control and Consent—People are at the center of credential exchange and make independent choices about what relationships to create and what information to share.

Minimal Disclosure for a Constrained Use—The identity metasystem is designed to support minimal disclosure through zero-knowledge proof so that information is not shared unnecessarily.

Justifiable Parties—Only the credential issuer, holder, and verifier are part of any credential exchange. No third parties, intermediaries, or system administrators have access to the data in the credential or information about how it is shared.

Directed Identity—The metasystem uses public and peer DIDs to provide appropriate direction for identifiers.

Pluralism of Operators and Technologies—The flexibility of credential definitions, the layered architecture, open-source code base, and interoperable protocols make the metasystem flexible and open ensuring multiple solutions from many technology providers can be used.

Human Integration—The metasystem places the human in the loop for determining what relationships to create, how they are maintained, and what credentials to share with who.

Consistent Experience Across Contexts—The primary artifacts of the metasystem are relationships and credentials. Regardless of what specific design is used for the user interface, the experience is consistent because it rests on these artifacts.

Life-Like Digital Identity

We use identity in the physical world without thinking about it. And when we do, there are patterns that are so ingrained in our ways of interacting that we don’t give them a second thought. If we are to move more and more of our lives to the digital realm while also preserving agency and autonomy, we must create a digital world that allows us to jump the trust gap we inevitably have with people, organizations, and things when our interaction is digital.

An identity metasystem provides the long-missing identity layer for the Internet that will allow this to happen. The metasystem can be incorporated into every digital tool and system providing a consistent, trustworthy experience that feels as frictionless and natural as identity in the physical world.

Decentralized, self-sovereign identity depends on an identity metasystem and is the foundation for a decentralized Web—a Web that flexibly supports the kind of ad hoc interactions people have with each other all the time in real life. We'll never get an online world that mirrors real life and feels frictionless and life-like until we do.

Consequently, the arguments for creating the identity metasystem provided by the Sovrin Network are not narrow or technical issues. We are not building it simply for perceived technical benefits. Rather, the identity metasystem is vital for personal autonomy and ultimately human rights. Computers are coming to intermediate every aspect of our lives. Our autonomy and freedom as humans depend on how we architect this digital world. Unless we put digital systems under the control of the individuals they serve without intervening administrative authorities, the Internet will undermine the quality of life it's meant to bolster. The identity metasystem is the foundation for doing that.

End Notes

  1. I wrote about Fixing the Five Problems of Internet Identity in 2017. I've updated the list. Specifically, I think "autonomy" is a superset of "consent" and much more important overall.
  2. Decentralized identifiers are defined in specifications created by the W3C Decentralized Identifier Working Group. More details on decentralized identifiers and how they work can be found in Decentralized Identifiers.
  3. See We've Stopped Trusting Institutions and Started Trusting Strangers by Rachel Botsman
  4. I believe that a universal trust framework will lead to explosion of new sharing economy businesses because the identity metasystem will significantly reduce the plaform costs associated with building them.

Thanks to Joyce Searls, Doc Searls, and Drummond Reed for feedback on an earlier draft of this article.

Photo Credit: Friends Celebration Dinner Table from Pixabay (CC0)

It's the Autonomy, Stupid!


In If you’re not Breaking Rules you’re Doing it Wrong, Simon Morris argues that the primary value proposition of decentralization is enabling the breaking of rules. He says:

The one value proposition that everyone seems to agree on for blockchain technologies is that they are ‘censor-proof’. And this matters only if you have something that someone wants to censor. To my mind the most interesting blockchain projects out there are the ones that enable the breaking of rules.

This article fascinated me and I spent a long time thinking about how this applies to Sovrin.

What bothered me is that Sovrin has made a point of having a strong governance framework that allows organizations around the world to comfortably use Sovrin without having to break rules or go rogue. Indeed, one of the reasons for Sovrin's success has been that we spotlight active governance as one of the important features of using Sovrin and the core reason the Sovrin Foundation exists.

Some might say that's evidence that Sovrin isn't sufficiently decentralized. I've argued strongly that Sovrin is decentralized and that that is one of it's core strengths. We talk a lot about censorship resistance. But we don't talk about breaking rules.

Of course, the reason we worry about censorship resistance is because we don't want any third party to be able to deprive a person or organization of their ability to use Sovrin. We don't talk about who might do that and why. We just work to create a system where they will have to work very hard to do so—hopefully harder than they'd be willing for whatever benefit they'd gain.

But, contrary to what Simon says above, I think that there is another overarching reason for decentralization: autonomy1. Centralized systems reduce individual freedom and autonomy. Craig Burton said

It's about choice: freedom of choice vs. prescribed options.

Leadership shifts. Policies expire. Companies fail. Systems decay.

Give me the freedom of choice to minimize these hazards.

The real value proposition of decentralization is autonomy—not being inside someone else’s administrative system where they make the rules in a one sided way2. Decentralization is closely linked to substitutability, the ability to substitute software and services without loss of functionality. Email is an example of a system that is substitutable. Facebook and Twitter are not. Substitutablity is a key feature of decentralized systems because it enables choice.

Speaking of the Internet of Things, I wrote:

Our autonomy and freedom as humans depends on how we build the Internet of Things. Unless we put these connected things under the control of the individuals they serve without an intervening administrative authority, we will end up building something that undermines the quality of life it's meant to bolster.

This is just as true about identity as it is about the Internet of Things. That's why we call it self-sovereign identity. Decentralization, in the form of an decentralized identity metasystem like Sovrin, allows us to build identity systems without intervening administrative authorities who can arbitrarily and at their sole discretion change the rules. Instead of breaking the rules, autonomy is about avoiding unnecessary rules altogether.

End notes

  1. The title of this post isn't meant to call Simon stupid or insult him. But the play on Bill Clinton's famous line from the 1992 presidential campaign was too good to pass up. Hopefully he'll forgive me.
  2. I think you can make the argument that autonomy and the ability to break rules are related. But like most things in life, there are degrees at play here. I feel like I'm relatively autonomous, but obviously I'm subject to the laws of the country I live in. There's a connection to John Locke's grand bargain here.
Photo Credit: Handcuffs from pxhere (CC0)

Answering Questions about Self-Sovereign Identity

Traverse Ridge

In Self-sovereign identity: 3 key questions (registration required), Susan Morrow asks some questions about the viability of self-sovereign identity (SSI). I actually found more than three. Here's some answers to Susan's questions.

After referencing Kim Cameron's Seven Laws of Identity (PDF), Susan states:

SSI is user-centric, but you don’t need to have a Self Sovereign ID system for it to be user-centric.

That's true. In fact, when we started Internet Identity Workshop, the mission was to explore user-centric identity. But, here's what I've found over the years: being about the user (user centric) doesn't necessarily mean that the user is structurally part of the flow, something Kim made central to his seven laws. I know there are plenty of people who hate the term, but "self sovereign" implies user control in a way that "user centric" does not.

Commercial Use

Susan's first question concerns commercial use cases. She says:

I want to understand how we can fit an identity framework, that is based on presenting verifiable claims, to a service. Who will pay for the verification? If one organization pays, will they be happy if that data is then shared with a competitor to build up a trusted relationship with them?

The simple answer is "the same people who pay for it now." The world is full of things that can be represented as verifiable credentials. A passport, drivers license, and membership cards are all examples of verifiable credentials. Who pays for them now? The person who wants it. An employee ID is another example. Who pays for it now? The employer (who also pays for the I-9 verification, in the US at least, that could also be part of the employee ID). You have a bank statement that could be represented as a verifiable credential. It's backed by an expensive KYC check. Who paid for that? The bank (and ultimately the customer). I could go on, but you get the point. Most of the use cases for verifiable credentials are just digital forms of credentials that have long existed and making them digital doesn't change the business model.

A subtle point that Susan alludes to is that when these credentials become digital, they can be used more widely and the issuer might want a piece of the action. For example, if I use my bank-statement-as-verifiable-credential to prove that I'm real (since only real people get personal bank accounts because of KYC requirements), will the bank want to charge the verifier1? Will banks and others be able to rely on and re-use expensive KYC checks? Rather than seeing this as a problem, I see it as an opportunity. The Sovrin network anticipates use cases where one party in the credential exchange pays another. Sovrin is designed to support them. There are organizations in the Sovrin ecosystem working on these kinds of use cases now.

Bottom line: Sovrin hasn't seen lack of commercial use cases or business models as a problem over the last three years. In fact, just the opposite. There are dozens of commercial use cases and many pilots. One of the reasons I got involved in Sovrin 3.5 years ago was because of the enthusiastic support from the credit union industry. That has not waned. In fact it's gotten stronger. Why? Because SSI solves real problems that credit unions and other businesses have. For the first time since the Internet was invented, we now have a general-purpose protocol for proving things about ourselves based on credentials from third parties.

In kind of a throw-away comment at the end of the section on commercial use, Susan says:

And a last point before I move on. This was brought up by a government official in the UK—the data ownership—is a government verified identity document like a passport actually your data to own?

There's nothing about SSI that implies that people own their passport or other credentials. SSI implies that people hold them and control their use. Just like they do with their physical passport. SSI isn't about ownership and we need to dispel the myth that it is. In On Sovereignty, I say:

The key to sovereignty is that all entities are peers. I have the same rights you do. The beauty of sovereignty isn't complete and total control, but rather balance of power that leads to negotiations about the nature of the relationships between various entities in the system.

Sovereignty implies interactions between peers. Neither party is part of the other's administrative system. Instead, the parties form a relationship (via the exchange of decentralized identifiers) and interact using a common protocol.

Governance and Stewards

Susan labels her next question "This Governance Thing?" but the question is really about the Steward model that Sovrin uses to perform validation on the blockchain. She says:

I can see the positive aspect of [Stewards]. It extends the notion of decentralization to another layer. Good. I do, however, wonder if the steward will become a weak point in the system. Will cybercriminals target stewards to gain control of the nodes?

The Sovrin ledger is operated by known validators who are called Stewards. There are currently over 60 Sovrin Stewards who are located on six continents around the world. The Sovrin Governance Framework contains the requirements for operating a node and the agreements that the Stewards sign.

The ledger is an instance of Indy Plenum which implements a Redundant Byzantine Fault Tolerance (RBFT) algorithm. The details are important because they contain the answers to Susan's question. Plenum is a 3f+1 RBFT system. The implication of this is that an attacker would have to compromise f+1 nodes to stop consensus and write progress and 2f+1 nodes to change what constitutes valid transactions.

So, making the math easy, assume there are 22 Stewards validating transactions on the mainnet. That makes f equal to 7. To stop writes to the ledger, you would have to compromise 8 Stewards. To change a valid transaction, you'd need to compromise 15 Stewards. That means you can't just hack one Steward to successfully attack the ledger as a whole.

Still, if a hacker took over one node, they could potentially send back bad answers to queries that are different from what's on the ledger. Clients have several defenses against that. First, clients can send a ledger query to more than one node. Second, and better, clients can ask for a state proof of ledger state. State proofs can be used to check the answers from a node and are signed by 2f+1 nodes. Consequently, answers can have RBFT built in, allowing clients to easily check the validity of the answer.

In any computer system, there are opportunities for security issues. Sovrin employs algorithms, code, and governance to make the ledger as secure as possible.


Susan's third question involves the reality of the privacy claims of Sovrin. She says:

It is all well and good having minimal disclosure. But what if you want to buy a pair of shoes online. You have to allow the online vendor to know your address to send the shoes to. They will likely also want your name and other demographic data if they can get consent, for marketing purposes. Your data is then outside the SSI and held in a more traditional manner. is now outside of your control too.

Susan is right. Minimal disclosure and zero knowledge proof can't keep companies from asking for too much information or storing that data in their systems. That's a human problem, not a technical one. Fortunately things like GDPR are starting to change the conversation on this.

Frankly, I'm not sure what point Susan is trying to make on this. Should we just give up? It's hopeless? I don't think so. What Sovrin's minimal disclosure does do is show that it's possible to limit information. Sovrin gives companies the means to ask for and use less data. I don't have to share my entire bank statement to prove that I have a bank account. And companies who don't want to handle my entire bank statement don't have to. Companies can no longer claim there's no choice. There is a choice and we can demonstrate that it works.

Zero knowledge proofs also allow credentials to be richer without compromising too much data. Here's an example: my employee ID credential could have lots of information (attributes) in it about not only my current role, but also all my past positions, salary history, and benefits. But I can choose to share only part of it to answer a specific request. I may prove to the bank that I've been employed greater than 3 years for a loan and then prove to the change control system that I'm authorized to deploy updates to the HR system—all from one credential. This makes it more flexible for the identity owner and easier to produce for the issuer since they don't have to create multiple credentials for the same person.

One more point: Sovrin's privacy stance is based on more than zero-knowledge proofs. It also relies on peer-to-peer relationships without correlating identifiers. This makes it harder for third parties to correlate information about me without my consent. Again, it doesn't make it impossible, but making it harder and showing that we can make working identity systems without a universal ID is a big improvement over where we've been, even with systems like social login.

As an aside, the ecommerce vendor doesn't actually have to have your address. They have to know what sales tax jurisdiction you live in (at least in the US) and they have to have a unique handle that the shipping company can turn into an address for delivery. You can imagine an ecommerce company that keeps no payment or address information on customers, but is still able to process their orders and send the merchandise. A universal protocol for exchanging verifiable credentials would be a foundation for this.

An Air of PGP to It

Finally, Susan says:

I get the same ‘techie’ feel of PGP within the SSI movement. I know that folks in SSI are working hard to get neat apps together to help with usability, but still, there is an air of PGP about it.

The best answer to this concern is to invite you to use a Sovrin wallet. Download Evernym's from the app store and visit their demo site2. You won't see any keys. You won't see cryptocurrency addresses. You'll see relationships and credentials. Those are pretty common artifacts that almost any adult will have no problem understanding. Nothing could be further from the PGP user experience.

If you're an identity professional and trying to understand how it all works underneath the covers, you're going to see DIDs, credentials, public keys, zero-knowledge proofs, and all other kinds of technology. But none of that need be exposed to identity owners and it isn't.

A consistent user experience is, in Kim Cameron's view, a fundamental feature of an identity metasystem. That doesn't mean a single user interface—there will be multiple wallets. But the experience will be similar no matter which wallet you use.


Susan concludes:

SSI is not the only way to skin a cat. My own view is that a mix of technologies will, at least for the foreseeable future, be needed to accommodate the vast array of needs across the identity ecosystem. I can see use cases for SSI. But will it become the overarching way that humans resolve themselves in a digital realm?

While it may not be the only way to skin a cat, it's the only way that is universal. Other identity systems and protocols will continue to exist and interface to the identity metasystem. In an analogy, the Internet didn't do away with local area networks, but it connected them up and provided a universal protocol for exchanging messages between those networks. Sovrin will similarly impact and change existing, disconnected identity systems.

But it's bigger than just connecting systems that already exist. My argument is that Sovrin is an identity metasystem that serves as a foundation to support building any domain-specific identity system. Untold numbers of physical credentials can now be made digital—something that goes well beyond just connecting existing identity systems. The Sovrin identity metasystem gives rise to a universal trust framework that will impact almost every aspect of digital life. Yeah, I'm that bullish.

End notes

  1. See my recent blog post for a primer on verifiable credentials that defines terms and describes how they work.
  2. By the way, I point to Evernym's wallet simply because it has a nice credential demo they've created for it and it's the first to be commercially available. I'm aware of at least three other wallets in beta, including the wallet I wrote about in DID Messaging: A Batphone for Everyone. For more on the continually developing ecosystem of Sovrin, see Self-Sovereign Identity at IIW: We Have Liftoff.

No on Universal Patient ID


Last week the House slipped a provision into the budget bill that would lift the funding ban on exploring a universal patient identifier. The ban is known as the Foster-Kelly amendment. If approved by the Senate, exploration of a universal patient identifier (UPI) could begin in earnest.

I strongly oppose the UPI or universal identifiers of any sort. While healthcare IT professionals may wish for a single identifier to make correlating information easier, I don't know many identity professionals who would advocate universal identifiers.

We have other examples of universal identifiers like Social Security Numbers and even cell phone numbers. Your email address is another universal identifier. The problem with universal identifiers is twofold: First, they are indiscriminate; they don't care who's using them to correlate information about a person. The bad guys, scammers, and surveillers can use them just as easily as the doctors and hospitals. Second, computers make correlating information based on a universal identifier far too easy.

As a result, universal identifiers are a threat to privacy and personal security. No matter what safeguards you put in place, creating a universal identifier scheme like a UPI is going to cause harm to people. Universal identifiers are a 20th Century solution that has no business being used in the 21st Century.

The good news is there's usually no need to create universal identifiers. Use cases for a UPI can be supported without a universal identifier thanks to advances in cryptography and its application. Self-sovereign identity (SSI) provides a model for how to put people at the center of their healthcare and allow them to correlate data where desirable without exposing their records to unwanted correlation by third parties. Hyperledger Indy and Aries are open source projects that support SSI. Sovrin is a project that makes it real and usable.

Ironically, just as we are able to create interoperability and provide patient safety without using a UPI, it's finally moving forward. Instead of creating new privacy and security problems for Americans, I implore the US Senate to earmark funds for exploring how to use SSI to solve the healthcare records problem.

Photo Credit: Patient from PxHere (CC0)

Thoughts on Libra


Yesterday, after months of speculation, Facebook announced Libra, a cryptocurrency with the mission of enabling a simple global currency and financial infrastructure that empowers billions of people.

That's a worthy goal. But, as you'd expect with almost anything Facebook does these days, there was a lot of reaction ranging from skepticism to outright opposition.

As Chair of the Sovrin Foundation, I've had a lot of people ask my opinion on Libra.


One thing that I like about Libra is that it's not just a Facebook coin, which is what I had imagined when I first heard about it. Rather, Libra is a Swiss-based organization and Facebook is just one of (eventually) 100 members. Voting in Libra is stake-based, so that doesn't necessarily mean Facebook will just have 1% of the voting power. They could have much more depending on their stake.

An independent, multilateral governing organization is a good design choice. I have no evidence that Sovrin Foundation served as a model in any way, but that choice is aligned with the governance model we've pioneered with the Sovrin Governance Framework.

That said, there's a big difference in the governing model of Libra and Sovrin. Libra is very clearly an industry association. The governance is controlled by the organizations who stake it and these organizations will be making decisions about how Libra operates based on what's good for them. Sovrin Foundation, on the other hand, is NOT an industry association because we want Sovrin to support Identity for All, rather than identity in the service of a few large companies.


Facebook will play a big role in the success of Libra. With 1.7 billion users, they can incorporate Libra into their apps and make it useful for payments on Facebook, Instagram, WhatsApp, and beyond. They won't need exchanges—they are their own exchange. Libra can become useful for lots of people very quickly as a medium of exchange inside Facebook's ecosystem. That ignores a lot of other use cases outside of Facebook, but clearly this is a Facebook play and their user base is a large reason others have joined in.

That kind of reach will be huge for cryptocurrencies in general because it will get people used to the idea of using crypto. When lots of people have Libra coins, other utility tokens will be incentivized to build in support for exchanging Libra for their tokens. Libra could become a common currency for various projects.

And we can't ignore the validation this gives to the idea of tokens in general. As Erik Voorhees said on Twitter: "Zoom out for a second and realize how far this industry has come. The biggest companies in the world are now launching cryptocurrencies. BOOM." Crypto is now mainstream.


The Libra Whitepaper includes this paragraph:

An additional goal of the association is to develop and promote an open identity standard. We believe that decentralized and portable digital identity is a prerequisite to financial inclusion and competition.

That's all it says, so it's hard to know what exactly it means. The first question in my mind is what do they mean when they say "identity"? Are they thinking in traditional digital identity terms where identity is mostly about authentication and maybe KYC around a small set of attributes? They give no clues that they are considering anything beyond that. I hope they're not thinking of tying Libra addresses to some correlatable identifier since that will be a privacy nightmare.

Second, there's already a number of open identity standards. They don't say why they think they need to develop another one. Of course, the common mindset among most corporate types is that identity is a silo that you build yourself, so it may be nothing more considered than the default view.

Third, portable, digital identity exists now in Sovrin. There's no reason, of course, that Sovrin's identity metasystem can't serve as the basis for identity in Libra. And there are many reasons why it should. Sovrin provides a flexible, open, and public metasystem that can easily serve as the foundation for the identity services a system like Libra would need to support financial inclusion without surveillance. Financial inclusion shouldn't come at the cost of privacy.


Of course, this is just the announcement. The launch isn't for another year and lots will change as Libra moves from the drawing board to reality.

Overall, I see Libra as a good development. One that will push the crypto space forward and drive adoption. Rather than destroying other cryptocurrencies and tokens, Libra augments them and validates them. Every coin or token has to live or die on the basis of its utility and Libra doesn't change that. The world needs multiple tokens because they represent the means of exchange in a particular network and provide market incentives in the context of that network. Libra is a big step toward a world where market-driven networks are the norm. That's a good thing.

Photo Credit: Libra Digital from Public Domain Pictures (CC0)

DID Messaging: A Batphone for Everyone


In my last post, I wrote about a demo given by BCGov, Spark NZ, and Streetcred ID at the last Internet Identity Workshop. That demo caused a lot of people to download and try out Streetcred ID's digital wallet. One of the features that Streetcred ID built into their wallet was peer-to-peer messaging based on DID Messaging and that led to some interesting insights.

A Brief Primer on DIDs

If you're not familiar with DIDs, take a minute to go read my article on Decentralized Identifiers from earlier this year. I'll summarize the relevant parts here:

  • DIDs are a new type of cryptographic identifier that are resolvable, non-reassignable, and decentralized (not under the control of a single authority).
  • DIDs have at least one associated public/private key pair.
  • The public key(s) and endpoints associated with a DID can be retrieved by resolving the DID and getting them from the resulting DID Document.

DIDs are inexpensive to create, so best practice is to create a new DID for every one with whom you create a digital relationship. The exchange of these so-called "peer DIDs" thus creates a mutually-authenticated relationship between the participants, where each can use the public key associated with the other's DID to authenticate them.

The wide use of peer DID exchange creates a network of peer-to-peer relationships that are not only mutually authenticated, but can exchange encrypted messages with each other. This capability requires the use of a DID Messaging protocol like the one found in the open-source Hyperledger Aries codebase1 that forms the basis for peer-to-peer interactions in the Sovrin network. The software that exchanges these messages for each party is called an "agent".

DID Messaging

As I mentioned, the Streetcred ID digital wallet supports peer-to-peer messaging through Sovrin P2P agents. This is something any wallet based on Aries and Sovrin could do, but as far as I know, Streetcred ID's wallet is the first to explore this capability.

After IIW, a friend of mine, Tim Bouma, was talking about the P2P messaging in the Streetcred wallet. He hadn't been at IIW, but I opened my wallet and created an invitation for Tim and sent it to him in a Twitter DM.

Creating a DID Invitation
Creating a DID Invitation in Streetcred ID's Digital Wallet (click to enlarge)

Tim accepted the invitation, but how could I be sure it was him--that Malory hadn't intercepted the invitation I sent Tim and inserted himself in the middle of the communication? Fortunately the wallet had a solution. I was able to ask Tim to prove things about himself based on credentials he had in his wallet.

Verifying the Relationship
Verifying the Relationship using an Email Credential (click to enlarge)

Once Tim has proven his email address to me from a credential, I was more sure I was really connected to Tim. For a higher value exchange, I could have asked for other information from Tim until I was sure that it was really him on the other end. With that, we were able to exchange messages. The software took care of encrypting our communication and ensuring that my discussion with Tim was both protected and to him alone.

Messaging in the Streetcred ID digital wallet
Messaging in the Streetcred ID Digital Wallet (click to enlarge)

The Batphone

After this exchange, Vic Cooper likened DID-based P2P messaging to the Batphone. When Batman picks up the Batphone to talk with Commissioner Gordon, Commissioner Gordon doesn't start off the conversation with "Who am I speaking to?", "Can you give me your account number?", "What's your date of birth?", or "What street did you live on in Junior High?" When Commissioner Gordon picks up the Batphone, he knows it's Batman on the other end. Only Batman can call on the Batphone.

So DID Messaging is like having a Batphone for every digital relationship you have. You and they know they're communicating with the right party2. All the messages are protected from eavesdroppers.

DID Messaging could revolutionize how we talk to each other and how we communicate with businesses.

  • We no longer have to rely on a correlatable identifier like an email or phone number, to identify the other party.
  • We no longer have to use centralized systems to talk to other parties with the attendant risk of the system being down or the conversation not being private.
  • We save time and money using frictionless communications with companies we need to work with. We might even get better service.
  • We can verify who's at the other end by asking them to prove things to us.
  • We can sever one relationship without affecting others since everyone has a different identifier for us.

DID Messaging is the foundation for verifiable credential exchange, but is more general purpose and can be used to reliably and securely exchange messages with anyone else who has a digital wallet that supports DIDs3.


  1. The Aries project was recently split off from the Hyperledger Indy project.
  2. If you're concerned about losing your phone and having all those relationships exposed, see What If I Lose My Phone.
  3. Not all digital wallets currently expose the DID messaging functionality, but any that do will be compatible with each other.

Self-Sovereign Identity at IIW: We Have Liftoff

Liftoff of the SpaceX Falcon 9 rocket carrying NASA's TESS spacecraft.

Last week was the 28th semi-annual Internet Identity Workshop (IIW). There were 129 session conducted by people from all over the world and about many different aspects of identity. There were technical discussions, standards works, policy debates, and lots of demonstrations. I'll post a link to the Book of Proceedings when it's available so you can read about them yourself.1

One thing that stood out to me is the impact self-sovereign identity is having. There were several dozen sessions on SSI. I was excited to see seven different implementations of Indy Agents that were working together and combined to create several demonstrations of credential exchange.

  • Evernym and Onfido did a demonstration of the wallet and the Onfido identity verification service. You can do it too. Download the app to you phone and then in the "Menu" select the Onfido item and start getting a real, live, production identity verification based on an existing identity credential such as a passport or drivers license. Once you do, you'll have a connection to and credential from Onfido.

    You can also go to and walk through a demonstration of how credential exchange can work, using actual (though not real) credentials in your wallet

  • Vonx (BC Gov), StreetCred, and Spark NZ showed a demonstration using a StreetCred wallet to connect to and get credentials from two different services: a Vonx email verification service and an IIW attendee verification service. Once attendees had both of those credentials, they could use them to unlock a box that Spark had built and brought to the workshop.

  • IDRamp showed a demonstration of their product that can add credentials to any system that speaks SAML. They were demonstrating using a wallet to present a credential to log into Slack and Rocketchat. This is a production service that can credentialize any SAML service.

  • Pico Labs, my lab at BYU, demonstrated picos that acted as Hyperledger Indy agents and were able to connect to each other as well as other Indy agents like the AgentBook demo from Vonx. Picos are designed to act as digital twins or device shadows for the Internet of Things (IoT). Having agent-enabled secure messaging and credential exchange could be very useful for IoT products.

What got me excited about these demonstrations was that there were seven different organizations interoperably working in an ecosystem for credential exchange. While the rely on common libraries like Hyperledger Indy, they are separate code bases from different development teams that work together. This is a big development in the world of self-sovereign identity, demonstrating the reality of data exchange that is credential-based, secure, and private.


  1. You can read the proceedings of past Internet Identity Workshops on the IIW website.

Photo Credit: Liftoff of the SpaceX Falcon 9 rocket carrying NASA's TESS spacecraft. from NASA TV (CC0)

Decentralized Identifiers

Key and Label

Decentralized identifiers are one of several foundational technologies for building a metasystem for self-sovereign identity. I wrote about verifiable credentials and their exchange previously. Just like the Web required not only URLs, but also a specification for web page formats and how web pages could be formatted, self-sovereign identity needs DIDs, a protocol for creating DID-based relationships, and a specification and protocol for verifiable credential exchange.

Identifiers label things. Computer systems are full of identifiers. Variable names are identifiers. Usernames are identifiers. Filenames are identifiers. IP numbers are identifiers. Domain names are identifiers. Email addresses are identifiers. URLs are identifiers.1 Any time we use a unique (within some context) string to label something for quick reference, we're giving it an identifier. A computer system uses identifiers to correlate all the information it knows about a given thing. The mis-use of identifiers can lead to unwanted, even dangerous correlations.

Identifiers need context to be meaningful. For example, a string of digits might be a phone number, but we have no way of knowing for sure without context. Online context is often provided by a prefix. For example, is an email address, but is an account identifier.

Web-based identity systems have largely defaulted to using email addresses as identifiers. Everyone has one. And someone else has done the work of ensuring uniqueness since email addresses must be globally unique. But email addresses are also less than ideal as identifiers for several reasons:

  1. First, email addresses have a real, intended use (sending email) and so might change for reasons unrelated to their use as an identifier.
  2. Second, email addresses are generally correlatable. If you use the same email address for all your account identifiers, it's easy to track your activity at all those different places.
  3. Third, email addresses are generally administered by someone else who can take them away. Even if you use your own domain name, you're just renting that and may give up control in the future.
  4. Fourth, email addresses have limited global resolvability. All you can do is send an email message to the owner.
  5. Lastly, email addresses are reusable. If you stop using an email address the administrator of the email system may reassign it, decreasing security and privacy.

Decentralized Identifiers

Decentralized Identifiers, or DIDs, are a new kind of identifier that solves the problems outlined in the last section. As noted above, DIDs are one of the foundational technologies of self-sovereign identity. The DIDs specification is being developed inside the W3C Credentials Community Group. Let's explore the properties of DIDs and look at how they are formatted.

DID Properties

Decentralized identifiers should be implemented so that they have these important properties:

  • non-reassignable—DIDs should be permanent, persistent, and non-reassignable. Permanence ensures that the identifier always references the same entity. As a result, DIDs are more private and more secure than identifiers that can be reassigned such as a domain name, IP address, email address, or mobile number. Permanence is vital for user control and self sovereignty.
  • resolvable—DIDs are made useful through resolution. Resolution ensures that a DID is actionable. We'll discuss how DID resolution works in more detail below.
  • cryptographically verifiable—DIDs are designed to be associated with cryptographic keys and the entity controlling the DID can use those keys to prove ownership. That can happen in several ways. The result of resolving a DID may be cryptographically signed to ensure its integrity. The resolution also provides one or more public keys associated with the DID. Using cryptographic keys, the owner can prove they are in control of the DID. Parties who have exchanged DIDs can mutually authenticate each other and encrypt their communication.
  • decentralized— DIDs are designed to function without a central registration authority. Depending on the DID method specification for a given class of DIDs, they might also be created and updated outside the purview of any single party or entity, increasing censorship resistance.

DID Syntax

The syntax of a DID is fairly simple and designed to support different decentralization methods. The following diagram shows the primary, required components of a DID:

DID Syntax
DID Syntax (click to enlarge)

Each component is separated by a colon. The scheme, did, is fixed for all DIDs and alerts software seeing the DID that it is a DID. The method specifies how the DID is created, updated, and resolved. In the preceding figure, the method is sov. The method-specific identifier is an alphanumeric string that is guaranteed to be unique within the context of the method.

DID Resolution

Useful identifiers have a means of discovering what the identifier means. Discovery is performed in the manner outlined in the DID method. The DID specification outlines the necessary operations any method must implement. Different methods can support their own way of performing resolution using a specific blockchain or other storage system. The method outlines the way to create, retrieve, and update the DID and it's associate DID Document. For example, the did:sov method outlines how to create, lookup, and update the DID on the Sovrin ledger. A resolver can use the method to find the routines necessary for interacting with a given identifier. Methods allow a variety of systems to serve as repositories for DIDs.

DIDs are resolved to a DID Document. Resolution is the act of looking up the DID Document for a specific DID using the method given by the DID's method component. Taken as a whole, DID infrastructure functions as a global, decentralized key-value store where DIDs act as the keys and DID Documents are the values.

While the expectation is that these repositories will be decentralized, there's nothing in the specification that forces that. Any storage system could potentially have a DID method associated with it. Beware that some repositories may not be able to fulfill the non-reuse and permanence properties that are expected of DIDs.

DID Documents

DID Documents describe the public keys, authentication protocols, and service endpoints necessary to initiate trustworthy interactions with the identified entity. A DID Document is a JSON-LD document that contain the following six, optional components:

  1. The DID that points to the DID Document, identified by the key id.
  2. A list of public keys identified by the key publicKey.
  3. Lists of protocols for authenticating control of the DID and delegated capabilities identified by the key authentication.
  4. A set of service endpoints, usually URLs, that allow discovery of way to interact with the entity that the DID identifies identified by the key service.
  5. Timestamp indicating when the DID Document was created and updated for auditing the DID Document identified, respectively, by the keys created and updated.
  6. A digital signature for verifying the integrity of the DID Document identified by the key proof.

DID Documents can use other JSON-LD contexts to extend the DID Document and aid in discovery. For example, the data model could be extended to include the entity's RSS feed by referencing a JSON-LD context that describes RSS feeds.

The following is an example of a minimal DID Document taken from the DID specification2:

  "@context": "",
  "id": "did:sov:123456789abcdefghij",
  "publicKey": [{
    "id": "did:sov:123456789abcdefghij#keys-1",
    "type": "RsaVerificationKey2018",
    "controller": "did:sov:123456789abcdefghij",
    "publicKeyPem": "-----BEGIN PUBLIC KEY...END PUBLIC KEY-----\r\n"
  "authentication": [{
    "type": "RsaSignatureAuthentication2018",
    "publicKey": "did:sov:123456789abcdefghi#keys-1"
  "service": [{
    "id": "did:sov:123456789abcdefghij;exam_svc",
    "type": "ExampleService",
    "serviceEndpoint": ""
  "created": "2018-02-08T16:03:00Z",
  "proof": {
    "type": "LinkedDataSignature2015",
    "created": "2018-02-08T16:02:20Z",
    "creator": "did:sov:8uQhQMGzWxR8vw5P3UWH1ja#keys-1",
    "signatureValue": "QNB13Y7Q9...1tzjn4w=="

The DID Document is the root record for a decentralized identifier that can reference not only what's in the DID Document itself, but also any information from the service endpoints. This is accomplished by adding selectors, paths, query parameters, and fragments to the DID. With the exception of selectors, which are specific to DIDs, the syntax of these is familiar to anyone acquainted with the syntax of a URI.

The selector is used to identify a particular part of the DID Document. Selectors follow the DID itself and are delineated with a semicolon. In the preceding DID Document, there is only one service. Nevertheless, it can be selected using the following DID:


If the DID also includes a path, that is appended to the URL given in the service's serviceEndpoint attribute before the endpoint is called. For example, the following DID:


is equivalent to the following URL (based on the preceding example DID Document):

Through this mechanism, DIDs provide a permanent, resolvable identifier for any Internet service. For example, If one of the service endpoints in my DID Document is for email, then I can change my email address at will and anyone holding that DID will still be able to reach me. All I need to do is to be sure to update the DID Document when I change my email.

Public and Peer DIDs

The preceding use case—putting my email in a DID Document—might be a privacy problem if I don't want my email to be publicly readable. Fortunately, not all DIDs are public. Identifiers can be, in the language of Kim Cameron (PDF), omnidirectional or unidirectional. Kim says in reference to his fourth law, Directed Identity:

A universal identity system must support both “omnidirectional” identifiers for use by public entities and “unidirectional” identifiers for use by private entities, thus facilitating discovery while preventing unnecessary release of correlation handles.

Sovrin supports public DIDs, written to the ledger and resolvable by all—omnidirectional identifiers. Sovrin also supports peer DIDs, exchanged between parties to a relationship and resolvable only within that relationship—unidirectional identifiers.

The availability of peer DIDs has significant advantages. Practically speaking, peer DIDs allow for greater scalability of the DID resolution infrastructure since the vast majority of DIDs are private and those are resolved on a peer-to-peer basis rather than through access to some shared piece of infrastructure such as a distributed ledger.

More importantly, as Kim says about directed identity, peer DIDs reduce access to correlatable identifiers by third parties increasing privacy protections. Peer DIDs are critical infrastructure for a key part of the Sovrin architecture: peer relationships.

Peer Relationships

In On Sovereignty, I write:

The key to sovereignty is that all entities are peers. I have the same rights you do. The beauty of sovereignty isn't complete and total control, but rather balance of power that leads to negotiations about the nature of the relationships between various entities in the system.

In a world of identity systems based on decentralized identifiers, people do not create accounts at online service providers and then merely exist within that administrative system. Rather, people create relationships with other online entities and relate as peers.

To see how this works, imagine that you have recently been hired at a new job. Your new employer, ACME Corp, has a public DID that they use for issuing verifiable credentials. But as part of your employee onboarding, they and you will each create and exchange peer DIDs. Because DIDs are cryptographically verifiable, you now each have a secure, channel to the other. You can use these DIDs to mutually authenticate when a connection is established, and to encrypt your communications.

This DID-based peer relationship is based on software agents that act for each party, maintain DIDs, resolve them, and facilitate cryptographically secure communication. The connection is truly peer-to-peer without some other platform in the middle. Apps and services built on top of these peer relationships can use these secure communication channels without being party to the private keys that secure them and ensure their integrity.

Since a DID Doc is JSON-LD and can be extended with other contexts, it can be extended to include other information. For example, you could extend the DID Document you share with your employer to include your home address and bank account information. Whenever those change, you'd update that DID Document and your employer would automatically see the changes.

Since the DID with selectors, fragments, and paths provides a way to resolve this information at will, the employer could merely store DIDs for that information rather than the information itself and resolve it at the local agent each time it is needed. Anyone breaking into their systems and stealing the reference wouldn't have permission to resolve the reference and get sensitive information. This provides the means for an employee, say, to share information with an employer that can be trusted and resolved at will without the employee having to issue a verifiable credential.

DIDs and the Identity Metasystem

In The Laws of Identity, I make the case for Sovrin being an identity metasystem—a universal foundation upon which other identity systems can be built. DIDs and DID Documents are a big part of the metasystem. Sovrin is designed to support the use of DIDs and DID Documents. Furthermore, Sovrin agents manage DID-based peer relationships, verifiable credential exchange, public and peer DID resolution, and DID-based secure communication and authentication. DIDs allow Sovrin to be used by multiple parties for their own purposes.

Online Sovereignty

Decentralized identifiers and the attendant infrastructure that supports them provide a significant improvement over the ad hoc, email, and domain name based personal identifiers we've used for identity systems in the past. DIDs represent a universal addressing, abstraction, and verification layer for key pairs, endpoints, and any other information we wish to include in the DID Document. Layer verifiable credential exchange on top of this for multi-source identity and this constitutes a significant upgrade to online identity.

Because there's no central authority controlling DIDs and because people can issue peer DIDs themselves, they constitute a truly decentralized means of not only creating identifiers, but using them for mutual authentication, privacy preservation, and secure communication of almost any information parties need to share.

Speaking of DIDs, DID Documents, and Verifiable Credentials in an email to Project VRM mailing list, Joe Andrieu, put it like this:

The win is that these new technologies let us engage in digital society with identifiers we create and control--rather than those gifted or rented to us from a third party. Combined with an open system of verifiable attributes, we can also control the selective disclosure of certain "provable" assertions (provable in the sense that some entity like the DMV stands behind the assertion). Collectively, the identifiers and attributes constitute a full and verifiable identity in the common sense we imagine. For the first time, we can come to the party as a peer of the realm instead of a serf.

An identity metasystem that can provide real peer relationships is critical to protecting individual privacy, creating real security, and, more importantly, supporting human dignity. DIDs are a key part of the architecture.


  1. All of these may be other things as well like addresses or names, but they're still identifiers.
  2. I've modified this DID Document slightly to support the examples I want to make.

Photo Credit: Grey Color Keychain Mat Metal Key Shiny from Unknown (CC0 Public Domain)