The Impact of a Network of Networks on Censorship


SSI credentials are anchored on a distributed ledger. Sovrin Network is based on Hyperledger Indy. In Indy, the credential definition, a public DID, schema, and revocation registry are all stored on the ledger1.

On a purely technical level, because of how credential proofs and DID resolution works, it doesn't really matter which ledger these artifacts are anchored on since if I prove something to you from a credential I hold, then you can use the information in the credential proof to find its definition, schema, the DID of the issuer, and so on. Regardless of where the credential is anchored, the verifier can get everything they need to cryptographically determine the fidelity of the credential.

But, knowing whether to trust the issuer of the credential and the ledger the credential is anchored on is more difficult. This is a matter of provenance and is more about governance than the technical features of the protocols and software.

As a result, we can imagine a world where many ledgers serve as anchors for the credential definitions and the other artifacts necessary for credential exchange to be trusted. In Sovrin, this idea is called "Network of Networks" and it has many proponents. We might have questions about which of those ledgers to trust, but that's the subject of a different post and I think the answer lies in governance frameworks. The issue I want to address in this post is what is the impact of Network of Networks architecture on censorship resistance.


Censorship is the ability of one party to stop another from "speaking." I put that in quotes because I'm using the term "speak" in a very general sense. Speaking, on the Internet, is any activity which results in a packet being transmitted from one machine to another on someone's behalf. So, sending an email is speaking, but so is a simple ping, or even a ACK in a TCP three-way handshake.

In the world of credential exchange, you can censor issuers by restricting who can get a DID or write a credential definition. This is why supporting public writes is important. But you can also censor them by not allowing credential holders and verifiers to see the definitions they've written2.

I have found that when people talk about censorship resistance, the discussion often rests on the decentralized nature of distributed ledgers. This happens because decentralization offers good protection against some censoring activities, along with other benefits for adoption and incentives. For censorship, decentralization can remove intermediaries. In any system with intermediaries, the intermediary can censor anyone connecting through them.

A decentralized architecture reduces dependence on someone else to speak, and so is more resistant to censorship. Decentralization can also help with censorship by ensuring access to the ledger and that no single entity can disrupt the validation of new entries on the ledger. But decentralization alone isn't enough to create a network that resists censorship. Censorship resistance depends on how the decentralization is employed.

For an example of why this is so, let's talk for a minute about another feature that distributed ledgers are made to solve, the so-called double spend problem where a digital token is used more than once. Paradoxically, the way ledgers solve the double spend problem is to create a single ledger that everyone agrees on through eventual consistency. So, the users and validators on the ledger may be decentralized, but they are relying on a single, centralized artifact, the ledger.

A Network of Networks

I spoke of the network of networks model above. To understand that better, let's look at the Sovrin SSI Stack. This figure is modified from one's I've shared before in that layer one contains more than one DID directory (my name for the combination of a DID method and a DID repository like a ledger).

The Sovrin SSI Stack
The Sovrin SSI Stack (click to enlarge)

As I've said, the nature of DID resolution lets any agent at layer two resolve a DID, regardless of which DID Directory it is stored in. A Sovrin agent, based on Hyperledger Aries also uses the DID directory to discover credential definitions, schema, and revocation registries. Ideally, these DID directories are public utilities that are, at least, readable by anyone.

Anyone can use the open-source Indy code to create a fully functional DID directory. And people will, for reasons good and bad. As a consequence, there is not a single, shared ledger where credentials and public DIDs are anchored, but many.


If we filter this all through the lens of decentralization as an unalloyed good, then a network of networks seems like a wonderful idea. The logic is inescapable: more networks == more decentralization == more good. But a network of networks has consequences for censorship resistance that we may not like.

Suppose the country of Naruba decides that they need their own DID directory to feel comfortable that citizen's credentials are anchored in a ledger with validator nodes that are trusted entities inside the country. There's an element of trust here and different governments and organizations will have their own trust criteria.

Within a proper governance framework, Naruba's DID directory could be known to be trustworthy by other international players (a property I call "provenance"). Sovrin Foundation has plans to extend the Sovrin Governance Framework to support a network of networks model and provide the rules for establishing the provenance of DID directories functioning within the Sovrin ecosystem.

Now, imagine you're a business based in Naruba, anchoring credentials on the Naruba DID directory. Your credentials will be trusted within Naruba because the government has set up governance for the Naruba DID directory and told Narubians to trust it. Your credentials might be trusted outside of Naruba if the Naruba DID directory is operating within some governance framework that organizations outside Naruba trust. So far, so good.

The Emirate of Kunami and Naruba are not on friendly terms. In an effort to punish Narubian businesses and keep them from buying Kumani oil, the Emir declares that the Narubian DID directory is off limits and the country carefully blocks the nodes on the Narubian ledger so that it is not accessible from Kunami. As a result, Narubian oil refineries can no longer do business with Kumani oil suppliers. Because the entire world economy depends on SSI and verifiable credentials, this is devastating because there are no other mechanisms to validate the complex supply chain transactions.

Now imagine a different scenario where there's one, predominant ledger where credential definitions are anchored. In this world, when Kunami wants to block Narubian credentials, blocking access to the DID directory would also block credentials their own economy depends on. So, they're forced to try to attack credentials one-by-one. A single, trusted anchor for credential definitions protects everyone from censorship. If any actor can isolate their core credential definitions on a network that they control, they can censor other networks without too much impact on themselves. Large, mixed pools of credential definitions provide a sort of herd immunity for everyone against censorship.

Of course, you can't stop someone from standing up their own network and, in the case of a government, forcing their citizens to use it. But if businesses and agencies inside the country need to interact with others outside the country, they may need to anchor credentials off that nationalized ledger to do business and then they can't censor. So, whether or not the Kunami DID directory would facilitate censorship depends on whether or not the international community would recognize it as a trustworthy source. If others don't trust it, Kumani can't use it as a weapon.

Network of Networks Governance

Don't get me wrong. I understand the drive to create a DID directory controlled by a government or industry organization. And some of those reasons form the basis for gaining traction and getting the adoption necessary for SSI to become a dominant means of creating trustworthy connection on the Internet.

Consequently, Sovrin supports a Network of Networks model. Right now adoption is the most important thing. Over time, multiple DID directories will likely coalesce into a few large directories. In the meantime, shared governance and community activity will compensate for the danger of censorship that multiple DID directories can create.

What does that governance look like? In a Network of Networks world, censorship resistance depends on strong governance that champions and facilitates convergence and cooperation while tolerating independence and innovation. The ability to censor depends on a network's ability to ignore other networks in favor of themselves. Governance must be carefully designed so that cooperation and mutual support are incentivized. Governance may need to institute measures like staking and quadratic membership fees to discourage natural monopolies. Without strong measures people, organizations, and governments will at best lose confidence in the network and at worst be held hostage to it.

Care must be taken to ensure that no single network gets so large that others cannot ignore it, but it can ignore them. Alternatively, we have to ensure that that network is one that is governed by the SSI principles that are consistent with the mission of Identity for All. The Sovrin Governance Framework is a start, but there is much work to be done. The Governance Framework Working Group has begun early work on the governance structure of a network of networks. The conversation is not over, but has only just begun.


  1. For details, see What Goes on the Ledger (PDF)
  2. This can also impact credential holders, but the biggest way to censor credential holders is to control their wallet. That's the subject of a different, future post.

Photo Credit: Censorship from Bill Kerr (CC BY-SA 2.0)

Supporting LESS and Trustless Identity

If you haven't yet seen Christopher Allen's excellent presentation on How to avoid another identity tragedy with SSI?, I encourage you to review the slides or watch the video of his recent presentation on

Christopher Allen Slides

Christopher's point is simple: identity systems have real-world, sometimes life and death, consequences. Designers of identity systems must take care to ensure they're not unwittingly enabling some future identity dystopia. He uses the recent remembrance of Jews killed by Nazis in the Netherlands as an example of a well-intentioned identity system being used later by the Nazis to efficiently find and kill a larger percentage of the Jewish population there than elsewhere in Europe. The Neatherlands built the system in the 1930's as part of a civil registration project.

Christopher points to two major "tracks" in self-sovereign identity: LESS Identity and what Christopher terms "Trustless" (or "trust minimized") identity.

