The Architecture of Identity Systems

Skysong Center

Introductory note: I recently read a paper from Sam Smith, Key Event Receipt Infrastructure, that provided inspiration for a way to think about and classify identity systems. In particular his terminology was helpful to me. This blog post uses terminology and ideas from Sam's paper to classify and analyze three different identity system architectures. I hope it provides a used model for thinking about identity online.

John Locke was an English philosopher who thought a lot about power: who had it, how it was used, and how it impacted the structure of society. Locke’s theory of mind forms the foundation for our modern ideas about identity and independence. Locke argued that "sovereign and independent" was man’s natural state and that we gave up freedom, our sovereignty, in exchange for something else, protection, sociality, and commerce, among others. This grand bargain forms the basis for any society.

This question of power and authority is vital in identity systems. We can ask "what do we give up and to whom in a given identity system?" More succinctly we ask: who controls what? In Authentic Digital Relationships I made the argument that self-sovereign identity, supporting heterarchical (peer-to-peer) interaction, enables rich digital relationships that allow people to be digitally embodied so they can act online as autonomous agents. I argued that the architecture of SSI, its structure, made those relationships more authentic.

In this post, I intend to explore the details of that architecture so we can better understand the legitimacy of SSI as an identity system for online interaction. Wikipedia defines legitimacy as

the right and acceptance of an authority, usually a governing law or a regime.

While the idea of legitimacy is most often applied to governments, I think we can rightly pose legitimacy questions for technical systems, especially those that function in an authoritative manner and have large impacts on people and society. Without legitimacy, people and organizations using an identity system will be unable to act because anyone they interact with will not see that action as authorized. My thesis is that SSI provides a more legitimate basis for online identity than administrative identity systems of the past.

Terminology

While we properly talk of identity systems, identity systems do not manage identities, but rather relationships. Identity systems provide the means necessary for remembering, recognizing, and relying on the other parties to the relationship. To do so, they use identifiers, convenient handles that name the thing being remembered. Identifiers are unique within some namespace. The namespace gives context to the identifiers since the same string of characters might be a phone number in one system and a product ID in another.

Figure 1: Binding of controller, authentication factors, and identifiers in identity systems.
Figure 1: Binding of controller, authentication factors, and identifiers in identity systems. (click to enlarge)

Identifiers are issued to or created by a controller who by virtue of knowing the authentication factors can make authoritative statements about the identifier (e.g. claiming it by logging in). The controller might be a person, organization, or software system. The controller might be the subject that the identifier refers to, but not necessarily. The authentication factors might be a password, key fob, cryptographic keys, or something else. The strength and nature of the bindings between the controller, authentication factors, and identifier determine the strength and nature of the relationships built on top of them.

To understand why that's so, we introduce the concept of a root of trust1. A root of trust is a foundational component or process in the identity system that is relied on by other components of the system and whose failure would compromise the integrity of the bindings. A root of trust might be primary or secondary depending on whether or not it is replaceable. Primary roots of trust are irreplaceable. Together, the roots of trust form the trust basis for the system.

The trust basis enabled by the identity system underlies a particular trust domain. The trust domain is the set of digital activities that depend on the binding of the controller to the identifier. For example, binding a customer to an identifier allows Amazon to trust that the actions linked to the identifier are authorized by the controller. Another way to look at this is that the strength of the binding between the identifier and customer (controller) determines the risk that Amazon assumes in honoring those actions.

The strength of the controller-identifier binding depends on the strength of the binding between the controller and the authentication factors and between the authentication factors and the identifier. Attacking either of those bindings reduces the trust we have in the controller-identifier binding and increases the risk that actions taken through a particular identifier are unauthorized.

Identity Architectures

We can broadly classify identity systems into one of three types based on their architectures and primary root of trust:

  • Administrative
  • Algorithmic
  • Autonomic

Both algorithmic and autonomic are SSI systems. They are distinguished by their trust bases. Some SSI systems use one or the other and some (like Sovrin) are hybrid, employing each for different purposes. We'll discuss the properties of the trust basis for each of these in an effort to understand the comparative legitimacy of SSI solutions to traditional administrative ones.

These systems differ in who controls what and that is the primary factor in determining the basis for trust in them. We call this control authority. The entity with control authority takes action through operations that affect the creation (inception), updating, rotation, revocation, deletion, and delegation of the authentication factors and their relation to the identifier. How these events are ordered and their dependence on previous operations is important. The record of these operations is the source of truth for the identity system.

Administrative Architecture

Identity systems with an administrative architecture rely on an administrator to bind the the identifier to the authentication factors. The administrator is the primary root of trust for any domain with an administrative architecture. Almost every identity system in use today has an administrative architecture and their trust basis is founded on the administrator.

Figure 2: The trust basis in administrative identity systems.
Figure 2: The trust basis in administrative identity systems. (click to enlarge)

Figure 2 shows the interactions between the controller, identifier and authentication factors in an administrative identity system, the role of the administrator, and the impact these have on the strength of the bindings. The controller usually generates the authentication factors by choosing a password, linking a two-factor authentication (2FA) mechanism, or generating keys.

Even though the identifier might be the controller's email address, phone number, public key, or other ID, the administrator "assigns" the identifier to the controller because it is their policy that determines which identifiers are allowed, whether they can be updated, and their legitimacy within the identity system's domain. The administrator "owns" the identifier within the domain. The administrator also asserts the binding between the identifier and the authentication factors. An employee's mistake, a policy change, or a hack could affect the binding between the identifier and authentication factors or the identifier and the controller. Consequently these bindings are relatively weak. Only the binding between the controller and authentication factors is strong because the controller generates them.

The administrator's primary duty is to authoritatively assert the controller-identifier binding. Authoritative control statements about the identifier are recorded in the administrator's database, the source of truth in the system, subject to change by employees and hackers. The administrator might be an ecommerce site that maintains an identity system as the basis for its customer's account. In this case the binding is private, and its integrity is of interest only to the web site and the customer. Alternatively, the administrator might provide federated login services. In this case the administrator is asserting the controller-identifier binding in a semi-public manner to anyone who relies on the federated login. A certificate authority is an example of an administrator who publicly asserts the controller-identifier binding, signing a certificate to that effect.

Because the administrator is responsible for binding the identifier to both the authentication factors and the controller, the administrator is the primary root of trust and thus the basis for trust in the overall system. Regardless of whether the binding is private, semi-public, or public, the integrity of the binding is entirely dependent on the administrator and the strength of their infrastructure, policies, employees, and continued existence. The failure of any of those can jeopardize the binding, rendering the identity system unusable by those who rely on it.

Algorithmic Architecture

Identity systems that rely on a ledger have an algorithmic architecture. I'm using "ledger" as a generic term for any algorithmically controlled distributed consensus-based datastore including public blockchains, private blockchains, distributed file systems, and others. Of course, it's not just algorithms. Algorithms are embodied in code, written by people, running on servers. How the code is written, its availability to scrutiny, and the means by which it is executed all impact the trust basis for the system. "Algorithmic" is just shorthand for all of this.

Figure 3: The trust basis in algorithmic identity systems.
Figure 3: The trust basis in algorithmic identity systems. (click to enlarge)

Figure 3 shows how the controller, authentication factors, identifier, and ledger are bound in an identity system with an algorithmic architecture. As in the administrative identity system, the controller generates the authentication factors, albeit in the form of a public-private key pair. The controller keeps and does not share the private key. The public key, on the other hand, is used to derive an identifier (at least in well-designed SSI systems) and both are registered on the ledger. This registration is the inception of the controller-identifier binding since the controller can use the private key to assert her control over the identifier as registered on the ledger. Anyone with access to the ledger can determine algorithmically that the controller-identifier binding is valid.

The controller makes authoritative control statements about the identifier. The events marking these operations are recorded on the ledger which becomes the source of truth for anyone interested in the binding between the identifier and authentication factors.

