Decentralized architectures require that care is taken in each component or layer to ensure that the resulting system will not contain hidden weaknesses. That doesn't just apply to the system itself, but also to the ways it is governed. And all decentralized systems are governed. The governing might be ad hoc or hidden, but it's there.

I've written a lot about distributed ledgers, Sovrin, governance, and decentralization over the past several years. Here's a partial list:

• Decentralization and Distributed Ledgers (Aug 2016)
• An Internet for Identity (Aug 2016)
• The Case for Decentralized Identity (Aug 2017)
• Is Sovrin Decentralized? (Sep 2017)
• Decentralized Governance in Sovrin (Feb 2018)
• Building Your Business on Sovrin: Domain-Specific Trust Frameworks (Mar 2018)
• Coherence and Decentralized Systems (Apr 2018)
• The Sovrin Foundation (Jul 2018)

You can see this topic has been on my mind. The remainder of this post is going to focus on the decentralized nature of the Sovrin Network.

As a hybrid system, the Sovrin Network benefits both from having a blockchain-based ledger and from having formal governance. Both of these are important for Sovrin to thrive and meet its objectives. And, contrary to what you might think, governance helps in achieving a public, decentralized system that has real utility.

The Sovrin Network

Our goal is for the Sovrin Network to be an open, public, decentralized utility for digital identity. Those three adjectives deserve some explanation:

• open—The Sovrin network is based on the open-source Hyperledger Indy project. That is important, but it's not sufficient. The governance of the Sovrin Network should also be open. This extends to decisions about the code, who runs it, and the features that it enables.
• public—Anyone should be able to access and use Sovrin for any purpose that it supports. Public access is a foundational element for self-sovereignty because it avoids gatekeepers that might censor some transactions. This applies not only to reading information from the ledger, but also authoring ledger transactons.
• decentralized—no single entity should represent a single point of failure. This doesn't just apply to the availability of the network, but also the ability of people to use the network.

The Sovrin protocol is layered as shown in the following diagram.

Each of these layers builds upon the one below. Consequently, it's important that each layer have appropriate support for decentralized operation to ensure that the network supports self-sovereignty.

The Ledger Layer

The Sovrin Network is based on a distributed ledger. The ledger is a small, but critical, part of Sovrin's overall functionality. Every identity system needs a way to discover what identifiers mean—if you get an identifier, you want to look it up. For identity systems, that has traditionally been implemented as a centralized database controlled by a single entity. For Sovrin to be decentralized, it must have a decentralized means of discovery. The Sovrin ledger provides that.

Sovrin's ledger is a hybrid combining known validator nodes with public access. Because of this architecture, Sovrin is difficult to categorize in the various discussions of permissioned and permissionless blockchain systems. One common refrain is "blockchains don't need trust (governance) frameworks." Another goes "the point of blockchain is to avoid governance." Those might be true in some architectures, but they don't apply to Sovrin, as I'll discuss below.

Sovrin never stores personally identifying information, encrypted or not, on the ledger, unlike many other blockchain-based identity systems. Rather Sovrin uses the ledger for Decentralized Identifiers (DIDs), schema definitions, credential definitions, and revocation registries. Without a ledger to store these, Sovrin would have a single point of failure for these critical objects. For more information, see What Goes on the Ledger (PDF).

Objects like a DIDs are written to the ledger by transaction authors and validated by transaction validators. These functions are separate. Because the Sovrin Network is public, anyone can be a transaction author. But only organizations who function as Sovrin Stewards can validate transactions. Validation is done using a modified Redundant Byzantine Fault Tolerance algorithm implemented as Indy Plenum.

If the ledger is the basis for decentralized discovery in Sovrin, then we should ensure that no single organization controls the ledger and that it is protected from being taken down or corrupted by a single or even a few entities. Sovrin is designed to be censorship resistant. No company or special interest can control who can use the protocol. Sovrin is available for any application or purpose. And the priority of transaction validation is fair. Public authorship of Sovrin transactions on a ledger represents the best means available to combating censorship.

Validation on the Sovrin ledger is based on a known set of nodes run by the Stewards. This architecture was chosen to reduce the resource usage (and hence, cost) of the ledger. We have designed the ledger and its governance to ensure that the ledger is public, open, and decentralized despite the presence of known validators.

One key idea in decentralized systems is that different parts of the system are under the control of different organizations. Censorship resistance requires that even though Stewards must meet certain requirements to participate, we must still assume that any node might be hostile because of a hack or other circumstances beyond the control of the Steward. A distributed ledger provides this important property and is, consequently, the right data structure for this.

In addition, using a blockchain ensures that multiple organizations are responsible for a shared space for discovery. Losing one or even several Stewards would not impact the ability of people to manage and use their identifiers on Sovrin. One of Sovrin's guiding principles is diversity of validators to protect this vital function.

Some might be concerned that Sovrin Foundation itself holds a special place and thus represents a single point of failure. While it's true that the Foundation administers the governance framework and manages the open source project, the Foundation does not run the Sovrin Network. Consequently, it could cease to exist and the network would continue operating. In the case of the ledger itself, the Stewards would keep operating the Network and re-organize. The open source project would continue, as open source projects do, because the code is available to and maintained by people rather than a specific organization.