LESS Identity is a concept from Tim Bouma that is an acronym for "legally-enabled self-sovereign" identity. Tim defines the key characteristics of LESS Identity as:

  • Minimum Disclosure: I want to disclose the absolute minimum to get a service or entitlement. If a service only needs to know I am legal to buy or receive something (because of age and/or residency) that's all they should get —not my name, date-of-birth, or my address.
  • Full Control: I want full control over what I disclose. Not only at the point in time of the transaction, but all future uses that I may, or may not allow.
  • Necessary Proofs: I understand that someone might not believe what I am providing — that’s ok — I should be able to provide proofs from the right authority—my age as proven by my local government, my academic degree as proven by my university.
  • Legally-Enabled: All of the preceding requirements backed up by the necessary or applicable legal framework to protect me, and to protect those who are providing services to me (risk goes both ways in any transaction).

On the other hand, Christopher defines Trustless Identity as having the following characteristics:

  • Anonymity
  • Web of Trust
  • Censorship Resistance
  • Defend Human Rights against Powerful Actors (nation states, multi-national corps, mafias, etc.)

I've used the concepts of monument and tapestry credentials to talk about these different needs. Too many 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 legal identity, things like birth certificates, property titles, and passports. This is the world of LESS Identity. But, for many, monument credentials suffer from two primary challenges: access and accuracy.

On the other hand, 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 evidence that can be trusted for things for which we’d otherwise rely on monument credentials. Taken together, they can be more accurate than a single monument credential. And because they're based on many small interactions, they are more immediately available to many, especially under-documented populations. Panfil and Mellon discuss, for example, how a system of tapestry credentials could be used in land administration.

More simply, think of things that you could prove through a credential-base web of trust where those whom you interact with day-to-day can say about you: things you've purchased, places you have been, flights you've taken, relationships you have, where you live, your family, where you work, and many other things can be attested by local organizations or the people you know. For many purposes, a tapestry of credentials can provide a sufficiently trustworthy foundation for achieving social goals.

A properly designed identity metasystem can balance the legitimate commercial and legal interests in credential exchange with the needs of everyone, in different contexts, for digital interactions that are privacy-preserving and autonomy-protecting. The Sovrin identity metasystem can provide for both LESS Identity (monument credentials) and Trustless Identity (tapestry credentials). There are several important characteristics of this identity metasystem that allow it to be useful in either context:

  • Censorship Resistant—Censorship is broadly defined in an identity system as being able to keep someone from accessing and using the system for any reason. There are several features that increase resistance of the metasystem to censorship including removing intermediaries, anchoring credentials in a large, global pool of other credential definitions, and state proofs for easily verifying the integrity of a ledger lookup—even offline.
  • Guardianship—There are many who won’t be in a position to manage their credentials directly for several reasons including not having access to the appropriate digital infrastructure, being too young, or otherwise lacking legal capacity (e.g. in a coma). We've spent considerable time on the legal and technical architectures necessary to support guardianship in Sovrin.
  • Correlation Minimization—Our work on and support for the Peer DID Method Specification is one example of how we work to reduce correlation. Peer DIDs reduce correlation, increase privacy, and scale to trillions of connections. Peer DIDs are easy to rotate or cancel because each relationship uses a different identifier.
  • Public DIDs for People—At the same time, people should be able to issue credentials to enable the wide use of tapestry credentials. GDPR, at present, limits the use of public DIDs for people (the root of an issued credential). Sovrin Foundation is engaged in discussions to balance data protection regulations with the legitimate needs of people to anchor credential definitions in a public ledger.
  • Minimal Disclosure—Credential holders use the Sovrin identity metasystem to share information from credentials using zero-knowledge proofs The agent protocols include the infrastructure and tools to enable the process of communicating, negotiating, sending, and verifying the fidelity of zero knowledge proofs (ZKPs). This is a secure way to minimize the information that is disclosed in a credential exchange without limiting functionality or security.

Many people, focused on the needs of LESS Identity, have claimed these features are too costly and unnecessary. But Sovrin Network provides an existence proof that these are not only possible, but efficient and usable. There's no excuse to not implement these vital features, when the code for them is open and usable. Without these important features, we risk building an identity metasystem that meets the demands of LESS Identity, but runs the risk of a future catastrophe. By supporting these, the Sovrin Network shows that LESS Identity is not necessarily in conflict with the goals of Identity for All.

This support for both is vital. Support for LESS Identity is needed for wide adoption. Without that, a Trustless Identity system is worthless since it is immediately identifiable as "an other" and therefore easily censored. When both are running on the same infrastructure, would-be censors can't kill one without damaging the other. One of the biggest factors in resisting censorship is making censorship too costly.

Sovrin Foundation has been dedicated to the goal of Identity for All since its inception. This must include both monument and tapestry credential models supporting legally-enabled and trustless self-sovereign identity. Ensure Identity for All requires that we balance the needs of all stakeholders by ensuring the metasystem remains independent.

Credentials and Covid-19 Recovery

Food Handler

In a recent Gates Foundation AMA on Reddit, Bill Gates said the following in response to a questions about the impact of Covid-19 on businesses:

Eventually we will have some digital certificates to show who has recovered or been tested recently or when we have a vaccine who has received it.

The responses from the Reddit community were predictable, with people wondering how such a document could be used against them.

Similarly, in a Wired Magazine interview with epidemiologist Larry Brilliant, he postulated a similar, albeit less high-tech, solution to the problem of knowing who's safe:

[We will] begin to see large numbers of people—in particular nurses, home health care providers, doctors, policemen, firemen, and teachers who have had the disease—are immune, and we have tested them to know that they are not infectious any longer. And we have a system that identifies them, either a concert wristband or a card with their photograph and some kind of a stamp on it. Then we can be comfortable sending our children back to school, because we know the teacher is not infectious.

Both of these are discussing credentials that can be used to know who is safe to have working. Imagine, for example, that you run a restaurant, live-in care facility, or other place where food is prepared and want to know that the people in the kitchen are safe.

Bill's solution would rely on the public key infrastructure and it presents privacy concerns from correlation to other information about the individual. Larry's solution is familiar, but hard to scale in a way that's trustworthy.

Verifiable credentials present an alternative that meets the needs of the use cases Bill and Larry foresee without the attendant privacy and scaling problems. Credentials based on Sovrin would protect individual privacy and autonomy while also ensuring credential fidelity. Specifically, anyone accepting a credential proof would know with certainty (1) who issued the credential, (2) that the credential is being presented by the person who it was issued to, (3) that the credential hasn't been tampered with, and (4) that it hasn't been revoked.

COVID-19 Credential Exchange
A testing organization issues a credential to the patient who can use it to prove to anyone they want that they've been tested for COVID-19 and found disease-free.

Further, an authoritative institution like the NIH could set up a governance framework that says who can authoritatively issue credentials for people who are immune, have been tested, or have been vaccinated. They would make this public in a credential issuer registry like OrgBook that the Government of British Columbia developed. Such a registry would be used to ensure credential provenance.

With this system in place, people don't have to be in a public registry and relying parties who verify the credential can trust that the attestation from the certifying organization about the person presenting the credential is true. People carry their own credentials and present them on request, protecting privacy. And the decentralized nature of the Sovrin Network ensures that it can scale to any degree required.

And the best news is that it can be built on Sovrin, right now. With multiple commercial software vendors offering products for credential issuers, credential holders, and credential verifiers and widespread support by a diverse community. A group of volunteers has formed to develop a pilot and support broad, scalable deployment of credentials that aid in preventing the spread of the disease and the economic recovery that needs to follow.

For more information, you can visit this Google Doc and find out how you can get involved.

The Sovrin SSI Stack

This post is based on Section 2 of the Sovrin Technical Architecture paper that Drummond Reed and I authored (to be published). Many others contributed to the thinking and provided useful critique and editing.

The Sovrin Network is a metasystem for building identity systems. The metasystem provides the means for anyone to issue, hold, present, accept, and verify credentials. The metasystem provides a universal means of discovering issuer identifiers and credential definitions in the ledger layer, and a universal protocol, called DIDComm, for connecting and sharing credentials in the agent layer. This universal protocol, combined with interoperable agents, creates an interoperable ecosystem. Participants share this interoperable ecosystem while exchanging credentials to solve their own individual problems.

The issuance, presentation, and verification of credentials in the Sovrin Network takes place within a stack of protocols and technologies. The Sovrin Stack comprises four layers:

  1. The Ledger Layer
  2. The Agent Layer
  3. The Credential Exchange Layer
  4. The Governance Layer

These layers are shown in Figure 1. The rest of this paper will discuss each layer in detail.

The Sovrin SSI Stack
The Sovrin SSI Stack (click to enlarge)

Layer One: The Sovrin Public Ledger