In an identity system with an algorithmic trust basis, computer algorithms create a ledger that records the key events. The point of the ledger is that no party has the power to unilaterally decide whether these records are made, modified, or deleted and how they're ordered. Instead, the system relies on code executed in a decentralized manner to make these decisions. The nature of the algorithm, the manner in which the code is written, and the methods and rules for its execution all impact the integrity of the algorithmic identity system and consequently any bindings that it records.

Autonomic Architecture

Identity systems with an autonomic architecture function similarly to those with an algorithmic architecture. As shown in Figure 4, the controller generates a public-private key pair, derives a globally unique identifier, and shares the identifier and the currently associated public key with anyone.

Figure 4: Trust basis in autonomic identity systems.
Figure 4: Trust basis in autonomic identity systems. (click to enlarge)

The controller uses her private key to authoritatively and non-repudiably sign statements about the operations on the keys and their binding to the identifier, storing those in an ordered key event log2. One of the important realizations that make autonomic identity systems possible is that the key event log must only be ordered in the context of a single identifier, not globally. So, a ledger is not needed for recording operations on identifiers that are not public. The key event log can be shared with and verified by anyone who cares to see it.

The controller also uses the private key to sign statements that authenticate herself and authorize use of the identifier. A digital signature also provides the means of cryptographically responding to challenges to prove her control of the identifier. These self-authentication and self-authorization capabilities make the identifier self-certifying and self-managing, meaning that there is no external third party, not even a ledger, needed for the controller to manage and use the identifier and prove to others the integrity of the bindings between herself and the identifier. Thus anyone (any entity) can create and establish control over an identifier namespace in a manner that is independent, interoperable, and portable without recourse to any central authority. Autonomic identity systems rely solely on self-sovereign authority.

Autonomic identifiers have a number of advantages:

  • Self-Certification—autonomic identifiers are self-certifying so there is no reliance on a third party.
  • Self-Administration—autonomic identifiers can be idependently administered by the controller.
  • Cost—autonomic identifiers are virtually free to create and manage.
  • Security—because the keys are decentralized, there is no trove of secrets that can be stolen.
  • Regulatory—since autonomic identifiers need not be publicly shared or stored in an organization’s database, regulatory concern over personal data can be reduced.
  • Scale—autonomic identifiers scale with the combined computing capacity of all participants, not some central system.
  • Independent—autonomic identifiers are not dependent on any specific technology or even being online.

Algorithmic and Autonomic Identity In Practice

We are all familiar with administrative identity systems. We use them all the time. Less familiar are algorithmic and autonomic identity systems. Their use is emerging under the title of self-sovereign identity.

There are several parallel development efforts supporting algorithmic and autonomic identifiers. The Decentralized Identifier specification is the primary guide to algorithmic identifiers that live on a ledger. The DID specification provides for many DID methods that allow DIDs to live on a variety of data stores. There's nothing in the DID specification itself that requires that the data store be a blockchain or ledger, but that is the primary use case.

I've written about the details of decentralized identifiers before. DIDs have a number of important properties that make them ideal as algorithmic identifiers. Specifically, they are non-reassignable, resolvable, cryptographically verifiable, and decentralized.

As algorithmic identifiers, DIDs allow the controller to cryptographically make authoritative statements about the identifier and the keys it is bound to. Those statements are recorded on a ledger or blockchain to provide a record of the key events that anyone with access to the ledger can evaluate. The record is usually public since the purpose of putting them on a ledger is to allow parties who don't have an existing relationship to evaluate the identifier and its linkage to the controller and public keys.

There are two related efforts for autonomic identifiers. Key Event Receipt Infrastructure is a general-purpose self-certifying system for autonomic identifiers. KERI identifiers are strongly bound at inception to a public-private key pair. All operations on the identifier are recorded in a cryptographic key event log. KERI has strong security and accountability properties. Drummond Reed has made a proposal that would allow KERI autonomic identifiers to be used with any DID method.

The second option is Peer DIDs. The vast majority of relationships between people, organizations, and things need not be public and thus have no need for the ability to publicly resolve the DID. Peer DIDs fill this need with the benefits of autonomic identifiers listed above.

Like KERI, Peer DIDs maintain a key event log (called "deltas") that records the relevant operations on the keys in a cryptographic manner. The Peer DID key event log can be shared with other parties in the relationship over DIDComm, a protocol that allows parties to a relationship to securely and privately share authenticated messages. The security and authority of a DIDComm channel are rooted in DIDs and their associated authentication factors. DIDComm can be used over a wide variety of transports.

The vast majority of digital relationships are peer to peer and should use autonomic identifiers. Algorithmic identifiers allow for public discovery of identifier properties when relationships are not peer to peer. In the Sovrin Network3, the ledger records public DIDs for verifiable credential issuers. But people, organizations, and things form relationships using peer DIDs without need for the ledger. This hybrid use of both algorithmic and autonomic identity systems was designed so that credential exchange would be practical, secure, and private while reducing the correlation that might occur if individuals used a few DIDs on a ledger.

Comparing Identity Architectures

Table 1 summarizes the architectural properties of identity systems with administrative, algorithmic, and autonomic bases of trust.

Architectural properties of administrative, algorithmic, and autonomic identity systems
Table 1: Architectural properties of administrative, algorithmic, and autonomic identity systems (click to enlarge)

The table shows how the locus of control, source of truth, root of trust, and trust basis differ for each of our three architectures. For Administrative systems, the administrator is directly in control of all four of these. In an algorithmic architecture, the controller is the locus of control because the ledger is set up to allow the controller to be in charge of all key operations. Sometimes this is done using special administrative keys instead of the keys associated with the identifier. The organizations or people operating nodes on the ledger never have access to the keys necessary to unilaterally change the record of operations. No third party is involved in autonomic identity systems.

Table 2 summarizes the trust bases of administrative, algorithmic, and autonomic identity systems4.

Comparing the trust bases of administrative, algorithmic, and autonomic identity systems
Table 2: Summarizing the trust bases of administrative, algorithmic, and autonomic identity systems (click to enlarge)

We can see from the evaluation that algorithmic and autonomic architectures are decentralized while the administrative system has a single point of failure—the third party administrator. As a result administrative systems are less secure since an attack on one party can yield a trove of valuable information. Administrative systems also rely on privacy by policy rather than having privacy preserving features built into the architecture. And, as we've seen, all too often privacy is in direct conflict with the administrator's profit motive leading to weak privacy policies.

Power and Legitimacy

I started this post by talking about power and legitimacy. From our discussion and the summary tables above, we know that power is held very differently in these three systems. In an administrative system, the administrator holds all the power. I argued in Authentic Digital Relationships that the architecture of our identity systems directly impacts the quality and utility of the digital relationships they support. Specifically, the power imbalance inherent in administrative identity systems yields anemic relationships. In contrast, the balance of power engendered by SSI systems (both algorithmic and autonomic) yields richer relationships since all parties can contribute to it.

Clearly, administrative identity systems have legitimacy—if they didn't, no one would use or trust them. As new architectures, algorithmic and autonomic systems have yet to prove themselves through usage. But we can evaluate each architecture in terms of the promises it makes and how well it does in the purposes of an identity system: recognizing, remembering, and relying on other parties in the relationship. These are largely a function of the trust basis for the system.

Administrative systems promise an account for taking actions that the administrator allows. They also promise these accounts will be secure and private. But people and organizations are increasingly concerned with privacy and seemingly non-stop security breaches are chipping away at that legitimacy. As noted above, the privacy promise is often quite limited. Since the administrator is the basis for trust, administrative systems allow the administrator to recognize, remember, and rely on the identifier depending on their security. But the account holder does not get any support from the administrative system in recognizing, remembering, or relying on the administrator. The relationship is strictly one-way and anemic.

SSI systems promise to give anyone the means to securely and privately create online relationships and trustworthily share self-asserted and third-party-attested attributes with whoever they chose. These promises are embodied in the property I call fidelity. To the extent that algorithmic and autonomic identity systems deliver on these promises, they will be seen as legitimate.