Because transaction authoring is a public function, the use of a ledger also ensures that people can access, write, and update identifiers without being subject to gatekeepers. Even if those gatekeepers are friendly, they might restrict access to certain people, certain groups, or certain jurisdictions due to a hack or other circumstances beyond the control of the gatekeeper.

The Agent Layer

Agents are a core element of the Sovrin architecture. Since Sovrin does not store personally identifying information on the ledger, people need a place to hold, manage, and use keys and credentials. Agents fill that role. Sovrin's architecture supports both cloud and device agents. Most people will have more than one. Sovrin identity owners usually have at least two agents, one on a device and one in the cloud The device agent is connected to an app and contains a wallet for storing keys and credentials.

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

Clearly device agents and wallets are not centralized because they store their keys and credentials on the device. The cloud agent can be run by a service provider called an agency or self-hosted. Most people will opt to use an agency. There can be multiple agencies and agent operation is standardized so that users can switch agencies.

Further, the agency does not have access to what's in the agent. There are no master keys. So, barring a code problem that opens a security hole, there's no honey pot. We believe agent code should be open source to reduce security risk by getting as many eyes on the problem as possible.

The peer-to-peer architecture of agents and their availability from multiple agencies creates a decentralized system for storing, managing, and using keys and credentials. This not only is a boon to identity owner privacy and autonomy, it also ensures that Sovrin can scale to trillions of relationships.

The Credential Exchange Layer

The top layer in Sovrin is where credential exchange happens. Credential exchange is central to how Sovrin works. Sovrin does not have "identity providers" because anyone can be the source of their own identity. Your digital identity is made from credentials from multiple sources. I call this multi-source identity. You might have a Sovrin-based relationship¹ with your bank. They could provide a Sovrin credential stating you're a customer and maintain a certain balance. Similarly, you could have a relationship with your employer and an employer-issued credential stating you're an employee. And you likely have a relationship with the state, and credentials they issue representing your birth certificate or drivers license. The list goes on. You could have hundreds of relationships and associated credentials in your wallet. You can use any of these, in multiple configurations, to prove things about yourself (with minimal disclosure) to any other party who accepts them.

Credential exchange is done peer to peer via agents. Agents use the ledger in various ways in credential exchange. Issuers use it to write public DIDs, credential definitions, schema, and revocation registries. Credentials holders use the ledger to prove a credential they're presenting hasn't been revoked, among other things. Verifiers use the ledger to check the public DIDs of the credential issuer and look up schema and credential definitions. Because of the ledger, credential issuers don't see when a verifier verifies a credential, a further boon to identity owner privacy.

Sovrin's trust model for verifiable claims has five important and desirable properties that all underscore its support for decentralization and personal autonomy:

1. Credentials are decentralized and contextual. There is no central authority for all credentials. Every party can be an issuer, an owner, and a verifier. The system can be adapted to any country, any industry, any community, any set of credentials, or any set of trust relationships.
2. Credential issuers decide on what data is contained in their credentials. Sovrin allows anyone to write credential schemas to the ledger. Anyone can create a credential definition based on any of these schemas.
3. Verifiers make their own trust decisions about which credentials to accept—there's no central authority who determines what credentials are important or which are used for what purpose.
4. Verifiers do not need to contact issuers to perform verification—that's what the ledger is for. Credential verifiers (the people or organizations relying on a credential) don't need to have any technical, contractual, or commercial relationship with credential issuers (the people or organizations making the credential).
5. Credential holders are free to choose which credentials to carry and what information to disclose. People and organizations are in control of the credentials they hold (just as they are with physical credentials) and determine what to share with whom.

Decentralized credential exchange is not new—we've been doing it in the physical world for centuries. But it is new online. Decentralized credential exchange gives people and organizations the freedom and autonomy to create authorization regimes that meet their particular needs. Furthermore, credential holders have autonomy and choice in whether to participate. The result is a flexible system that covers thousands of use cases while supporting choice and privacy for identity owners.

Decentralized, Self-Sovereign Identity

The architecture of Sovrin, at all three levels of operation, creates a decentralized identity system that has the same decentralized properties as the Internet:

• No one owns it
• Everyone can use it
• Anyone can improve it

The lack of a decentralized, heterarchical, and interoperable identity system has led to an environment where the services most people use online are a lot more centralized than the Internet they exist upon. Sovrin corrects this by providing the means for people to exercise greater autonomy and freedom. Decentralized identity is the key to creating a more decentralized Web—a Web that flexibly supports the kind of ad hoc interactions people have with each other all the time in real life.

Without peer-based interactions and public access, Sovrin would not be self-sovereign. By supporting control of identity information by people, Sovrin creates a self-sovereign identity environment. Self-sovereignty requires that the parties to the credential transaction behave as peers. In traditional identity systems the rights of the so-called "identity subject" are subordinate to those of the identity provider. In Sovrin, every player independently determines the role they'll play, who they trust, and what they will believe.

Notes

1. When I say "relationship" that means that both sides have an agent and have exchanged DIDs to create a pairwise pseudonymous relationship.

Photo Credit: Bees in a bee hive from USDA (CC BY 2.0)