The bottom layer of the stack is the Sovrin Public Ledger. This decentralized ledger is specifically designed to support identity transactions and has several important properties:

  • Publicly accessible—this ledger is publicly readable and writable so that anyone can use it without an intermediary. This makes the network resistant to censorship. By having a decentralized network of nodes run by Sovrin Stewards around the world, anyone will be able to access the network at any time, even if one or many nodes get shut down or become inoperable.
  • Open source—the ledger nodes each run Hyperledger Indy, an open-source distributed ledger purpose-built for decentralized identity.
  • It enables the generation of state proofs—the ledger is capable of generating state proofs1 that can be used by Sovrin-compatible clients to know the state of the ledger without having to download and access the entire ledger. Each state proof contains a time stamp so the client can decide if the state proof is current enough for their use case or needs to be refreshed. This makes it ideal for use in credential verification where the clients may not have internet access for a period of time, a key requirement for universal adoption of digital credentials.

    In addition, state proofs can be cross anchored on other ledgers to increase reliability, trustworthiness, and resistance to censorship. This allows any holder to present a verified credential stored in their digital wallet—such as a driver’s license—anywhere and at any time in order to prove an attribute about themselves—such as their age—as needed, for example, to purchase a product requiring a legal minimum age.

  • Inexpensive to operate—transaction validation on the ledger is performed by known entities under proof-of-authority, making ledger access inexpensive enough to support the Network’s mission of establishing Identity for All (I4A). This means everyone—regardless of circumstances—has access to the Sovrin Network. The Sovrin Foundation’s I4A Council partners with NGOs, civil society organizations, and other groups promoting more inclusive identification systems to help bring identity network technology to populations who may not otherwise be served.
  • Provides support for the Sovrin Protocol Token—the ledger supports transactions of the Sovrin Token and ties it to identity transactions.

Unlike many other blockchain-based identity systems, using the Sovrin Network does not require storing personal identifying information, encrypted or otherwise, on the ledger. Rather, the Sovrin Network uses the ledger to store credential definitions, decentralized identifiers (DIDs) for issuers, schema definitions, and revocation registries. Without a decentralized ledger to store these, the Sovrin Network would have a single point of failure for these critical objects.

Objects like DIDs are created by Transaction Authors and added to the ledger by Stewards acting as Transaction Validators. Because the Sovrin Network is public, anyone can be a Transaction Author. But only organizations that function as Sovrin Stewards can validate the transactions that enable proof-of-authority consensus. Validation is done using a modified Redundant Byzantine Fault Tolerance algorithm implemented as Indy Plenum.

Storing credential definitions, and supporting data, on the ledger ensures that a credential verifier can test the fidelity of the credential without having to talk directly to the issuer. Fidelity allows the verifier to know 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 ledger breaks the circuit so that issuers don't know who is using a credential or when the credential is being used, a critical privacy provision. The ledger also lowers the cost and complexity for credential issuers since they don't have to maintain an always-on API for verifiers to use.

Decentralized Discovery and Governance of the Ledger

If the ledger is the basis for decentralized discovery, then we must ensure that no single organization controls the ledger and that it is protected from being taken down or corrupted by a single entity or by multiple entities.

The Sovrin Foundation and its Technical Governance Board (TGB) has designed the ledger and its governance to ensure that the ledger is public, open, and decentralized. This design includes three main groups: Sovrin Stewards, who operate the ledger nodes; Transaction Authors, who write DIDs and other cryptographic objects to the ledger; and Transaction Endorsers, who have permission to write to the ledger on behalf of Transaction Authors under the current Permissioned Write Access policies (PDF). These policies are only transitional until the Sovrin Foundation is able to provide Public Write Access. Sovrin infrastructure is designed to be censorship resistant such that no company or special interest can control who can use the protocol. All transactions are assigned validation priority through a transparent and fair algorithm maintained by the TGB. Public authorship of Sovrin transactions on a ledger via Public Write Access policies represent the best means available to combat censorship.

One key idea in decentralized systems is that different parts of the system are under the control of different organizations. Censorship resistance requires that even though Stewards must meet certain requirements to participate, it must still be assumed that any node might be hostile because of an attack or other circumstances beyond the control of the Steward. The Hyperledger Indy distributed ledger architecture provides this important property.

Because the Sovrin Network is based on blockchain technology and run by a large number of diverse validators (Sovrin Stewards), censorship becomes extremely difficult, if not practically impossible. Even if one or several of these access points stops actively participating in the Sovrin Network, there will still be someone who will provide access, as long as the governance rules are followed.

Because transaction authoring is a public function, the use of a ledger also ensures that under Public Write Access policies people can access, write, and update identifiers without being subject to gatekeeping. Note that it is possible that a specific gatekeeper—a Sovrin Steward—might restrict access to certain people, groups, or jurisdiction as a result of a compromised server, legal restrictions in its own jurisdiction, or other circumstances beyond its control. However, because the Sovrin Network is decentralized, people will still be able to access the ledger by using another Sovrin Steward’s node.

Decentralized Identifiers and Their Properties

Decentralized identifiers, or DIDs, are a new kind of identifier that provides the means of managing relationships in a self-sovereign identity system. DIDs resolve to 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 associated with exactly one DID. The W3C Credentials Community Group has published a global DID specification that is used in the Sovrin Network (and the W3C is currently forming a full W3C DID Working Group for further standardization of DIDs).

Decentralized identifiers in Sovrin infrastructure have these important properties:

  • Non-reassignable—DIDs are 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 identity holder control and self-sovereignty.
  • Resolvable—Resolution is the act of looking up the DID Document for a specific DID as defined by the specification for that particular type of DID, called the DID method. All Sovrin DIDs use the Sovrin DID method. 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.
  • Cryptographically verifiable—DIDs are associated with cryptographic keys, and the entity controlling the DID can use those keys to prove ownership (a process known as DID authentication). 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 directly with each other—called a peer-to-peer connection—can mutually authenticate each other and encrypt their communication.
  • Decentralized—DIDs are designed to function without a central registration authority. Sovrin DIDs can be created by anyone, anywhere, and for any purpose.

The Sovrin Network uses two kinds of DIDs: public and peer. Each has a different role in the operation of the network.

Public DIDs are created by people or organizations who are issuing credentials. The DID for a credential issuer must be written to the Sovrin Ledger so that they are capable of being resolved by anyone. When someone wishes to verify a credential, they retrieve the issuer's DID from the credential definition and then resolve—look up—the public DID to retrieve the associated DID Document of the issuer. Then, they use the public key in the DID Document and the digital signature of the credential to ensure it is is valid and has not been tampered with. They can also cryptographically verify that the credential was issued to the holder and that it has not been revoked.

Peer DIDs are not written to the Sovrin Ledger because they don’t need to be publicly resolvable. Instead, identity owners can issue a peer DID directly to another identity owner for peer-to-peer identity verification. By decentralizing verification, peer DIDs transform communication between verifiable entities in important ways (for full details, see the Peer DID Method Specification).

First, peer DIDs improve security because there is no need to use correlatable identifiers, such as email addresses, phone numbers, or credit card numbers, for verification. Therefore, decentralizing identity through peer DIDs eliminates the honey pots of data that centralized identity systems create and which become recurring targets of data breaches. Even if a peer DID was hacked in some way, it would be easy to cancel. Cancelling a peer DID is like cancelling a single-use credit card number—it does not affect any other relationship except the one party it was shared with.

Second, peer DIDs increase privacy because people are no longer dependent on centralized messaging systems (like WhatsApp or iMessage) to communicate with other parties; communication is peer-to-peer and cannot be “overheard”.

Third, peer DIDs provide more reliable communication as a decentralized network is more resistant to service interruption than centralized identity systems (almost every single node on the network would have to be disrupted). Peer DIDs also make communication between entities frictionless and controllable in ways not possible within centralized systems. If we want to sever a relationship with a particular entity, there is no impact on any other entity we have a relationship with. DID messaging through the use of peer DIDs is like having a dedicated private phone for every entity you engage with.

Finally, the use of peer DIDs allows for much 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 the Sovrin Ledger or some other blockchain.

Layer Two: The Agent-to-Agent Protocol

Agents are the basis for peer relationships in Sovrin infrastructure. The protocol used by agents, called DIDComm2, is defined in an open, public process inside the Hyperledger Aries project.

The Sovrin Network is designed so that personal identifying information does not need to be stored on the ledger. The design does this by using software agents that provide people with a place to hold, manage, and use keys and credentials. Sovrin identity owners usually have at least two agents, one on a device and one in the cloud3. If an identity owner has more than one device, all of their devices are likely to each have an agent.