Both algorithmic and autonomic identity systems provide strong means for recognizing, remembering, and relying on the identifiers in the relationship. For an algorithmic system, we must trust the ledger as the primary root of trust and the trust basis. Clearly our trust in the ledger will depend on many factors, including the code and the governance that controls its operation.

The trust basis for an autonomic identity system is cryptography. This implies that digital key management will become an important factor in its legitimacy. If people and organizations cannot easily manage the keys in such a system, then it will not be trusted. There is hope that key management can be solved since the primary artifacts that people using an SSI system manipulate are relationships and credentials, not keys and secrets. By supporting a consistent user experience rooted in familiar artifacts from the physical world, SSI promises to make cryptography a usable technology by the majority of people on the Internet.

Conclusion

In this article, we've explored the high-level architectures for the identity systems in use today as well as new designs that promise richer, more authentic online relationships, better security, and more privacy. By exploring the trust bases that arise from these architectures we've been able to explore the legitimacy of these architectures as a basis for online identity. My belief is that a hybrid system that combines algorithmic public identifiers with autonomic private identifiers can provide a universal identity layer for the Internet, increasing security and privacy, reducing friction, and providing new and better online experiences.


Notes

  1. Often the term root of trust is used to a hardware device or some trusted hardware component in the computer. The usage here is broader and refers to anything that is relied on for trust in the identity system. Trust anchor is a term that has sometimes been used in the cryptography community to refer to this same concept.
  2. A number of cryptographic systems are trivially self-certifying (e.g. PGP, Ethereum, Bitcoin, etc.). What sets the autonomic identity systems described here apart is the key event log. Sam Smith calls these identifiers “autonomic identifiers” to set them apart from their less capable counterparts and emphasize their ability to self-manage keys without recourse to a third party system.
  3. The Sovrin Network is an operational instance of the code found in the Hyperledger Indy and Aries projects.
  4. This table is borrowed, with permission, from Chapter 10 of the upcoming Manning publication Self-Sovereign Identity by Drummond Reed and Alex Preukschat.

Photo Credit: Skysong Center from Phil Windley (CC BY-SA 3.0 US)


Authentic Digital Relationships

Two Bees

An earlier blog post, Relationships and Identity proposed that we build digital identity systems to create and manage relationships—not identities—and discussed the nature of digital relationships in terms of their integrity, lifespan, and utility. You should read that post before this one.

In his article Architecture Eats Culture Eats Strategy, Tim Bouma makes the point that the old management chestnut Culture Eats Strategy leaves open the question: how do we change the culture. Tim's point is that architecture (in the general sense) is the upstream predator to culture. Architecture is a powerful force that drives culture and therefore determines what strategies will succeed—or, more generally, what use cases are possible.

Following on Tim's insight, my thesis is that identity systems are the foundational layer of our digital ecosystem and therefore the architecture of digital identity systems drives online culture and ultimately what we can do and what we can't. Specifically, since identity systems are built to create and manage relationships, their architecture deeply impacts the kinds of relationships they support. And the quality of those relationships determines whether or not we live effective lives in the digital sphere.

Administrative Identity Systems Create Anemic Relationships

I was the founder and CTO of iMall, an early, pioneering ecommerce tools vendor. As early as 1996 we determined that we not only needed a shopping cart that kept track of a shopper's purchases in a single session, but one that knew who the shopper was from visit to visit so we could keep the shopping cart and pre-fill forms with shipping and billing addresses. Consequently, we built an identity system. In the spirit of the early web, it was a one-off, written in Perl and storing personal data in Berkeley DB. We did hash the passwords—we weren't idiots1.

Early Web companies had a problem: we needed to know things about people and there was no reliable way for them to tell us who they were. So everyone built an identity system and thus began my and your journey to collecting thousands of identifiers as the Web expanded and every single site needed it's own way to know things about us.

Administrative identity systems, as these kinds of identity systems are called, create a relationship between the organization operating the identity system and the people who are their customers, citizens, partners, and so on. They are, federation notwithstanding, largely self contained and put the administrator at the center as shown in Figure 1. This is their fundamental architecture.

Administrative identity systems put the administrator at the center.
Figure 1: Administrative identity systems put the administrator at the center. (click to enlarge)

Administrative identity systems are owned. They are closed. They are run for the purposes of their owners, not the purposes of the people or things being administered. They provision and permission. They are bureaucracies for governing something. They rely on rules, procedures, and formal interaction patterns. Need a new password? Be sure to follow the password rules of what ever administrative system you're in. Fail to follow the company's terms of service? You could lose your account without recourse.

Administrative identity systems use a simple schema, containing just the attributes that the administrator needs to serve their purposes and reduce risk. The problem I and others were solving back in the 90's was legibility2. Legibility is a term used to describe how administrative systems make things governable by simplifying, inventorying, and rationalizing things around them. Identity systems make people legible in order to offer them continuity and convenience while reducing risk for the administrator.

Administrative identity systems give rise to a systematic inequality in the relationships they manage. Administrative identity systems create bureaucratic cultures. Every interaction you have online happens under the watchful eye of a bureaucracy built to govern the system and the people using it. The bureaucracy may be benevolent, benign, or malevolent but it controls the interaction.

Designers of administrative identity systems do the imaginative work of assigning identifiers, defining the administrative schemas and processes, and setting the purpose of the identity system and the relationships it engenders. Because of the systematic imbalance of power that administrative identity systems create, administrators can afford to be lazy. To the administrator, everyone is structurally the same, being fit into the same schema. This is efficient because they can afford to ignore all the qualities that make people unique and concentrate on just their business. Meanwhile subjects are left to perform the "interpretive labor" as David Graeber calls it of understanding the system, what it allows or doesn't, and how it can be bent to accomplish their goals. Subjects have few tools for managing these relationship because each one is a little different, not only technically, but procedurally as well. There is no common protocol or user experience. Consequently, subjects have no way to operationalize the relationship except in whatever manner the administrator allows.

Given that the architecture of administrative identity systems gives rise to a bureaucratic culture, what kinds of strategies or capabilities does that culture engender? Quoting David Graeber from The Utopia of Rules (pg 152):

Cold, impersonal, bureaucratic relations are much like cash transactions, and both offer similar advantages and disadvantages. On the one hand they are soulless. On the other, they are simple, predictable, and—within certain parameters, at least—treat everyone more or less the same.

I argue that this is the kind of thing the internet is best at. Our online relationships with ecommerce companies, social media providers, banks, and others are cold and impersonal, but also relatively efficient. In that sense, the web has kept its promise. But the institutionalized frame of action that has come to define it alienates its subjects in two ways:

  • They are isolated and estranged from each other.
  • They surrender control over their online activity and the associated data within a given domain to the administrator of that domain.

The administrative architecture and the bureaucratic culture it creates has several unavoidable, regrettable outcomes:

  • Anemic relationships that limit the capabilities of the systems they support. For example, social media platforms are designed to allow people to form a link (symmetrical or asymmetrical) to others online. But it is all done within the sphere of the administrative domain of the system provider. The relationships in these systems are like two-dimensional cardboard cutouts of the real relationships they mirror. We inhabit multiple walled gardens that no more reflect real life than do the walled gardens of amusement parks.
  • A surveillance economy that relies on the weak privacy provisions that administrative systems create to exploit our online behavior as the raw material for products that not only predict, but attempt to manipulate, our future behaviors.3 Many administrative relationships are set up to harvest data about our online behavior. The administrator controls the nature of these relationships, what is allowed, and what is behavior is rewarded.
  • Single points of failure where key parts of our lives are contained within the systems of companies that will inevitably cease to exist someday. In the words of Craig Burton: "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 Self-Sovereign Alternative