Sovrin agents operate independently from each other in a heterarchical peer-to-peer topology. Agents communicate with each other for DID and credential sharing without an intermediary. They do not need the ledger to communicate. Communication between agents is done via peer-to-peer signed and encrypted DIDComm messages. The two agents in a peer relationship authenticate each other using the keys associated with the peer DIDs they exchanged when they established a relationship. Each agent has its own keys, and keys are never copied between agents.4

The use of device agents is highly decentralized because all keys and credentials are stored on the device at the very edges of the internet. Cloud agents, though hosted in the cloud, are also decentralized because they can be either self-hosted or run by any qualified service provider, called an agency. The cloud agent, like the edge agent, is always, wholly under the control of the person or organization who owns it. Most people using the Sovrin Network will opt to use an agency. There can be any number of agencies, and cloud agent operation is standardized so that identity owners should be able to easily switch agencies.

An agency does not have access to the data stored in a cloud agent. As a rule, cloud agent data is stored encrypted and can only be decrypted by device agents using keys stored at the edge of the network where they are safest. So, barring a coding problem that opens a security hole, there is no honey pot of information in an agency. The use of open source code for agencies should further reduce risk because the contributed code is constantly monitored and tested for quality and security by a global community of expert engineers and security professionals.

The peer-to-peer architecture of agents and their availability from multiple agencies creates a decentralized system for storing, managing, and using keys and credentials. This not only is a boon to identity owner privacy and autonomy, it also gives Sovrin infrastructure the potential to support an unlimited number of relationships.

Self-sovereign identity needs to be robust. It should be difficult for an accident or malice to wrest control of an identity away from its rightful owner, and it should be easy to fix problems if they arise. The DIDComm protocol includes strong decentralized key management and support for people to recover from accidents5 and attacks.

Layer Three: Credential Transmission

The third layer of the Sovrin technology stack is the credential transmission protocol that determines how the issuer’s agent issues credentials to the credential holder, how the credential verifier requests information from the credential holder, and how the credential holder presents a proof of information from their credentials that the verifier can trust (as explained in 1.4.2).

Credentials are defined by their issuer using a credential definition. The credential definition links the public DID of the issuer, the schema for the credential, and a revocation registry for the credential. The definition, public DID, schema, and revocation registry are all stored on a distributed ledger that is used for decentralized discovery—on the Sovrin Network, this is the Sovrin Ledger. The use of a publicly visible and verifiable credential definition provides credentials with important properties:

  1. Credentials are remotely verifiable. The public DID links the credential to its issuer, its public key, and other service information.
  2. Credentials are machine readable and understandable. The schema provides verifiers with information about the meaning and structure of the credential.
  3. Credentials can be revoked. The revocation registry allows the holder to prove to the verifier that the credential has not been revoked without the verifier needing to contact the issuer.

A single credential definition can be the root of millions of individual credentials because it links and records the public DID of the issuer, the schema, and revocation registry on the ledger. None of that information changes for credentials of the same type from the same issuer. It's like a rubber stamp that can be used to stamp many documents. By way of example, the Canadian provinces of British Columbia and Ontario have issued more than 1.4 million credentials proving official business registration for 529,000 companies using the Sovrin Network based on only a few credential definitions posted to the Sovrin Ledger.

Credential Exchange
Figure 2: Credential Exchange (click to enlarge)

Figure 2 shows an example of how the British Columbia credential issuing system operates: (1) Mary registers her Eco Tours business and receives a digital incorporation credential from the government of British Columbia. (2) Now Mary needs a loan for a new tour bus. When the bank’s online loan service asks for proof of incorporation, she presents her digital incorporation credential issued by British Columbia. Using the Sovrin Network, the bank verifies Mary’s credential and (3) uses it as part of the loan transaction.

Credential Exchange Using Zero Knowledge Proofs

Credential holders can share information from multiple credentials with minimal disclosure using Zero Knowledge Proofs (ZKPs). ZKPs are cryptographic techniques that allow users to share information without relinquishing their security and privacy. ZKPs use cryptography to prove a statement from the holder to the verifier without revealing any additional information that is not required by the verifier.

Zero Knowledge Proofs must have three properties to be usable:

  1. Completeness: If the statement is true, the verifier believes the result of the proof.
  2. Soundness: If the statement is false, the holder is unable to create a false proof to fool a verifier into thinking that it is true.
  3. Zero-knowledge: The verifier does not learn any other information about the holder other than what is in the proof.

A classic example is date of birth. Driver’s licenses and identification cards are often the primary means of proving age. However, this type of identification also contains other valuable private information, such as a person’s home address, which is frequently used in identity theft. Selective disclosure uses ZKPs to turn a digital copy of a driver’s license into a cryptographic proof of specific information in the driver’s license. It’s as if you’re creating a custom copy of your driver’s license that is every bit as reliable, and conveys the same personally identifiable information, as the real thing; but, based on who is asking, you control what information actually appears to them on that particular copy.

A Sovrin modile wallet can create a ZKP for each situation where the credential holder needs to prove their age. ZKP technology allows her to quickly, easily, and securely verify she is over 18, or 21, or 65 without actually having to share a specific date of birth.

The ZKP-based query language for credentials used by the Sovrin Network is currently implemented by open source code in the Hyperledger Aries project using the underlying crypto code of the Hyperledger Ursa project. The query language is sophisticated and designed to support a good holder experience while ensuring minimal disclosure. Attributes on a credential (also called “claims”), such as an address or social security number are individually signed by the issuer. ZKPs are created using these attributes. Using the Sovrin Network, identity holders create ZKPs to prove one or more of the following things about their attributes.

  1. Equality: if the attribute is equal to the value or an identity holder can just reveal the attribute itself in the proof.

    Example: [Are you employed?] = Sovrin ZKP: [Yes] or [Employer: IBM]

  2. Inequality: if an attribute lies in a specific range without revealing the actual value. This is helpful when dealing with something that has a numerical attribute, like age or money.

    Example: [Are you over 21] = Sovrin ZKP: [Age >= 21]

  3. Set Membership: ZKPs can prove if a value is contained in a set without revealing which value.

    Example: Do you live in Europe? = Sovrin ZKP: [Country of residence is: a European country] or [Country of residence is: not in a European country]

The Ledger in Use: What is Written, What is Not

Every credential issuer must write a credential definition to the ledger so that a verifier can look up the credential definition to ensure its integrity. Every credential issuer will also have to write a public DID. Most issuers will write revocation registries, and many will write schema definitions.

By contrast, most individuals will not need to write DIDs to the ledger or issue credentials. This is because peer DIDs are exchanged pairwise each time a new peer-to-peer relationship is formed (see also previous section: Decentralized Identifiers and Their Properties).

The following table summarizes what goes on the ledger and what does not.

Goes on the ledger Does not go on the ledger
Public DIDs and associated DID documents with verification keys and endpoints Peer DIDs
Schemas and credential definitions Issued credentials
Revocation registries Consent receipts or records of credential exchange transactions
Agent authorization policies

Layer Four: Governance

Although the Sovrin Network is decentralized, it still operates under a community-driven governance process whose goal is to maximize trust in the Sovrin Network as a global identity network. This governance process is essential to producing a system that can both meet governmental and jurisdictional requirements for data security, privacy, protection, and portability, while at the same time preventing censorship and ensuring individual sovereignty over the sharing of identity data.

The Sovrin Governance Framework (SGF) is the legal foundation of the Sovrin Network as a global identity network for self-sovereign identity. It is developed by the Sovrin Governance Framework Working Group (SGFWG), currently chaired by Sovrin Trustee Drummond Reed. Each new version is approved by the Sovrin Foundation Board of Trustees to become the official set of governance documents for the operation of the Sovrin Ledger and the Sovrin Network.

The Sovrin Network enforces rules through a mixture of open-source code and an active, open-governance process for rulemaking. This ensures that everyone can see the process for creating the rules, not just the methods by which they are enforced.