Self-sovereign identity (SSI) systems offers an alternative model that supports richer relationships. Rather than provisioning identifiers and accounts in an administrative system where the power imbalance assures that one party to the relationship can dictate the terms of the interaction, SSI is founded on peer relationships that are co-provisioned by the exchange of decentralized identifiers. This architecture implies that both parties will have tools that speak a common protocol.

SSI Stack
Figure 2: Self-Sovereign Identity Stack (click to enlarge)

Figure 2 shows the self-sovereign identity stack. The bottom two layers, the Verifiable Data Repositories and the Peer-to-Peer Agents make up what we refer to as the Identity Metasystem. The features of the metasystem architecture are our primary interest. I have written extensively about the details of the architecture of the metasystem in other posts (see The Sovrin SSI Stack and Decentralized Identifiers).

The architecture of the metasystem has several important features:

  • Mediated by protocol—Instead of being intermediated by an intervening administrative authority, activities in the metasystem are mediated through peer-to-peer protocol. Protocols are the foundation of interoperability and allow for scale. Protocols describe the rules for a set of interactions, specifying the kinds of interactions that can happen without being overly prescriptive about their nature or content. Consequently, the metasystem supports a flexible set of interactions that can be adapted for many different contexts and needs.
  • Heterarchical—Interactions in the metasystem are peer-to-peer rather than hierarchical. The are not just distributed, but decentralized. Decentralization enables autonomy and flexibility and to assure its independence from the influence of any single actor. No centralized 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.
  • Consistent user experience—A consistent 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. Consistent user experiences let people know what to expect so they can intuitively understand how to interact in any given situation regardless of context.
  • Polymorphic—The information we need in any given relationship varies widely with context. The content that an identity metasystem carries must be flexible enough to support many different situations.

These architectural features give rise to a culture that I describe as protocological. The protocological culture of the identity metasystem has the following properties:

  • Open and permissionless—The metasystem has the same three virtues of the Internet that Doc Searls and Dave Weinberger enumerated: No one owns it, everyone can use it, and anyone can improve it. Special care is taken to ensure that the metasystem is censorship resistant so that everyone has access. The protocols and code that enable the metasystem are open source and available for review and improvement.
  • Agentic—The metasystem allows allows people to act as autonomous agents, under their self-sovereign authority. The most vital value proposition of self-sovereign identity is autonomy—not being inside someone else's administrative system where they make the rules in a one sided way. Autonomy requires that participants interact as peers in the system, which the architecture of the metasystem supports.
  • Inclusive—Inclusivity is more than being open and permissionless. Inclusivity requires design that ensures people are not left behind. For example, some people cannot act for themselves for legal (e.g. minors) or other (e.g. refugees) reasons. Support for digital guardianship ensures that those who cannot act for themselves can still participate.
  • Flexible—The metasystem allows people to select appropriate service providers and features. No single system can anticipate all the scenarios that will be required for billions of individuals to live their own effective lives. A metasystem allows for context-specific scenarios.
  • Modular—An identity metasystem can’t be a single, centralized system from a single vendor 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.
  • Universal—Successful protocols eat other protocols until only one survives. An identity metasystem based on protocol will have network effects that drive interoperability leading to universality. This doesn't mean that one organization will have control, it means that one protocol will mediate all interaction and everyone in the ecosystem will conform to it.

Supporting Authentic Relationships

Self-sovereign identity envisions digital life that cannot be supported with traditional identity architectures. The architecture of self-sovereign identity and the culture that springs from it support richer, more authentic relationships:

  1. Self-sovereign identity provides people with the means of operationalizing their online relationships by providing them the tools for acting online as peers and managing the relationships they enter into.
  2. Self-sovereign identity, through protocol, allows ad hoc interactions that were not or cannot be imagined a priori.

The following subsections give examples for each of these.

Disintermediating Platforms

Many real-world experiences have been successfully digitized, but the resulting intermediation opens us to exploitation despite the conveniences. We need digitized experiences that respect human dignity and don't leave us open to being exploited for some company's advantage. As an example consider how the identity metasystem could be the foundation for a system that disintermediates the food delivery platforms. Platform companies have been very successful in intermediating these exchanges and charging exorbitant rents for what ought to be a natural interaction among peers.

That's not to say platforms provide no value. The problem isn't that they charge for services, but that their intervening position gives them too much power to make markets and set prices. Platforms provide several things that make them valuable to participants: a means of discovering relevant service providers, a system to facilitate the transaction, and a trust framework to help participants make the leap over the trust gap, as Rachel Botsman puts it. An identity metasystem supporting self-sovereign identity provides a universal trust framework for building systems that can serve as the foundation for creating markets without intermediaries. Such a system with support for a token can even facilitate the transaction without anyone having an intervening position.

Disintermediating platforms requires creating a peer-to-peer marketplace on top of the metasystem. While the metasystem provides the means of creating and managing the peer-to-peer relationship, defining this marketplace requires determining the messages to be exchanged between participants and creating the means of discovery. These messages might be simple or complex depending on the market and could be exchanged using DIDComm, or even ride on top of a verifiable credential exchange. There might be businesses that provide discovery, but they don't intermediate, they sit to the side of the interaction providing a service. For example, such a business might provide a service that allows a restaurant to define its menu, create a shopping cart, and provide for discovery, but the merchant could replace it with a similar service, providing competition, because the trust interaction and transaction are happening via a protocol built on a universal metasystem.

Building markets without intermediaries greatly reduces the cost of participating in the market and frees participants to innovate. Because these results are achieved through protocol, we do not need to create new regulations that stifle innovation and lock in incumbents by making it difficult for new entrants to comply. And these systems preserve human dignity and autonomy by removing administrative authorities.

Digitizing Auto Accidents

As an example of the the kinds of interactions that people have every day that are difficult to bring into the administrative sphere, consider the interactions that occur between various participants and their representatives following an auto accident. Because these interactions are ad hoc, large parts of our lives have yet to enjoy the convenience of being digitized. In You've Had an Automobile Accident, I imagine a digital identity system that enables the kinds of ad hoc, messy, and unpredictable interactions that happen all the time in the physical world.

In this scenario, two drivers, Alice and Bob, have had an accident. Fortunately, no one was hurt, but the highway patrol has come to the scene to make an accident report. Both Alice and Bob have a number of credentials that will be necessary to create the report:

  • Proof of insurance issued by their respective insurance companies
  • Vehicle title from the state
  • Vehicle registration issued by the Department of Motor Vehicles (DMV) in different states (potentially)
  • Driver's license, potentially from a different agencies than the one who registers cars and potentially in different states

In addition, the police officer has a credentials from the Highway Patrol, Alice and Bob will make and sign statements, and the police officer will create an accident report. What's more, the owners of the vehicles may not be the drivers.

Now imagine you're building a startup to solve the "car accident use case." You imagine a platform to relate to all these participants and intermediate the exchange of all this information. To have value, it has to do more than provide a way to exchange PDFs and most if not all of the participants have to be on it. The system has to make the information usable. How do you get all the various insurance companies, state agencies, to say nothing of the many body shops and hospitals, fire departments, and ambulance companies on board? And yet, these kinds of ad hoc interactions confront us daily.

Taking our Rightful Place in the Digital Sphere

Devon Leffreto said something recently that made me think:

You do not have an accurate operational relationship with your Government.

My thought was "not just government". The key word is "operational". People don't have operational relationships anywhere online.4 We have plenty of online relationships, but they are not operational because we are prevented from acting by their anemic natures. Our helplessness is the result of the power imbalance that is inherent in bureaucratic relationships. The solution to the anemic relationships created by administrative identity systems is to provide people with the tools they need to operationalize their self-sovereign authority and act as peers with others online. Scenarios like the ones envisioned in the preceding section happen all the time in the physical world—in fact they're the norm. When we dine at a restaurant or shop at a store in the physical world, we do not do so under some administrative system. Rather, as embodied agents, we operationalize our relationships, whether they be long-lived or nascent, by acting for ourselves. An identity metasystem provides people with the tools they need to be "embodied" in the digital world and act autonomously.