The SGF V2 was initially approved by the Sovrin Board of Trustees in March 2019. A subsequent set of revisions to add the legal support for compliance with the EU General Data Protection Regulation (GDPR) and other global data protection regulations as explained on the Sovrin Foundation’s Data Protection page was approved on December 2019. The primary documents include:

  1. The Sovrin Governance Framework Master Document (PDF)—The "constitution" of the Sovrin Network, this document defines the purpose, core principles, and core policies—and also references all other documents in the SGF V2, including all the Controlled Documents, which contain policies managed by specific subgroups within the Sovrin Foundation, listed in Appendix A.
  2. The Sovrin Glossary—A comprehensive glossary of almost 250 terms used in the Sovrin and digital identity communities throughout all the SGF V2 documents and all of Sovrin infrastructure, plus eight appendices that provide in-depth explanations of core groups of terms.
  3. The Sovrin Trust Assurance Framework (PDF)—This document defines criteria and processes for assessing the conformance of different Sovrin actors to the policies of the Sovrin Governance Framework.

The SGF V2 also includes five legal agreements:

  1. The Sovrin Steward Agreement (PDF)—between the Sovrin Foundation and a Sovrin Steward
  2. Steward Data Processing Agreement (PDF)—between the Sovrin Foundation and a Steward establishes the responsibilities of each for complying with GDPR and other data protection regulations.
  3. Transaction Author Agreement (PDF)—between the Sovrin Foundation and any person or organization initiating a write transaction to the Sovrin Ledger.
  4. Transaction Endorser Agreement (PDF) —between the Sovrin Foundation and any organization requiring permissioned write access to the Sovrin Ledger.
  5. Transaction Endorser Data Processing Agreement (PDF) —between the Sovrin Foundation and a Transaction Endorser establishes the responsibilities of each for complying with GDPR and other data protection regulations.

Lastly, the SGF V2 has seven Controlled Documents:

  1. Sovrin Governing Body Policies (PDF)—the governance policies that apply to all Sovrin Governing Bodies.
  2. Sovrin Ledger Access Policies (PDF)—governing reading and writing to the Sovrin Ledger and processing Sovrin Ledger Transaction Data.
  3. Sovrin Steward Business Policies (PDF)—governing qualification, application, activation, operation, suspension, and termination of Sovrin Stewards.
  4. Sovrin Steward Technical and Organizational Policies (PDF)—governing the security, node operation, node selection, and reporting requirements for Sovrin Stewards.
  5. Transaction Endorser Technical and Organizational Policies (PDF)—governs the security and operational policy requirements for Transaction Endorsers.
  6. Sovrin Economic Policies (PDF)—governing economic incentives, fees, and regulatory compliance.
  7. Sovrin Trust Mark Policies (PDF)—governs the use of the Sovrin Trust Mark by Stewards, agencies, and developers.

2.2 Operational Status

Anyone abiding by the Sovrin Governance Framework can use the network to issue verifiable digital credentials by writing transactions via a Transaction Endorser. Similarly, anyone can access the network for the purposes of verifying a proof of a Sovrin-based verifiable credential. Developers, organizations, and businesses working on Sovrin-based projects are currently using the Sovrin Public Ledger, including the Agent-to-Agent protocol, to issue and verify verifiable digital credentials under the current Permissioned Write Access policies. Issuers of Sovrin-based credentials, including Sovrin Stewards and Transaction Endorsers, are currently writing the information they need directly to the Sovrin Public Ledger. See Write to the Sovrin Public Ledger for information on how to get write to the ledger. Examples of these ledger writes include public decentralized identifiers (DIDs), schema, credential definitions, and other GDPR compliant pieces of public information that abide by the Sovrin Governance Framework and Transaction Endorser Agreement. Under Perimissioned Write Access, the Sovrin Foundation is collecting a fee from these organizations through a manual billing process to support the Foundation’s administration of the network.

The open-source, community-developed code for decentralized self-sovereign identity that enables the Sovrin stack is available in three Hyperledger Projects: Hyperledger Indy, Hyperledger Aries, and Hyperledger Ursa. The source code for Hyperledger Indy was originally contributed to the Linux Foundation by the Sovrin Foundation. To operate the nodes on the Sovrin Network, the Sovrin Stewards use the code housed in the Hyperledger Indy project.


The Sovrin Network is composed of a sophisticated stack of protocols, implemented in open source, backed and supported by organizations of every size around the world. The Sovrin Network is not an identity system for solving a narrow set of identity problems in a few contexts, but a metasystem, supporting the creation of millions of identity systems for any context one can imagine.

The goal of an identity metasystem, like Sovrin Network, is to connect individual identity systems and allow them to interoperate since no single system meets the needs of every digital identity scenario. By providing a set of unifying protocols and consistent user experience, the metasystem creates the framework within which these identity systems are built and operate. A sophisticated system of governance allows organizations, large and small, to participate in a regulatory-compliant network and fuel adoption while protecting the autonomy of people around the world—truly providing Identity for All.


  1. A state proof requested from a node that provides cryptographic verification that the response reflects the current state of the Sovrin Ledger.
  2. DIDComm is defined in a set of Hyperledger Aries specification documents called RFCs. See the repository README.
  3. The cloud agent, at a minimum, performs routing functions for edge agents that don't have reliable inbound IP connectivity.
  4. Hardman, Daniel. How DIDs, Keys, Credentials, and Agents Work in Sovrin, Sovrin Foundation, 2019.
  5. Hardman, Daniel. What if I lose my phone? Evernym, 2019.

Decarbonizing Locally

The same, but different (Carbon)

I recently listened to Saul Griffith on the Ezra Klein show about decarbonization. In contrast to a lot of the climate-change discussion we hear, Griffith's message is one I've always resonated with: a decarbonized future is better than what we have now. Too often, climate change is all about the sacrifices we have to make for the planet. That won't sell. I've got personal experience that informs my decision.

I've spent my career in the identity industry and there's an issue, privacy, where the discussion is much the same. I've long maintained that people won't pay for privacy, or will readily give up privacy for convenience. But privacy is foundational to personal autonomy. So if we're going to build a digital life for ourselves, we can't ignore privacy. What to do? Make a system that respects privacy and is a better identity system. Cake eaten; but still there.

Griffith says:

All of the politicians are pitching their climate plans from some top-down economic view, saying things like, “We’ll decarbonize this industry by this date.” It all sounds very abstract. No one has presented the Green New Deal from the kitchen table out: What will it look like in my home?

So, I started thinking about my personal efforts to decarbonize. Something we all should think about. Here's what we're done (in roughly the order we did them):

  • We've replace all our incandescent bulbs with LED bulbs.
  • I've replaced most our gas-powered yard tools with battery-powered versions.
  • We've put 40 solar panels on the house that produce about 14 Mwh of electricity per year. I studied this carefully before we got solar and concluded we had about a ten to twelve year payback on a system with at least a twenty year life, so it made financial sense. We're blessed to have retail net metering, so we also have, for a small monthly fee to the electric company, a great big battery.1
  • Since we had solar, when we replaced the dryer, we went electric instead of gas.
  • Last year, we traded in a 2004 Suburban we'd driven since the kids were little for a Tesla Model 3. Again, having solar influenced that decision because it made it more economically viable.
  • We recently replaced the upstairs air conditioner and furnace with one that is more efficient and includes a heat pump. So, unless the temperature is below 27 degrees, we use electricity to heat the upstairs instead of gas. That's most of the time in Utah. Again, the fact that we have solar influenced this decision because it made electricity the cheaper option, rather than a sacrifice.

With all that, there's still more we can do:

  • We still have a Ford F-150 pickup truck. I use the truck as a truck quite a bit, so until a good electric option becomes available, I'll keep the Ford. That said, I could get another electric car to use as our second vehicle and just use the truck when I really need a truck.
  • The downstairs air conditioner and furnace will probably need to be replaced soon and I'll go with the same set up I did upstairs.
  • I bought a brand new snow blower the winter before we went solar. I didn't know enough to look at the electric versions. I only use it 3-4 times per winter, so it's not very economical to replace it.

And there are some things that are hard:

  • Our hot water heater is gas and an electric water heater would cost more to operate and might even require upgrading our electrical service, an expensive proposition. I'll continue to monitor this for new options and see if we can discover one that makes financial sense.
  • I can't really see cooking on an induction range instead of gas. I've tried them; I know people swear by them. But I'm really in love with our gas range.

I started this post with Saul Griffith's proposition that decarbonization ought to lead to a better life, an amazing future. I believe our efforts are in line with that vision. The Tesla is amazing. The new furnace produces nicer heat than the old one (not as big of swings). I worry less about someone leaving the lights on. And we're saving money (even with the capital costs).

I recognize that I'm blessed to have the means to make capital investments that pay off over time. Not everyone can do that. But I think of our efforts as a vanguard that explores possibilities. Much of this is doable on a larger scale if new construction just built houses this way. They'd be cheaper to operate, safer, and cleaner and the capital cost would be managed alongside the other large capital costs of housing.

The point isn't that everyone should do what I've done. Rather, my point is find out what you can do and do it, especially if it makes your life better in some way.


  1. I realize we're cheating a bit here, but this is about our personal decarbonization. We can't solve the problem of demand shifting solar electricity production on our own.

    The demand shifting problem is an interesting one. There are two types: daily and seasonal. Daily demand shifting can be done with batteries in the home. My net metering situation reduces the financial incentive to do this since I don't save money by buying batteris (whereas if I didn't have a good net metering situation, I would). Still, there are advantages that tempt me, like being somewhat self sufficient during power outages.

    Seasonal demand shifting isn't something I can do much about on my own. No battery I could buy is big enough to store summer energy for use in the winter. This is an area where commercial and regulatory efforts can make a big impact.

Photo Credit: The same, but different (Carbon) from Tatters (CC BY-SA 2.0)

Building Identity Systems on the Sovrin Network

A metasystem is a system of systems. Metasystems employ protocols, governance, and convention to provide interoperability between the systems they comprise. Perhaps the most familiar example of a metasystem is the internet. The internet is not so much a communications system as it is a system for building communication systems that all interoperate.

An identity metasystem is a system for building interoperable identity systems. The concept of an identity metasystem was first introduced by Kim Cameron in 2005 (PDF). In describing this system, Kim said:

We need a unifying identity metasystem that can protect applications from the internal complexities of specific implementations and allow digital identity to become loosely coupled. This metasystem is in effect a system of systems that exposes a unified interface much like a device driver or network socket does.

The goal of an identity metasystem, like Sovrin Network, is to connect individual identity systems and allow them to interoperate since no single system meets the needs of every digital identity scenario. By providing a unifying protocol and consistent user experience, the metasystem creates the framework within which these identity systems are built and operate.

The Sovrin Identity Metasystem

I've spoken about the Sovrin Network as an identity metasystem before. The metasystem uses credential exchange as the unifying protocol for exchanging identity information. In credential exchange, an issuer issues a credential to a person or organization called the holder. The holder holds one or more credentials uses the protocols provided by the metasystem to prove things about themself to a verifier who needs trustworthy attributes. Figure 1 shows the layers of this system.

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

In this figure, the orange box represents the metasystem. The metasystem provides a universal means of discovering issuer identifiers and credential definitions in the ledger layer, and a universal protocol, called DIDComm, for connecting and sharing credentials in the agent layer.

The blue box on the top of Figure 1 represents an identity system built on top of the metasystem. There's more than one. In fact, there's tens of millions, maybe more. Every credential definition represents a new identity system created for a specific context. Anyone can define a credential for any purpose. And even though each identity system stands alone for its own purpose, they are interoperable because they are built on top of the metasystem.

For example, I may have a credential representing my drivers license and one representing my employee ID. These are designed for a specific purpose by the DMV and my employer. Yet, because they're based on a metasystem and use a common protocol, I could go to the bank and use those in concert to prove that I'm employed (employee ID) and my date of birth (drivers license) at the same time in one operation.

The two systems have different properties. The identity metasystem (orange box) provides important assurances about the fidelity of the credential. Specifically, the metasystem cryptographically assures (a) the identifier of the issuer and that (b) the credential was issued to the holder who is presenting it, (c) hasn't been tampered with, and (d) hasn't been revoked.

A credential verifier who receives a proof is concerned about credential fidelity, but they are 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). These latter are trust frameworks. Many already exist and I believe verifiable credentials will lead to the creation of many more.

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.

Identity Systems

When I say "digital identity system" most people probably think of just one thing: authentication. The digital identity systems we've built over the last 30 years are so anemic that it's difficult for us to imagine the kind of rich identity systems that exist in the physical world being available online.

In the offline world, we use credentials to prove things about ourselves to others. Each of these credentials constitutes an identity system, designed and built for a specific purpose in a given context. For example, businesses frequently give employees ID cards. I have one for Brigham Young University (BYU), my employer. I can use it to open doors, get a discount at the bookstore, get a car from the motor pool, and even ride a UTA bus or train. This flexible identity system allows the university to add new functionality over time as needs change. The university sets the rules about who gets an ID card and what it means. Of course, it also has use outside the context of the university, say, for example, at a store that gives discounts to university employees and is willing to accept the ID card as proof of employment.

Businesses are full of credentials. Every form or official piece of paper is a potential credential. Every bundle of data transmitted in a workflow is a potential credential. Here are a few examples of common credentials:

  • Employee badges
  • Drivers license
  • Passport
  • Wire authorizations
  • Credit cards
  • Business registration
  • Business licenses
  • College transcripts
  • Professional licensing (government and private)

Here are some others that may not be typically thought of as credentials, but fit the definition:

  • Invoices and receipts
  • Purchase orders
  • Airline or train ticket
  • Boarding pass
  • Certificate of authenticity (e.g. for art, other valuables)
  • Gym (or any) membership card
  • Movie (or any) tickets
  • Insurance cards
  • Insurance claims
  • Titles (e.g. property, vehicle, etc.)
  • Certificate of provenance (e.g. non-GMO, ethically sourced, etc.)
  • Prescriptions
  • Fractional ownership certificates for high value assets
  • CO2 rights and carbon credit transfers
  • Contracts

Since even a small business might issue receipts or invoices, have customers who use the company website, or use employee credentials, most businesses will define at least one credential and many will need many more. There are potentially tens of millions of different credential types. Many will use common schemas but each credential from a different issuer constitutes a different identity credential for a different context.

With the ongoing Anoncreds 2.0 work in Hyperledger Aries, these use cases expand even further. With its “redeemable credentials” feature, issuers can double-spend-proof proving credential possession without a ledger. This works for all kinds of redemption use cases like clocking back in at the end of a shift, voting in an election, posting an online review, or redeeming a coupon. If these use cases are interesting to you, please join the Aries WG calls and contribute.

You might notice that many of the things listed in the second list are solutions some people advocate building entire blockchains for. That's overkill when you can use a credential to get the job done. Especially when that credential is interoperable with others in a ubiquitous identity metasystem. By double-spend proofing credentials, you create a system capable of representing value of all sorts. Bottom line: an identity metasystem for trustworthy credential exchange has uses far beyond what we might typically think of as an "identity system."

A Marketplace for Credentials

Many credentials will be created for internal or non-commercial purposes (like the employee credential). But some will have a supporting business model. This is exactly what happens offline where many credentials are exchanged for money. The metasystem should support credential business models to achieve ubiquity. Daniel Hardman discusses this in his excellent blog post about Categorizing Verifiable Credentials.

Credentials may intersect with payment in different ways. Some may be issued and used for free; others may be purchased; still others may incur a fee with every use. And while payment could be viewed as entirely independent from credentials, the binding is actually more interesting. This is because economics and levels of assurance are intertwined. For example, a top-secret security clearance may require thousands of dollars of field work and investigation, and bump its holder’s salary by even more. Thus, business models that allow economic value to be harvested in any and all credential interactions are a no-brainer.
With non-free credentials, who pays whom is interesting. The most straightforward model is probably holder-pays-issuer; we already expect to pay a fee when we apply for a passport. But other variations are equally possible, and they represent potential innovation that’s been somewhat impractical with physical credentials. For example, a holder that’s applying to a university might pay the university a fee to verify their academic credentials. A potential employer with stringent security requirements might pay an issuer to achieve assurance that an applicant has a government security clearance. A medical researcher might pay a holder for the privilege of verifying genetic information from credentials, as part of a study they’re conducting.

While it's impossible to anticipate every possible credential use case that includes a reciprocal exchange of value, looking at a few use cases is instructive. The following use cases are just for the Holder-Pays-Issuer pattern, but other patterns, like Verifier-Pays-Issuer, are possible.

Drivers License—Drivers licenses are an excellent example of a credential people pay for. There are 112MM licensed drivers just in the US. If we assume each license costs $30 and is renewed every five years, almost $700 million is paid per annum for drivers licenses.

Memberships—Memberships in gyms are just one example of a membership credential where the credential holder pays the issuer. Gym membership revenues in the US in 2018 was $32BB according to Wellness Creatives. There are many more membership types that could be built on top of Sovrin.

Movie Tickets—Movie tickets are another credential that is bought. In 2018, 1.3 billion movie tickets were sold in the US. At $10 per ticket, that's $13 billion.