Time and again, various people have tried to create decentralized marketplaces or social networks only to fail to gain traction. These systems fail because they are not based on a firm foundation that allows people to act in relationships with sovereign authority in systems mediated through protocol rather than companies. We have a fine example of a protocol mediated system in the internet, but we've failed to take up the daunting task of building the same kind of system for identity. Consequently, when we act, we do so without firm footing or sufficient leverage.

Ironically, the internet broke down the walled gardens of CompuServe and Prodigy with a protocol-mediated metasystem, but surveillance capitalism has rebuilt them on the web. No one could live an effective life in an amusement park. Similarly, we cannot function as fully embodied agents in the digital sphere within the administrative systems of surveillance capitalists, despite their attractions. The emergence of self-sovereign identity, agreements on protocols, and the creation of a metasystem to operationalize them promises a digital world where decentralized interactions create life-like online experiences. The identity metasystem and the richer relationships that result from it promise an online future that gives people the opportunity to act for themselves as autonomous human beings and supports their dignity so that they can live an effective online life.


End Notes

  1. Two of my friends at the time, Eric Thompson and Stacey Son were playing with FPGAs that could crack hashed passwords, so we were aware of the problems and did our best to mitigate them.
  2. See Venkatesh Rao's nice summary of James C. Scott's seminal book on legibility and its unintended consequences, Seeing Like a State for more on this idea.
  3. See The Age of Surveillance Capitalism by Shoshana Zuboff for a detailed (705 page) exploration of this idea.
  4. The one exception I can think of to this is email. People act through email all the time in ways that aren't intermediated by their email provider. Again, it's a result of the architecture of email, set up over four decades ago and the culture that architecture supports.

Photo Credit: Two Yellow Bees from Pikrepo (public)


Cogito, Ergo Sum

Cogito, Ergo Sum

Descartes didn't say "I have a birth certificate, therefore I am." We do not spring into existence because some administrative system provisions an identifer for us. No single administrative regime, or even a collection of them, defines us. Doc Searls said this to me recently:

We are, within ourselves, what William Ernest Henley calls “the captain” of “my unconquerable soul”, and what Walt Whitman meant when he said “I know this orbit of mine cannot be swept by a carpenter's compass,” and “I know that I am august. I do not trouble my spirit to vindicate itself or be understood.” Each of us has an inner essence that is who we are.

Even in the digital realm, and limiting ourselves to what Joe Andrieu calls "functional identity", we are more than any single relationship. Our identity is something we are, not something we have. And it's certainly not what someone else provides to us. We are self-sovereign.

Some shrink from the self-sovereign label. There are some good reasons for their reluctance. Self-sovereignty requires some explanation. And it has political overtones that make some uncomfortable. But I've decided to embrace it. Self-sovereign identity is more than decentralized identity. Self-sovereign identity implies autonomy and inalienability.

If our identity is inalienable, then it's not transferable to another and not capable of being taken away or denied. To be inalienable is to be sovereign: to exercise supreme authority over one’s personal sphere—Whitman’s “orbit of mine.” Administrative identifiers, what others choose to call us, are alienable. Relationships are alienable. Most attributes are alienable1. Who we are, and our right to choose how we present ourselves to the world, is not alienable. The distinction between the inalienable and the alienable, the self-sovereign and the administrative, is essential. Without this distinction, we are constantly at the mercy of the various administrative regimes we interact with.

Self-sovereignty is concerned with relationships and boundaries. When we say a nation is sovereign, we mean that it can act as a peer to other sovereign states, not that it can do whatever it wants. Sovereignty defines the source of our authority to act. Sovereignty defines a boundary, within which the sovereign has complete control and outside of which the sovereign relates to others within established rules and norms. Self-sovereign identity defines the boundary in the digital space, gives tools to people and organizations so they can assert control—their autonomy, and defines the rules for how relationships are formed, authenticated, and used.

In the opening chapter of her groundbreaking book, The Age of Surveillance Capitalism, Shoshana Zuboff asks the question "Can the digital future be our home?" Not if it's based on administrative identity systems and the anemic, ofttimes dangerous, relationships they create. By starting with self-sovereignty, we found our digital relationships on principles that support and preserve human freedom, privacy, and dignity. So, while talking about trust, decentralization, credentials, wallets, and DIDs might help explain how self-sovereign identity works, sovereignty explains why we do it. If self-sovereignty requires explanation, maybe that's a feature, not a bug.


End Notes

  1. I'm distinguishing attributes from traits without going too deep into that idea for now.

Photo Credit: Cogito, Ergo Sum from Latin Quotes (Unknown License)


Relationships and Identity

Two People Holding Hands

The most problematic word in the term Self-Sovereign Identity (SSI) isn't "sovereign" but "identity" because whenever you start discussing identity, the conversation is rife with unspoken assumptions. Identity usually conjures thoughts of authentication and various federation schemes that purport to make authentication easier. I frequently point out that even though SSI has "identity" in it's name, there's no artifact in SSI called an "identity." Instead the user experience in an SSI system is based on forming relationships and using credentials.

I've been thinking a lot lately about the role of relationships in digital identity systems and have come to the conclusion that we've been working on building building systems that support digital relationships without acknowledging the importance of relationships or using them in our designs and architectures. The reason we build identity systems isn't to manage identities, it's to support digital relationships.

I recently read and then reread a 2011 paper called Identities Evolve: Why Federated Identity is Easier Said than Done from Steve Wilson. Despite being almost ten years old, the paper is still relevant, full of good analysis and interesting ideas. Among those is the idea that the the goal of using federation schemes to create a few identities that serve all purposes is deeply flawed. Steve's point is that we have so many identities because we have have lots of relationships. The identity data for a given relationship is contextual and highly evolved to fit its specific niche.

Steve's discussion reminded me of a talk Sam Ramji used to give about speciation of APIs. Sam illustrated his talk with a picture from Encyclopedia Britannica to show adaptive radiation in Galapagos finches in response to evolutionary pressure. These 14 different finches all share a common ancestor, but ended up with quite different features because of specialization for a particular niche.

adaptive radiation in Galapagos finches
Adaptive radiation in Galapagos finches (click to enlarge)

In the same way, each of us have hundreds, even thousands, of online relationships. They each have a common root but are highly contextualized. Some are long-lived, some are ephemeral. Some are personal, some are commercial. Some are important, some are trivial. Still, we have them. The information about ourselves, what many refer to as identity data, that we share with each is just as adapted to the specific niche that the relationship represents as the Galapagos finches are to their niches. Once you realize this, the idea of creating a few online identities to serve all needs becomes preposterous.

Not only is each relationship evolved for a particular niche, but it is also constantly changing. Often those changes are just more of what's already there. For example, my Netflix account represents a relationship between me and Netflix. It's constantly being updated with my viewing data but not changing dramatically in structure. But some changes are larger. For example, it also allows me to create additional profiles which makes the relationship specialized for the specific members of my household. And when Netflix moved from DVDs only to streaming, the nature of my relationship with Netflix changed significantly.

I'm convinced that identity systems would be better architected if we were more intentional about their need to support specialized relationships spanning millions of potential relationship types. This article is aimed at better understanding the nature of digital relationships.

Relationships

One of the fundamental problems of internet identity is proximity. Because we're not interacting with people physically, our natural means of knowing who we're dealing with are useless. Joe Andrieu defines identity as "how we recognize, remember, and respond" to another entity. These three activities correspond to three properties digital relationships must have to overcome the proximity problem:

  • Integrity—we want to know that, from interaction to interaction, we're dealing with the same entity we were before. In other words, we want to identify them.
  • Lifespan—normally we want relationships to be long-lived, although we also create ephemeral relationships for short-lived interactions.
  • Utility—we create online relationships in order to use them within a specific context.