Airline Tickets—Airline tickets are a special kind of credential that is purchased. According to IATA, there were 4.1 billion airline passengers in 2017. The US Department of Transportation Bureau of Transportation Statistics reports that average airfare was $347 that same year. So we can estimate that worldwide airfare was about $1.4 trillion in 2017.

Online Sales—Online sales could be accomplished using Holder-Pays-Issuer credential exchange. By paying for the receipt (a credential) equal to the amount of the order, you can view all of ecommerce as a form of paid credential issuance. Linking payment to a credential and placing it inside a wallet that emphasizes relationships and credential management may make credential-related payments an important component of online retail. US online retail sales were $519BB in 2018.

These are just a few potential use cases where credentials and value are exchanged. While not all of these will necessarily come to pass, it's easy to conclude that the potential marketplace for credentials is in the trillions of dollars. The identity metasystem, with it's mutually authenticated messaging protocol, is an excellent platform for supporting commercial credential exchange. These workflows, with built-in value exchange, can be developed on the identity metasystem.

Supporting Value Exchange

I believe decentralized systems need a built-in method of value exchange in order to thrive. A credential marketplace is a great example why this would be important in an identity metasystem. A native means of exchanging value has several advantages over doing it outside of the network.

  1. First, information received from credentials can't easily be pulled back if payment isn't received. By incorporating credential exchange and value exchange in the same network, the system can ensure finality1, eliminating the need for escrow in many situations.
  2. Second, a native payment mechanism reduces friction because people building identity systems don't have to source and integrate a separate payment system if the native system meets their needs.
  3. Third, a native payment mechanism could provide payment services at greatly reduced fees when compared with external payment networks.
  4. Lastly, and most importantly, a native payment system can ensure that the integration of payments doesn't inadvertently provide a correlation path and compromise privacy


An identity metasystem like the Sovrin Network provides the foundation for creating tens of millions of interoperable identity systems for every conceivable context and use. By virtue of being built on the metasystem, these identity systems share a common protocol and similar user experience. The metasystem is available to all and is decentralized, allowing each participant to make their own decisions about what identity systems they will build and participate in to support their goals and ambitions.


  1. Finality is the ability to know that the payment for a transaction is complete before finalizing the transaction.

Self-Sovereign Blogging

Sometime in 2011, I decided to use Flickr to host the images on my blog. My reasons for that ill-fated decision are lost, but I suspect, based on what I was doing in 2011, that I saw using cloud-based services as a way to off-load some of the work, storage costs, etc. Part of the reason for using Flickr probably has something to do with the Movable Type set up I was using in 2011. In 2013, I switched to a custom blogging platform I wrote that uses a combination of Emacs macros and a Perl program for assembly of the content files. I stopped using Flickr for this purpose in 2016 and just hosted the images myself, but all the entries on my blog for that 6-year period still used Flickr.

Not too long ago, I noticed that all the images being served by Flickr had a black background like this:

fuse microservice overall

Not exactly what I want. I suspect that some change at Flickr having to do with transparent images caused this. Admittedly, storing diagrams with transparent backgrounds for a blog is not Flickr's mainstay, so I don't blame them for this. They're just pursuing their own objectives. And that's the point I'm making:

Without a contract that gives me clear promises about what Flickr intends, I'm at their mercy. Note that this is true with any cloud service, especially those you're not paying for or using outside their main use case. They can go away at any point. They can change their business model. We've seen plenty of online services go away. We should expect it.

So, I decided I needed to fix my blog by hosting all the images myself. Fortunately, I can program, so I wrote a Perl program to do the following:

  1. Open the blog file and run through it looking for images hosted at Flickr, keeping a list
  2. Download all the original images from Flickr (which involves parsing the Flickr page to find the right URL for the original image file)
  3. Process the blog file, replacing all images referenced in the anchor and image tags with the names of the local files.

Of course, that simple algorithm ignores all the little problems that always come up. But writing the program was fun and now, I'm running it (slowly to not look like a DDoS attack to Flickr). Soon, my cloud problem will be in the past and my blog will be self-sovereign. Of course, I still rely on hosting (AWS) and DNS (Google) but those are much more basic services that are likely to not go away anytime soon. And if they do, there are clear substitutes.

Centralized Services Needn't be Evil to be a Problem

Microsoft Passport Logo

I ran across this story today about Microsoft forgetting to renew the domain and cutting off millions of users from service. It's no longer available at its original home, so the link is to the Wayback machine copy.

There are several lessons here:

  1. We like to talk about centralization being bad because it potentially gives power to evil actors. But let's not forget that centralization can be bad merely because organizations can be incompetent, forgetful, or inept. Leadership shifts. Policies expire. Companies fail. Systems decay. By all accounts, Microsoft is a well-run place, but relying on a single actor to make things work for millions is no way to do something as fundamental to human autonomy and dignity as digital identity.
  2. The use of just-in-time callbacks to build trust in an identity credential can put millions out of service for simple authentication checks. Imagine if every use of the driver's license required a real-time call back to the Drivers License Bureau. Instead, let's build identity systems that allow people to hold credentials that don't need real-time verification to check fidelity and provenance.
  3. Domain names are not identity. They're rented and so can't be permanent. The story on is interesting history, but the domain was impermanent. Thankfully, places like the Wayback Machine preserve some of it. Consider donating! I did.

Future-Safe Archives

In an interesting podcast format—voicemails—Dave and Doc raise the issue of future-safe archives. This is one of those important, but not-urgent-enough issues that gets far too little attention.

As they point out, we have Internet Archives, but that's just a copy and, while better than nothing, doesn't always preserve the original. I've got several different thoughts in my head after listening to Doc.

First, I think preserving things is worthwhile. When Doug Kaye decided to shut down IT Conversations, he did so early enough that he could "endow" its preservation at Internet Archives and pay for the preservation of the domain name, at least for a while. Consequently all the links still work. And the shows are still available. It's not perfect (e.g. the pictures don't load—at least not today), but it is preserved.

My second thought is that the Web is a fluid place. Hence the WayBack Machine. Doc and Dave are discussing blogs, and they grow but old stuff doesn't often change. (Hey! They're like blockchains! :) ) I can easily envision archiving and preserving blogs. Other sites are harder. I think about iMall, for example. iMall was an ecommerce company I founded with Ross Jardine in 1994 and worked on until we sold it to Excite@Home in 1999. There were thousands of variations to over the years. The WayBack Machine has many of them, but not likely all. What does it mean to preserve that? I'm not sure. Maybe the WayBack Machine is the best we can do.

P.S. This new podcast needs an RSS feed!

Update: Dave says: "Phil, the RSS feed is the feed of my blog. I'm going to wait until it gains traction, i.e. Doc and I get a regular thing going, to give it its own feed." Fair enough.

Four Pillars of an SSI Network

The restored Stoa of Attalos in Athens

A few weeks ago Andy Tobin posted an excellent piece on the Three Pillars of Self-Sovereign Identity:

  1. Secure connections
  2. Digital data “watermarking”1
  3. A trusted, tamper-proof public key directory

I encourage you to pop over and read it to understand the technical underpinnings of SSI. The point Andy is making is that all of these are necessary for a functioning SSI system. I hear far too many people saying that decentralized identifiers (DIDs) are all you need. That's like saying the Web is all about HTML, ignoring HTTP and URLs.

But, a functional identity metasystem needs more than just technical standards. We often hear that the internet is a product of standards, and while that's true, it also only exists because people strung cable, wrote code, created rules, built organizations, and formed alliances. SSI has similar needs and meeting them won't happen just because we define nice protocols and write some open source code. I wrote about this earlier in a piece on Decentralization and Coherence.

Social systems that are enduring, scalable, and generative require coherence among participants. Coherence allows us to manage complexity. Coherence is necessary for any group of people to cooperate. The coherence necessary to create the Internet came in part from standards, but more from the actions of people who created organizations, established those standards, ran services, and set up exchange points.

A functioning network for an identity metasystem is a social system, and building it requires a means of building coherence to align the actions of people and organizations. We created the Sovrin Foundation to do that. Over time its role may change, but right now, there are important tasks that must be done to create coherence.

Building a functional SSI network requires that, in addition to the technical standards, we work on several core areas: governance, community, operations, and adoption.


In a blog post on recent revisions to the Sovrin Governance Framework, I wrote:

Others in the blockchain space might wonder why Sovrin spends so much time, energy, and money complying with regulations. It's not just about various actors in the system being risk averse. An identity system that you can't use everywhere is just a different technology implementation of what we have now with Login with Apple (or Amazon or Google or Facebook or...). Credential issuers and credential verifiers of all stripes, including banks, governments, educational institutions, etc, must be comfortable with using Sovrin for it to gain universal adoption as an identity metasystem. These institutions will avoid using any system that is perceived as rogue or otherwise non-compliant

If the Sovrin community is not aiming to build a universal, interoperable system, then we're just building another silo that perpetuates all the problems with the existing silos: inflexibility, insecurity, and inconvenience.

Governance is critical to universal interoperability in an identity metasystem because all participants must be able to make their own decisions about who and what to trust. Governance gives assurances by providing process and accountability. As this Hackernoon article from Agata Slater says:

The hard part [of bootstrapping SSI] is setting up the governance and collaboration model that will ensure that the federation is reliable, secure, and affords appropriate data protection.

In particular, trust, the reason for an identity metasystem, can't exist without credential fidelity and provenance. And those require governance.


The Sovrin community is the heart of what makes the identity metasystem work and is composed of identity owners, developers, Stewards, businesses, and other organizations, all acting in multiple roles, such as credential issuers, holders, and verifiers, and with varied interests, business models, compliance requirements, and geographic representation.

Developer involvement is one of the keys to a thriving identity metasystem. As I said earlier, standards are essential, but you need code to bring them to life. Interoperability requires more than standards. It needs a strong community of developers collaborating to ensure their solutions work together. Developer communities, like any other social system need coherence. Look at successful open source projects like the Linux Kernel, React, or Homebrew and you'll find a tribe, institution, market, or network, depending on scope and scale who served as the backbone of its global adoption.

Sovrin Foundation supports developers around the world in the Hyperledger Aries, Indy, and Ursa projects. This support includes project coordination and organization, training on the code bases so developers can come up to speed quickly, and bringing together the various groups as we did in the recent Aries Connectathon.

Another important community is comprised of the organizations who use Sovrin to build identity systems for their specific needs. While using a verifiable credential within a single industry vertical is a significant step forward, we believe the real benefit of an identity metasystem is when you can present a credential from your bank to a car dealership. Sovrin-based identity systems will open a world of possibilities that are only dreams today. The Foundation works to bring participants together in community-lead meetings, and through working groups where participants can solve problems together. The Sovrin Alliance is an important part of this effort.


The foundational layer of the Sovrin Network is a ledger for storing DIDs, credential definitions, and other important artifacts, that everyone needs for making trust decisions. Validation on the Sovrin ledger is based on a known set of nodes run by the Stewards. To operate the nodes on the Sovrin Network, the Sovrin Stewards use the open source code housed in the Hyperledger Indy project. They run code produced by the Hyperledger Indy project.

Some of the key operational functions of the Sovrin Foundation are coordinating code releases and supporting Stewards. The Foundation Ops Team monitors the nodes which run the Sovrin Network to ensure they operate in accordance with the Governance Framework and the network meets important requirements, like censorship resistance.

Sovrin Stewards are organizations approved by the Trustees to operate a node to maintain the Sovrin Ledger. The ledger is permissioned, meaning that the nodes are run by organizations known to the Foundation and in accordance with the Governance Framework. Stewards must contractually agree to the Sovrin Steward Agreement and Steward Data Processing Agreement with the Sovrin Foundation. These agreements commit them to terms and conditions relating to confidentiality, intellectual property, and data privacy, among others. The nodes run an RBFT consensus algorithm called Plenum to come to agreement on the content of the ledger. Stewards can include for-profit and not-for-profit entities as well as governments or anyone else who abides by the Sovrin Governance Transaction Author and Transaction Endorser agreements who wants to write transactions to the Sovrin Ledger.

Three ledgers are in operation now: the mainnet for production use, a buildernet for testing, and the stagingnet for non-production use that requires more performance stability than the buildernet offers. Depending on the needs of the Sovrin community, there could be other ledgers in the future.

Because Sovrin is a permissioned network, validator nodes are chosen for each of these ledgers according to a node selection algorithm defined by Sovrin's Technical Governance Board. The Foundation provides staff to monitor node selection, coordinate communications with Stewards, Transaction Endorsers, and Transaction Authors, and ensure the network is technically strong and operating in accordance with Sovrin governance agreements.

Advocacy, Evangelism, and Adoption

The fourth key function of the Sovrin Foundation is evangelizing self-sovereign identity and bringing people and organizations together to spur adoption. The Foundation achieves this using a three-pronged approach.

  1. First, we focus on building awareness of and affinity for self-sovereign identity. Sovrin Foundation is a non-profit, open-source project formed to advance the development and adoption of tools, products, and services that are aligned with the Sovrin Governance Framework. We believe having a trusted leader in decentralized identity space sets the Sovrin ecosystem apart from other SSI community efforts.
  2. As many organizations actively contribute and participate in the Sovrin ecosystem, we also channel marketing efforts around the individual projects and their own respective value propositions, bringing awareness to specific features and communities.
  3. Finally, Sovrin Foundation works to highlight, promote and bring awareness to individual use cases and what they are providing their customers. Our aim is to connect all parts of this new evolving ecosystem to grow the adoption, and widespread use of self-sovereign identity and the Sovrin Network.

Our efforts include:

Advocacy: The are numerous organizations, groups, and efforts around the world working on SSI. Some of these are formal standards bodies, policy, and advocacy organizations. Some are community organizations with specific purposes. Sovrin Foundation facilitates the participation of staff and volunteers in these efforts to guide SSI developments in ways that are consistent with the principles that are part of the Governance Framework.

Sovrin Blog: The Sovrin Foundation blog is read by thousands and provides an opportunity to broadcast the latest news and views to a wide audience beyond the core ecosystem participants. Selected content may include summaries of important updates, both Governance and Technical, but it may also include stories about events, use cases, industry insights, and other topics that may be of interest to the community.

Community Events: In 2019, the Sovrin Foundation participated in nearly 60 events around the world. Employees, volunteers, and active members of the Sovrin Ecosystem traveled great distances at great expense to promote, educate, and participate in conferences, workshops, working groups, meetings, and speaking engagements.

Marketing & PR Channels: The monthly Sovrin Newsletter will celebrate its two year anniversary in 2020, never missing an issue. The newsletter provides a regular recap of news, events, profiles, and announcements from around the Sovrin Community. Along with the social media channels,, and forums, Sovrin works diligently to keep the lines of communication open between the employees, volunteers, and community.

Analyst Relations: Industry reports from third parties is a vital part of the Sovrin Foundation community engagement strategy. In 2019, Sovrin communicated with industry analysts (also known as research analysts) from six of the top independent research and consulting firms. These inquiries resulted in multiple mentions and positive attention in key industry reports on self-sovereign identity, decentralized identity, and blockchain.

Trademark & Brand: Adhering to the strong brand guidelines of the Sovrin Foundation offers an important as a trust signal to people using the Sovrin Network. A strong brand also helps avoid market confusion and serves to align the fast-growing community to reap optimal benefits when discussing association with Sovrin. The Sovrin Foundation has registered Sovrin® as a trademark in the United States and other countries to help with this effort.

Membership: There are many ways to be part of the Sovrin community. As more organizations find their way to Sovrin and self-sovereign identity, Sovrin Foundation makes every effort to onboard these groups to participate in the Sovrin Foundation as members of the Sovrin Alliance, Stewards, volunteers, and as open source contributors. Stay tuned in 2020 for more information spotlighting each of these important groups and how you too can be “Sovrin.”


In the Coherence and Decentralization post I referenced earlier, I talk about the four ways humans build consensus: tribes, institutions, markets, and networks. Sovrin Network's tribal days are past, but we still employ each of the other three methods in bringing people together and building a successful and functioning network.

Over time, the Foundation's role will moderate as more and more of the coherence is created through markets and the network itself. However, we must not underestimate the value of community leadership, guidance, and administration of network governance policies, especially as we bootstrap a thriving community. Without the Foundation as an objective and independent entity, there is much greater potential for mis-use, abuse, and strong-arm tactics that can remove the democratization of the underlying technology. There are no shortage of examples in the recent history of the digital economy that point to the need for objective governance that can ensure access to resources that can truly move self-sovereign identity to the world on a one-to-one basis so that is not controlled by a few large-scale players. There will always be a role for the Foundation that has the mission of ensuring that this technology truly provides “Identity for All” with equal and affordable access and opportunity for everyone.


  1. By "watermarking", Andy is referring to the verifiable credentials standard and Hyperledger Aries credential exchange protocol.

Photo Credit: The restored Stoa of Attalos in Athens from Adam Carr (CC0)