We'll discuss each of these in detail below, followed by a discussion of risk in digital relationships.

Relationship Integrity

Without integrity, we cannot recognize the other party to the relationship. Consequently, all identity systems manage relationship integrity as a foundational capability. Federated identity systems improve on one-off, often custom identity systems by providing integrity in a way that reduces user management overhead for the organization, increases convenience for the user, and increases security by eliminating the need to create one-off, proprietary solutions. SSI aims to establish integrity with the convenience of the federated model but without relying on an intervening IdP in order to provide autonomy and privacy.

A relationship has two parties, let's call them P1 and P2.1 P1 is connecting with P2 and, as a result, P1 and P2 will have a relationship. P1 and P2 could be people, organizations, or things represented by a website, app, or service. Recognizing the other party in an online relationship relies on being able to know that you're dealing with the same entity each time you encounter them.

In a typical administrative identity system, when P1 initiates a relationship with P2, P2 typically uses usernames and passwords to ensure the integrity of the relationship. By asking for a username to identify P1 and a password to ensure that it's the same P1 as before, P2 has some assurance that they are interacting with P1. In this model, P1 and P2 are not peers. Rather P2 controls the system and determines how and for what it is used.

In a federated flow, P1 is usually called the subject or consumer and P2 is called the relying party (RP). When the consumer visits the RP's site or opens their app, they are offered the opportunity to establish a relationship through an identity provider (IdP) whom the RP trusts. The consumer may or may not have a relationship with an IdP the RP trusts. RPs pick well-known IdPs with large numbers of users to reduce friction in signing up. The consumer chooses which IdP they want to use from the relying party's menu and is redirected to the IdP's identity service where they present a username and password to the IdP, are authenticated, and redirected back to the RP. As part of this flow, the RP gets some kind of token from the IdP that signifies that the IdP will vouch for this person. They may also get attributes that the IdP has stored for the consumer.2

In the federated model, the IdP is identifying the person and attesting the integrity of the relationship to the RP. The IdP is a third party, P3, who acts as an intervening administrative authority. Without their service, the RP may not have an alternative means of assuring themselves that the relationship has integrity over time. On the other hand, the person gets no assurance from the identity system about relationship integrity in this model. For that they must rely on TLS, which is visible in a web interaction, but largely hidden inside an app on a mobile device. P1 and P2 are not peers in the federated model. Instead, P1 is subject to the administrative control of both the IdP and the RP. Further, the RP us subject to the administrative control of the IdP.

In SSI, a relationship is initiated when P1 and P2 exchange decentralized identifiers (DID). For example, when a person visits a web site or app, they are presented with a connection invitation. When they accept the invitation, they use a software agent to share a DID that they created. In turn, they receive a DID from the web site, app, or service. We call this a "connection" since DIDs are cryptographically based and thus provide a means of both parties mutually authenticating. The user experience does not necessarily surface all this activity to the user. To get a feel for the user experience, run through the demo at Connect.me3.

In contrast to the federated model, the participants in SSI mutually authenticate and the relationship has integrity without the intervention of a third party. By exchanging DIDs both parties have also exchanged public keys. They can consequently use cryptographic means to ensure they are interacting with the party who controls the DID they received when the relationship was initiated. Mutual authentication, based on self-initiated DIDs provides SSI relationships with inherent integrity. P1 and P2 are peers in SSI since they both have equal control over the relationship.

In addition to removing the need for intermediaries to vouch for the integrity of the relationship, the peer nature of relationships in SSI also means that neither party has access to the authentication credentials of the other. Mutual authentication means that each party manages their own keys and never shares the private key with another party. Consequently, attacks, like the recent attack on Twitter accounts can't happen in SSI because there's no administrator who has access to the credentials of everyone using the system.

Relationship Lifespan

Whether in the physical world or digital, relationships have lifespans. Some relationships are long-lived, some are short-term, and others are ephemeral, existing only for the duration of a single interaction. We typically don't think of it this way, but every interaction we have in the physical world, no matter for what purpose or how short, sets up a relationship. So too in the digital world, although our tools, especially as people online, have been sorely lacking.

I believe one of the biggest failings of modern digital identity systems is our failure to recognize that people often want, even need, short-lived relationships. Think about your day for a minute. How many people and organizations did you interact with in the physical world4 where you established a permanent relationship? What if whenever you stopped in the convenience store for a cup of coffee, you had to create a permanent relationship with the coffee machine, the cashier, the point of sale terminal, and the customers in line ahead and behind you? Sounds ridiculous. But that's what most digital interactions require. At every turn we're asked to establish permanent accounts to transact and interact online.

There are several reasons for this. The biggest one is that every Web site, app, or service wants to send you ads, at best, or track you on other sites, at worst. Unneeded, long-lived relationships are the foundation of the surveillance economy that has come to define the modern online experience.

There are a number of services I want a long-lived relationship with. I value my relationships with Amazon and Netflix, for example. But there are many things I just need to remember for the length of the interaction. I ordered some bolts for a car top carrier from a specialty place a few weeks ago. I don't order bolts all the time, so I just want to place my order and be done. I want an ephemeral relationship. The Internet of Things will increase the need for ephemeral relationships. When I open a door with my digital credential, I don't want the hassle of creating a long-term relationship with it; I just want to open the door and then forget about it.

Digital relationships should be easy to set up and tear down. They should allow for the relationship to grow over time, if both parties desire. While they exist, they should be easily managable while providing all the tools for the needed utility. Unless there's long term benefit to me, I shouldn't need to create a long term relationship. And when a digital relationship ends, it should really be over.

Relationship Utility

Obviously, we don't create digital relationships just so we can authenticate the other party. Integrity is a necessary, but insufficient, condition for an identity system. This is where most identity models fall short. We can understand why this is so given the evolution of the modern Web. For the most part, user-centric identity really took off when the web gave people reasons to visit places they didn't have a physical relationship with, like an ecommerce web site. Once the identity system had established the integrity of the relationship, at least from the web site's perspective, we expected HTTP would provide the rest.

Most Identity and Access Management systems don't provide much beyond integrity except possibly access control. Once Facebook has established who you are, it knows just what resources to let you see or change. But as more and more of our lives are intermediated by digital services, we need more utility from the identity system than simple access control. The most that an IdP can provide in the federated model is integrity and, perhaps, a handful of almost-always-self-asserted attributes in a static, uncustomizable schema. But rich relationships require much more than that.

Relationships are established to provide utility. An ecommerce site wants to sell you things. A social media site wants to show you ads. Thus, their identity systems, built around the IAM system, are designed to do far more than just establish the integrity of the relationship. They want to store data about you and your activities. For the most part this is welcome. I love that Amazon shows me my past orders, Netflix remembers where I was in a series, and Twitter keeps track of my followers and past tweets.

The true identity system is much, much larger and specialized than the IAM portion. All of the account or profile data these companies use is properly thought of as part of the identity system that they build and run. Returning to Joe Andrieu:

Identity systems acquire, correlate, apply, reason over, and govern [the] information assets of subjects, identifiers, attributes, raw data, and context.

Regardless of whether or not they outsource the integrity of their relationships (and notice that none of the companies I list above do), companies still have to keep track of the relationships they have with customers or users in order to provide the service they promise. They can't outsource this to a third party because the data in their identity system has evolved to suit the needs of the specific relationship. We'll never have a single identity that serves all relationships because they are unique contexts that demand their own identity data. Rip out the identity system from a Netflix or Amazon and it won't be the same company anymore.

This leads us to a simple, but important conclusion: You can't outsource a relationship. Online apps and services decorate the relationship with information they observe, and use that information to provide utility to the relationships they administer. Doing this, and doing it well is the foundation of the modern web.

Consequently, the bad news is that SSI is not going to reduce the need for companies to build, manage, and use identity systems. Their identity systems are what make them what they are—there is no "one size fits all" model. The good news is that SSI makes online relationships richer. Relationships are easier and less expensive to manage, not just for companies, but for people too. Here's some of the ways SSI will enhance the utility of digital relationships:

  • Richer, more trustworthy data—Relationships change over time because the parties change. We want to reliably ascertain facts about the other party in a relationship, not just from direct observation, but also from third parties in a trustworthy manner to build confidence in the actions of the other party within a specific context. Verifiable credentials, self-issued or from others, allow relationships to be enhanced incrementally as the relationships matures or changes.
  • Autonomy and choice through peer relationships—Peer relationship give each party more autonomy than traditional administrative identity systems have provided. And, through standardization and substitutability, SSI gives participants choice in what vendors and agents they employ to manage their relationships. The current state of digital identity is asymmetric, providing companies with tools that are difficult or unwieldy for people to use. People like Doc Searls and organizations like Project VRM and the Me2B Alliance argue that people need tools for managing online relationships too. SSI provides people with tools and autonomy to manage their online relationships with companies and each other.
  • Better, more secure communications—DID exchange provides a private, secure messaging channel using the DIDComm protocol. This messaging channel is mutually recognized, authenticated, and encrypted.
  • Unifying, interoperable protocol for data transmission—DIDs and Verifiable Credentials, and DIDComm provides a standardized, secure means of interaction. Just like URLs, HTML, and HTTP provided for an interoperable web that led to an explosion of uses, the common protocol of SSI will ensure everyone benefits from the network effects.
  • Consistent user experience—Similarly, SSI provides a consistent user experience, regardless of what digital wallet people use. SSI's user experience is centered on relationships and credentials, not arcane addresses and keys. The user experience mirrors the experience people have of managing credentials in the physical world.
  • Support for ad hoc digital interactions—The real world is messy and unpredictable. SSI is flexible enough to support the various ad hoc scenarios that the world presents us and supports sharing multiple credentials from various authorities in the ways the scenario demands.

These benefits are delivered using an architecture that provides a common, interoperable layer, called the identity metasystem, upon with anyone can build the identity systems they need. A ubiquitous 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 friction, decrease cognitive overload, and make online interactions more private and secure.

Relationships, Risk, and Trust

Trust is a popular term in the SSI community. People like Steve Wilson and Kaliya Young rightly ask about risk whenever someone in the identity community talks about trust. Because of the proximity problem, digital relationships are potentially risky. One of the goals of an identity system is to provide evidence that can be used in the risk calculation.

In their excellent paper, Risk and Trust, Nickel and Vaesen define trust as the "disposition to willingly rely on another person or entity to perform actions that benefit or protect oneself or one’s interests in a given domain." From this definition, we see why crypto-proponents often say "To trust is good, but to not trust is better." The point being that not having to rely on some other human, or human-mediated process is more likely to result in a beneficial outcome because it reduces the risk of non-performance.

Relationships imply a shared domain, context, and set of activities. We often rely on third parties to tell us things relevant to the relationship. Our vulnerability, and therefore our risk, depends on the degree of reliance we have on another party's performance. Relationships can never be "no trust" because of the very reasons we create relationships. Bitcoin, and similar systems, can be low or no trust precisely because the point of the system is to reduce the reliance on any relationship at all. The good news, is the architecture of the SSI stack significantly limits the ways we must rely on external parties for the exchange of information via verifiable credentials and thus reduces the vulnerability of parties inside and outside of the relationship. The SSI identity metasystem clearly delineates the parts of the system that are low trust and those where human processes are still necessary.

The exchange of verifiable credentials can be split into two distinct parts as shown in the following diagram. SSI reduces risk in remote relationships using the properties of these two layers to combine cryptographic processes with human processes.

SSI Stack
SSI Stack (click to enlarge)

The bottom layer, labeled Identity Metasystem, comprises two components: a set of verifiable data repositories for storing metadata about credentials and a processing layer supported by protocols and practices for the transport and validation of credentials. Timothy Ruff uses the analogy of shipping containers to describe the identity metasystem. Verifiable credentials are analogous to shipping containers and the metasystem is analogous to the shipping infrastructure that makes intermodal shipping so efficient and secure. The Identity Metasystem provides a standardized infrastructure that similarly increases the efficiency and security of data interchange via credentials.

The top layer, labeled Identity Systems, is where people and organizations determine what credentials to issue, determine what credentials to seek and hold, and determine which credentials to accept. This layer comprises the individual credential exchange ecosystems that spring up and the governance processes for managing those credential ecosystems. In Timothy's analogy to shipping containers, this layer is about the data—the cargo—that the credential is carrying.

The Identity Metasystem allows verifiable credentials can be cryptographically checked to ensure four key properties that relate to the risk profile.

  1. Who issued the credential?
  2. Was the credential issued to the party presenting it?
  3. Has the credential been tampered with?
  4. Has the credential been revoked?

These checks show the fidelity of the credential and are done without the verifier needing a relationship with the issuer. And because they're automatically performed by the Identity Metasystem, they significantly reduce the risk related to using data transferred using verifiable credentials. This is the portion of credential exchange that could be properly labeled "low or no trust" since the metasystem is built on standards that ensure the cryptographic verifiability of fidelity without reliance on humans and human-mediated processes.

The upper, Identity Systems, layer is different. Here we are very much relying on the credential issuer. Some of the questions we might ask include:

  • Is the credential issuer, as shown by the identifier in the credential, the organization we think they are?
  • Is the organization properly accredited in whatever domain they're operating in?
  • What data did the issuer include in the credential?
  • What is the source of that data?
  • How has that data been processed and protected?

These questions are not automatically verifiable in the way we can verify the fidelity of a credential. They are different for each domain and perhaps different for each type of relationship based on the vulnerability of the parties to the data in the credential and their appetite for risk. Their answers depend on the provenance of the data in the credential. We would expect to see credential verifier's perform provenance checks by answering these and other questions during the process they use to establish trust in the issuer. Once the verifier has established this trust, the effort needed to evaluate the provenance of the data in a credential should cease or be greatly reduced.

As parties in a relationship share data with each other, the credential verifier will spend effort evaluating the provenance of issuers of credentials they have not previously evaluated. Once that is done, the metasystem will provide fidelity checks on each transaction. For the most part, SSI does not impose new ways of making these risk evaluations. Rather, most domains already have processes for establishing the provenance of data. For example, we know how to determine if a bank is a bank, the accreditation status of a university, and the legitimacy of a business. Companies with heavy reliance on properties of their supply chain, like pharmaceuticals, already have processes for establishing the provenance of the supply chain. For the most part, verifiable credential exchange will faithfully present digital representations of the kinds of physical world processes, credentials, and data we already know how to evaluate. Consequently, SSI promises to significantly reduce the cost of reducing risk in remote relationships without requiring wholesale changes to existing business practices.

Conclusion

Relationships have always been the reason we created digital identity systems. Our historic focus on relationship integrity and IAM made modern Web 2.0 platforms and services possible, but has limited use cases, reduced interoperability, and left people open to privacy and security breaches. By focusing on peer relationships supported by an Identity Metasystem, SSI not only improves relationships integrity but also better supports flexible relationship lifecycles, more functional, trustworthy relationship utility, and provides tools for participants to correctly gauge, respond to, and reduce risks inherent in remote relationships.


Notes

  1. For simplicity, I'm going to limit this discussion to two-party relationships, not groups.
  2. I've described federation initialization very generally here and left out a number of details that distinguish various federation architectures.
  3. Connect.me is just one of a handful of digital wallets that support the same SSI user experience. Others vendors include Trinsic, ID Ramp, and eSatus AG.
  4. Actually, imagine a day before Covid-19 lockdown.

Photo Credit: Two People Holding Hands from Albert Rafael (Free to use)


What is SSI?

Girl On A Bicycle


A few days ago I was in a conversation with a couple of my identerati friends. When one used the term "SSI", the other asked him to define it since there were so many systems that were claiming to be SSI and yet were seemingly different. That's a fair question. So I thought I'd write down my definition in hopes of stimulating some conversation around the topic.

I think we've arrived at a place where it's possible to define SSI and get broad consensus about it. SSI stands for self-sovereign identity, but that's not really helpful since people have different ideas about what "sovereign" means and what "identity" means. So, rather than try to go down those rabbit holes, let's just stick with "SSI."1

SSI has the following properties:

  • SSI systems use decentralized identifiers (DIDs) to identify people, organizations, and things. Decentralized identifiers provide a cryptograhic basis for the system and can be employed so that they don't require a central administrative system to manage and control the identifiers. Exchanging DIDs is how participants in SSI create relationships, a critical feature.
  • SSI participants use verifiable credentials exchange to share information (attributes) with each other to strengthen or enrich relationships. The system provides the means of establishing credential fidelity.
  • SSI supports autonomy for participants. The real value proposition of SSI is autonomy—not being inside someone else's administrative system where they make the rules in a one sided way. Autonomy implies that participants interact as peers in the system. You can build systems that use DIDs and verifiable credentials without giving participants autonomy.

Beyond these there are lots of choices system architects are making. Debates rage about how specifically credential exchange should work, whether distributed ledgers are necessary, and, if so, how should they be employed. But if you don't use DIDs and verifiable credentials in a way that gives participants autonomy and freedom from intervening administrative authorities, then you're not doing SSI.

As a consequence of these properties, participants in SSI systems use some kind of software agent (typically called a wallet for individuals) to create relationships and exchange credentials. They don't typically see or manage keys or passwords. And there's no artifact called an "identity." The primary artifacts are relationships and credentials. The user experience involves managing these artifacts to share attributes within relationships via credential exchange. This user experience should be common to all SSI systems, although the user interface and what happens under the covers might be different between SSI systems or vendors on those systems.

I'm hopeful that, as we work more on interoperability, the implementation differences will fade away so that we have a single identity metasystem where participants have choice about tools and vendors. An identity metasystem is flexible enough to support the various ad hoc scenarios that the world presents us and will support digital interactions that are life-like.


Notes

  1. This is not to say I don't have opinions on what those words mean in this context. I've written about "sovereign" in Cogito, Ergo Sum, On Sovereignty, and Self Sovereign is Not Self Asserted.

Photo Credit: Girl On A Bicycle from alantankenghoe (CC BY 2.0)


Held Hostage

Hostages being freed

Platforms service two-sided markets. We're all familiar with platform companies like Uber, AirBnB, Monster, eBay, and many others. Visa, Mastercard, and other credit card systems are platforms. Platforms are a popular Web 2.0 business model because they create an attractive way for the provider to extract service fees from one side, and sometimes both sides, of the market. They can have big network effects and tend to natural monopolies.

Platforms provide several things that make them valuable to users:

  1. They provide a means of discovering relevant service providers.
  2. They facilitate the transaction.
  3. They help participants make the leap over the trust gap, as Rachel Botsman puts it.

Like compound interest, small advantages in any of these roles can have huge effects over time as network effects exploit the advantage to drive participants to a particular platform. This is happening rapidly during the recent crisis in food delivery platforms.

A recent New York Times article, As Diners Flock to Delivery Apps, Restaurants Fear for Their Future, highlights the power that platforms have over their users:

But once the lockdowns began, the apps became essentially the only source of business for the barroom restaurant he ran with a partner, Charlie Greene, in Columbus, Ohio. That was when the fees to the delivery companies turned into the restaurant’s single largest cost—more than what it paid for food or labor.

Pierogi Mountain’s primary delivery company, Grubhub, took more than 40 percent from the average order, Mr. Majesky’s Grubhub statements show. That flipped his restaurant from almost breaking even to plunging deeply into the red. In late April, Pierogi Mountain shut down.

"You have no choice but to sign up, but there is no negotiating," Mr. Majesky, who has applied for unemployment, said of the delivery apps. "It almost turns into a hostage situation."

The standard response to these problems from people is more regulation. The article discusses some of the attempts cities, counties, and states have made to rein in the fees that food delivery platforms are charging.

A better response is to create systems that don't require an intermediary. Sovrin provides an identity metasystem that provides a univeral trust framework for building identity systems that can serve as the foundation for creating markets without intermediaries. When Sovrin has a token it can even facilitate the transaction.

Defining a marketplace requires determining the protocol for interaction between participants and creating the means of discovery. The protocol might be simple or complex depending on the market and could be built on top of DIDComm, or even ride on top of a verifiable credential exchange. There might be businesses that provide discovery, but they don't intermediate, they sit to the side of the interaction providing a service. For example, I might provide a service that allows a restaurant to define it's menu, create a shopping cart, and provide for discovery, but I'm easily replacable by another provider because the trust interaction and transaction are happening via a protocol built on a universal metasystem.

Building markets without intermediaries greatly reduces the cost of participating in the market and frees participants to innovate. And it does it without introducing regulation that stifles innovation and locks in incumbents by making it difficult for new entrants to comply. I'm hopeful that Sovrin and related technology will put an end to the platform era of the Internet by supporting greater, trustworthy autonomy for all participants.


Photo Credit: BE024003 from Tullio Saba (Public Domain Mark 1.0)


Get the Bike that Speaks to You

My latest bike, a Trek Supercommuter+ 8S

My middle son Jacob recently asked me about a number of gravel bikes in the $1000-1500 price range. In looking them over, they all had aluminum frames, carbon forks, and mechanical disk brakes. The other components differed a little from bike to bike but nothing stood out. All were from major manufacturers.

How to choose? I've bought a number of bikes over the years (I've only got three right now). I told Jacob that one thing made all the difference in choosing: the test ride. I've often been taken in by the specs on a bike, only to ride it and find that it felt dead. The bikes I've purchased spoke to me. They felt like they were alive, a part of me, and I wanted to ride them. Bottom line: buy the bike you fall in love with.

The implication of this is to buy from a local shop since you need to test ride and they have the bikes. Establishing a relationship with the shop is useful for service and advice too. They often will discount service on bikes they sold. Most bike shops have knowledgeable staff and can help you with everything from accessories to good riding trails. You might pay a bit more, but I think it's worth it.


Using Sovrin for Age Verification

Under 25? Please be prepared to show proof of age when buying alcohol

Kamea, a member of the Sovrin Telegram channel asked this question:

I’m looking for our users to sign up with a Sovrin account, validate their identity, then use it to verify age and passport country on our network using a zk proof so we don’t have to handle any personal data.

There are actually two different things here and it's useful to separate them.

First, there's no such thing as a "Sovrin account". SSI doesn't have accounts, it has relationships and credentials. But your company will have accounts. The way that works is you set up an enterprise agency on your side to create a relationship (technically a peer DID exchange) with anyone who wants to create an account with you. After they establish that relationship, you can begin to collect attributes you need to provide service. Some of those will be self asserted and some you might require credentials depending on your use case.

The second thing is determining which credentials you want to require. If your requirement is an attested proof of age, then there could be several choices. In an ideal world, people would have a number of those (e.g. national ID, drivers license, passport, bank KYC, etc.) In the current world, you might have to partner with someone like Onfido or another KYC company do give people a way to get their age verified and a credential to use in proving it. Once people have this credential, however, it gives them the means of proving their age (and likely other attributes) anywhere, not just to you.

Kamea mentioned the desire to avoid handling personal data and this is a good solution for that. The proof would record that the person was over 18 and their country of residence without seeing or recording any other information.

I recommend running through the demo at Connect.me to see how all this could work. There are a number of vendors who can supply help with enterprise agencies and consulting on how to set this up in your organization.


Photo Credit: Under 25? Please be prepared to show proof of age when buying alcohol from Gordon Joly (CC BY-SA 2.0)


The Impact of a Network of Networks on Censorship

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

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.

Consequences

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.


Notes

  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 SSIMeetup.org.

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.