Decentralized Governance in Sovrin

Marc Hulty defines governance as "the processes of interaction and decision-making among the actors involved in a collective problem that lead to the creation, reinforcement, or reproduction of social norms and institutions." From this we can conclude that everything gets governed, the question is whether governance is ad hoc or formal, explicit or implicit.

One of the ironies of decentralized systems is that they require better governance than most centralized systems. Centralized systems are often governed in an ad hoc way because the central point of control can easily tell all participants what to do. Decentralized systems, on the other hand, must coordinate across multiple parties, all acting independently in their own self-interest. This means that the rules of engagement and interaction must be spelled out and agreed to ahead of time, with incentives, disincentives, consequences, processes, and procedures made clear.

The Internet is an excellent example of this. All the computers that connect to the Internet, along with those that route messages between nodes, follow a set of procedures determined ahead of time that cannot be ignored by participants without loss of functionality. These procedures are called protocols and they are embodied in the code that participants in the network—both edge nodes and routers—execute.

Blockchain systems are no different. Their interactions are wholly or partially governed by protocols embodied in code. But these protocols are not emergent properties of the blockchain, rather they are designed by humans who write the code and agreed to by the humans who execute it. Without the design and agreement of humans, the blockchain does not function.

The Sovrin blockchain is a good example. There are two primary components of how Sovrin operates: the design of the protocols and the operation of the ledger. We can ask governance questions about each.

Sovrin's code is open source—specifically it is the Hyperledger Indy project under the umbrella of the Linux Foundation. This means developers from around the world collaborate to design and build the code that makes Sovrin work. Their decisions are governed in the way of most open source projects: rough consensus and running code with pull requests accepted by a core set of developers who manage the code base. Code embodies the rules that make up the Sovrin protocol. Since the protocol is a critical component of Sovrin governance, how decisions are made about the code is a key component of ensuring Sovrin is governed well.

But with the Sovrin blockchain there is another kind of governance that is not embodied in the code. Sovrin is built on a public permissioned blockchain. This means that anyone can use the Sovrin ledger, but consensus is achieved by a known set of validator nodes. Validators perform a similar function on a permissioned ledger than miners perform on a permissionless ledger—ensuring that each copy of the ledger records the same data in the same order1. Since Sovrin’s validators are part of a known group, we should also examine how this group of validators is selected, organized, and governed.

Decisions about how code is architected, which code is run by validator nodes, and how those nodes operate are made in accordance with the Sovrin Trust Framework, a document that specifies how the Sovrin Network is governed. The Trust Framework is Sovrin’s constitution, defining the operation and organization of the network, and is where the final authority for the Sovrin Network lies. In fact, Sovrin can be said to have a constitutional governance model. The Sovrin Foundation is an international, non-profit organization that represents the collective interests of all Sovrin identity owners. Sovrin Foundation exists to administer the Trust Framework. The Sovrin Foundation clearly and openly identifies the actors in decisions and the processes they use to reach those decisions and ensures they are made consistent with the trust framework.

Sovrin’s Trust Framework is based on a set of shared goals consistent with establishing a global public utility for privacy-respecting, self-sovereign identity. In One from Many: VISA and the Rise of the Chaordic Organization, Dee Hock writes:

In the constructive sense of the word, governance can be based only on clarity of shared intent and trust in expected behavior, heavily seasoned with common sense, tolerance, and caring for others as fellow human beings. This is not to say that contracts, laws, and regulations do not serve a purpose. Rather it is to point out that they can never achieve the mechanistic certainty and control we crave. Rules and regulations, laws and contracts, can never replace clarity of shared purpose and clear, deeply held principles about conduct in pursuit of that purpose.

In the case of Sovrin, that shared purpose and deeply held principles are contained in the Sovrin Trust Framework. The Trust Framework lays out the purpose of Sovrin as providing a global public utility for self-sovereign identity that adheres to a set of thirteen principles2:

  • Independence and Self-Sovereignty
  • Guardianship
  • Diffuse Trust
  • Web of Trust
  • System Diversity
  • Interoperability
  • Portability
  • Security by Design
  • Privacy by Design
  • Accountability
  • Openness
  • Identity for All
  • Collective Best Interest

Sovrin embraced these principles to meet the needs of identity owners and protect their data, privacy, and autonomy. These principles guide both the technical development of the Sovrin code and the operational rules for stewards, the trusted organizations who operate validator nodes and connect to the ledger in a transparent way.

Some have pointed to the permissioned structure and the existence of the foundation as a reason for distrusting whether it is truly a decentralized public network. To those people I say, “Look at the Trust Framework and tell me where it falls short.” Often this question is just a knee-jerk reaction to how Sovrin splits governance between code and agreement. There’s nothing magic about code when it comes to governance. It can automate things but it has no special properties when it comes to resisting accumulation of power or autocratic tendencies. Even in permissionless blockchains, change is proposed by the developers and accepted (or not) by miners. These are people coming to agreement or not based on the principles they hold dear.

Sovrin’s Trust Framework makes those principles explicit by providing a documented public agreement (consensus) about them. The process for amending Sovrin’s Trust Framework is also public. The stewards running validator nodes agree (or not) by accepting or rejecting changes. This is the same process we (and other public blockchains) use for managing code changes. It ensures that Sovrin continues to be public and open to all. There is no point of centralization in Sovrin because no single entity can force other participants to bend to that entity’s will. Sovrin is technically, politically, and geographically decentralized to achieve diffuse trust, which enables diffuse control.

Others might wonder how the Trust Framework governs the code that Sovrin runs. While it’s true that Sovrin code is open source and anyone can make contributions, those contributions still have to be accepted by the maintainers of Project Indy to be incorporated in the codebase. Further, the Indy code is not automatically transferred to Sovrin validators to run, but is subject to review by Sovrin’s Technical Governance board and the Stewards themselves.

Those reviews ensure that only code consistent with the Trust Framework is run by validator nodes. These reviews also put appropriate pressure on Project Indy contributors and maintainers to adhere to Sovrin Trust Framework principles, since not doing so could lead to a fork of the project (although not the ledger), with Sovrin developing its own branch of the Indy codebase to protect its interests. Recent events in the blockchain space show that this is not inconceivable, but it would be disruptive and costly to the ultimate success of Project Indy. This neatly aligns incentives between Project Indy and Sovrin. Make no mistake; Sovrin will take decisive action if our principles are threatened.

Participation in Sovrin is open to all. As I wrote in Is Sovrin Decentralized?: anyone can create identifiers. Sovrin does not have "identity providers" because they are entirely unnecessary; identity owners are empowered to carry their own claims. Furthermore, any organization who will publicly agree to the Trust Framework and meets its requirements is welcome to become a Sovrin Steward.

This is the ultimate point: no single entity owns or controls Sovrin, not even the Sovrin Foundation. The Sovrin network is a global public utility that we all own, collectively, just like we all own the Internet. And the governance model of the Trust Framework, along with governance of the open source Hyperledger Indy code run by all Sovrin stewards, has been carefully designed to reflect this. All of this is captured in the Sovrin Trust Framework which is developed and published under an open public process available to all.

The public and open nature of Sovrin supports an unprecedented level of autonomy, privacy, security, and control by the people and organizations using Sovrin. We welcome you and your organization to join us in this important work.


Endnotes:

  1. There are many reasons for using a permissioned model, as spelled out in the recent Sovrin Foundation white paper, but one of the most important is cost. Simply put, if the cost of using a ledger can be kept very low, then it will enable people to use a different cryptographic identifier for each relationship, thus reducing correlation risk and increasing privacy. Any blockchain-based identity system must be carefully architected to take advantage of the blockchain without sacrificing the privacy of the participants in the system. If writing transactions to the blockchain is expensive, as it typically is in permissionless ledgers, people are more likely to reuse identifiers (or hashes) and increase the risk of unwanted correlations.
  2. See Section 2 of the Trust Framework for a detailed discussion of these principles.

Thanks to Steve Fulling, Drummond Reed, Timothy Ruff, Jason Law, and Daniel Hardman for helpful discussions on this topic that improved the post and made it more clear.

Photo Credit: Bees and Honeycomb from Phil Windley (CC0)


Announcing the Sovrin Whitepaper

Sovrin Logo

I'm very pleased to announce that the Sovrin whitepaper is now available. The whitepaper pulls together in one place detailed information about why Sovrin exists, what Sovrin is, and how it will impact nearly every aspect of your online life. Here's the abstract:

Digital identity is one of the oldest and hardest problems on the Internet. There is still no way to use digital credentials to prove our online identity the same way we do in the offline world. This is finally changing. First, the World Wide Web Consortium is standardizing the format of digitally-signed credentials. Secondly, public blockchains can provide decentralized registration and discovery of the public keys needed to verify digital signatures. These two steps pave the way to establish a global public utility for self-sovereign identity—lifetime portable digital identity that does not depend on any central authority and can never be taken away.

The Sovrin Network has been designed exclusively for this purpose, including governance (the Sovrin Foundation and the Sovrin Trust Framework), scalability (validator and observer nodes and state proofs), and accessibility (minimal cost and maximum availability). Most importantly, Sovrin implements Privacy by Design on a global scale, including pairwise pseudonymous identifiers, peer-to-peer private agents, and selective disclosure of personal data using zero-knowledge proof cryptography.

The emergence of this infrastructure can transform at least four major markets: identity and access management, cybersecurity, RegTech, and data integration. To provide economic incentives for credential issuers, owners, and verifiers, the Sovrin protocol will incorporate a digital token designed expressly for privacy-preserving value exchange. The Sovrin token should enable a global marketplace for digital credentials of all types and value levels together with ancillary markets for digital credential insurance and permissioned first party data (direct from the customer).

As you can see, Sovrin will incorporate a native token for exchanging value in identity transactions. We're confident that a protocol token for Sovrin will enable use cases that would be unrealizable without it and drive the network effects for Sovrin adoption.

The whitepaper has been a long time coming. We wanted to get it right and make it as clear and understandable as possible. I'm grateful for my co-managing editor Drummond Reed, a member of the Sovrin Board of Trustees and chair of the Trust Framework working group for his diligent efforts in making this a reality. Countless others participated in discussions, made comments, or proofread various versions of the document. And a special thanks to Monique Heileson for her fine work on graphic design, layout, and illustration.

Internet identity has become synonymous with authentication and that's too bad. Identity in real life is much richer, flexibly and conveniently solving all kinds of thorny problems. Now with Sovrin, we can bring those rich identity transactions online. This paper shows how that happens and why it will impact every sector of the Internet in significant ways. I hope you'll spend some time reading it.


Secure Pico Channels with DIDs

Encryption Flow

Picos are Internet-first actors that are well suited for use in building decentralized soutions on the Internet of Things. See this description of picos for more details.

Picos send an receive messages over channels. Each channel has a non-correlatable identifier, called an ECI. Because picos can have as many channels as they like, you can use them to prevent correlation of the pico's identity without the pico's participation.

When two picos exchange ECIs to create a relationship, we call that a subscription. Wrangler, the pico operating system, supports creating and using subscriptions. Subscriptions allow picos to use peer-to-peer, graph-based interaction patterns. From a given pico's perspective, it has an inbound channel to receive messages (the Rx channel) and an outbound channel to transmit messages (the Tx channel).

Decentralized identifiers (DIDs) are a "new type of identifier intended for verifiable digital identity." DIDs are used with blockchain-based resolution to create decentralized systems. The DIDs for Hyperledger's Indy Project (and consequently the Sovrin network) are derived from, and are thus uniquely associated with, a public-private key pair.

Sean George completed a project this past Fall semester that made modifications to the channel identifier code in the Pico engine to use DIDs as the channel identifier. Because a DID is derived from an associated private key, that means that each channel also has a public-private key pair. Sean's work uses the channel keys to support signing and encrypting channel messages (using Diffie-Helman key exchange).

When a subscription is created between two picos, each pico stores the DID and public key of the incoming Rx channel. Having the public key for the other pico in the subscription allows each pico to securely message the other. There is no way to access the private keys from within KRL to protect them from unauthorized access.

This document on the Pico Labs documentation wiki includes sample KRL rules to shows how to use the built-in engine functions to sign, verify, encrypt, and decrypt messages.

Future work will focus on making the use of these functions easier and more automatic. We will also be working on integrating the Sovrin network with the pico engine. Once the DIDs are registered on the Sovrin ledger, the ledger will be used to verify the public key and outside systems will be able to make use of these capabilities without storing the public key, so long as they know the DID.


Fixing the Five Problems of Internet Identity

Credential Exchange

Andy Tobin has a great presentation that describes five problems of Internet identity. Our claim is that self-sovereign identity, and Sovrin in particular, solve these five problems:

The Proximity Problem—The proximity problem is as old as the familiar cartoon with the caption "On the Internet, nobody knows you're a dog." Because we're not interacting with people physically, our traditional means of knowing who we're dealing with are useless. In their place we've substituted username-password-based authentication schemes. The result is that people's identity information is replicated in multiple identity silos around the Internet.

The Scale Problem—Digital identity currently relies on hubs of identity information. We login using Facebook or Google—huge "identity providers." But for every place that uses one of these big identity providers, there are dozens that will never be part of the social login system. Many businesses are leery of giving up control of their customer information to another business that might decide next week to change things up. I don't think it's any accident that this is the same concern that was holding back online services in the days of CompuServe.

The Flexibility Problem—Many of the so-called "identity solutions" in play today are limited by fixed schema or attribute sets. For example, GOV.UK Verify is a univeral identity assurance system for UK citizens but has a limited data set. And it's unlikely that they could reasonably expand whatever schema they have to cover all use cases, even if they were inclined to do so.

The Privacy Problem—Current digital identity solutions rely on collections of data, often collected without subject's knowledge. The data is replicated over and over again in different systems. Third parties use universal identifiers like Social Security Numbers or phone numbers to correlate identity information, again without the subject's knowledge. They are a 20th century tool that is unsuited to the digital age.

The Consent Problem—And the data in these thousands of identity silos is often shared with others without consent. Sometimes this is done in service of the subject, but often it's done in service of the bottom line of the organization who controls the silo.

The Sovrin Architecture

Sovrin has a unique architecture that addresses these five identity problems. Sovrin is designed to discourage correlation, minimize disclosure, and promote security. Sovrin's architecture is decentralized so that these benefits are available to all. This is achieved through the careful combination of several important technologies:

Decentralized Identifiers (DIDs)DIDs are identifiers intended for self-sovereign, verifiable digital identities. Sovrin uses DIDs in a manner that is pairwise and psedonymous. That is, each relationship is given a new, opaque DID by default to prevent correlation. DIDs point to DID Documents that contain public keys and service endpoints and are thus the means of locating the place the identifier can be used and providing the keys to use it.

Verifiable ClaimsVerifiable claims are the digital equivalent of the various third-party credentials we all carry around in our wallets. These credentials have several important properties:

  • The format and content of the credential is determined by the issuer, not some central authority.
  • Anyone can issue whatever credentials they like.
  • Anyone can choose to accept whatever credentials suit their purposes
  • The credentials say who they're about (using a DID)
  • The credentials say who issued them (using a DID)
  • The credentials are packaged in a way that makes them tamper-evident

The claims can be verified by anyone without any kind of technical integration to or business arrangement with the issuer.

Zero-Knowledge Proofs—Zero knowledge proofs (ZKP) allow a person to prove things about themselves, based on verifiable claims, without having to reveal the claim itself. This reduces the amount of data given out by a person. For example, a ZKP can just reveal that the holder of the claim is over 18 without revealing the date of birth or even their age. ZKPs also provide support for non-correlation by proving the claim is about the identity owner without revealing the identifier that the claim issuer has for the person.

Agents—Sovrin's architecture supports independent software agents to hold and process claims as well as to perform identity transactions on the identity owner's behalf. These agents interoperate directly with each other as peers. Sovrin specifies the protocols that agents use so that agents from different vendors can work together and to support substitutability.

Distributed Ledger—A distributed ledger provides a place where decentralized artifacts like DIDs, verifiable claims, and proofs can be anchored. When agents create or resolve DIDs, they are interacting with the ledger. When an agent creates a claim or a proof from a claim, the various parts of the claim are referenced on the ledger. Without a ledger, agents would need a central repository of some sort to resolve DIDs. The ledger enables decentralized identity by doing away with the need for a central authority.

Handling the Five Problems of Identity

The architecture of Sovrin is designed to solve the five problems of identity.

  • DIDs and verifiable claims solve the proximity problem by giving people the means to prove information about themselves at a distance.

  • Agents and the ledger ensure that Sovrin scales by supporting a decentralized system of interacting peers that can scale to any size.

  • The decentralized nature of claims and claim schemas solves the flexibility problem because people can use Sovrin for the whatever identity problem they face. Everyone can design and use whatever claims will solve their problem.

  • DIDs and zero knowledge proofs provide tools for increased privacy by limiting correlation and supporting minimal disclosure.

  • Sovrin supports consent becausethe identity owner is structurally part of all identity transactions. Sovrin automatically records what was shared and under what terms.

Most physical world identity transactions are self-sovereign. They put people at the center and use decentralized credentials to transfer trustworthy attributes about the identity owner. The naturally support scalable, flexible, private interactions that take place with the identity owner's consent. The Internet introduced the proximity problem and the available solutions and their inherent limitations led us the situation we're in now.

Sovrin capitalizes on decades of cryptographic research and the now widespread availability of decentralized ledger technology to rethink identity solutions so that we can have scalable, flexible, private interactions with consent despite the issues that distance introduces. Sovrin introduces protocols for identity that govern interactions so as to solve the five problems of identity.


Photo Credit: Some IDs may be invalid starting Sept. 15 from Airman 1st Class Mariette M. Adams (Public Domain)


The 10-Year Platform: Shutting Down KRE

A few years ago, I announced on this blog that Kynetx was done. But the platform we'd created, the Kynetx Rules Engine, or KRE, lived on. Today I am annoucing that KRE is dead too. We shut it down last week.

Despite the demise of Kynetx, the platform continued to be open and available. Fuse was still running on it and my students were using it for class and research. But Fuse stopped working for good last spring when the MVNO we were using to process cellular data from the car devices shut down. And the new pico engine is working so well that we use it for everything now.

KRE was started in 2007 and envisioned as a cloud-based programming platform for events. While we had several different uses for it over the years, the focus on cloud-based program evaluation never changed. KRE was a PaaS play and so we built it with the idea that it would be a big chunk of infrastructure that we maintained for use by our customers.

Back at iMall in the 90's, Steve Fulling, Wade Billings, Mark Horstmeier, Cid Dennis, and I developed a core competancy around running big server farms. And AWS was still a fairly new thing. So, we built KRE using Dell servers, Linux, virtual servers, Puppet, and other technology we were familiar with. When we built iMall, not many people could do this well and we got good at running large infrastructure. So when Kynetx started up, that was our natural path. If I were doing it today, or even just 5 years ago, I'd do it on AWS.

Over the past 10 years, KRE has operated day in and day out without fail. The only time it's been offline is when we had to physically move the servers from one data center to another. Turning off KRE and retrieving the servers is the final step in the long, exciting dance that was Kynetx. A few weeks ago I realized that the platform I'd poured my soul into for the last 10 years was no longer needed. But the ideas that it spawned live on in the pico engine. Shutting it down is bittersweet, but I'm excited for the future.


Is Sovrin Decentralized?

People sometimes ask "Is Sovrin decentralized?" given that it relies on a permissioned ledger. Of course, the question is raised in an attempt to determine whether or not an identity system based on a permissioned ledger can make a legitimate claim that it's self-sovereign. But whether or not a specific system is decentralized is just shorthand for the real questions. To answer the legitimacy question, we have to examine the reasons for decentralization and whether or not the system in question adequately addresses those reasons.

This excellent article from Vitalik Buterin discusses the meaning of decentralization. Vitalik gives a great breakdown of different types of decentralization, listing architectural decentralization, political decentralization, and logical decentralization.

Of these, logically decentralized systems are the most rare. Bitcoin and other decentralized ledgers are, in fact, logically centralized. There's one ledger. But the architecture (no infrastructural central point of failure) and politics (no one controls them) of Bitcoin are decentralized. But of course, these aren't binary options. There's a spectrum.

For example, while it's true that Bitcoin miners aren't centrally controlled in some aspects (e.g. who can use them, who can verify transactions), there are points of control such as the code itself. No one person has control but many have a lot more than others. I'm not saying this to throw shade on Bitcoin. Rather, I'm making the point that not even Bitcoin is completely governed by technology. There's some balance between the business, technical, and legal agreements that make up any functioning decentralized system.

The more important question about decentralization is: does the level of decentralization serve the goals of the system. There are several good reasons for going to the effort of creating a decentralized system:

  • Avoiding common mode failure—This is one of the most frequently stated reason for decentralization. An architecture built from many parts is less likely to fail if one of them fails. Of course, this assumes that the many components are put together combined in a way that makes this possible. And it also assumes that the failure isn't due to something they're all susceptible to (otherwise known as the monoculture problem).
  • Resisting attacks—Attacking a decentralized system requires taking on many components in a coordinated manner. Lack of central control points makes attacking decentralized systems much more expensive.
  • Avoiding collusion—Collusion is, as Vitalik puts it "coordination that we don’t like." When participants in the system conspire to cheat or gain an unfair advantage, we call it collusion.

So, rather than asking "Is Sovrin decentralized?", we might ask how the Sovrin network avoids common mode failure, resists attacks, and makes collusion difficult.

Is Sovrin Resilient to Common Mode Failures?

There are many kinds of common mode failures, but there are techniques we can use to avoid them. Sovrin is built on a distributed ledger that is readable and writable by nodes on the network. These nodes are operated by organizations of different types, industry affiliations, and size. They are spread out around the globe. Nodes are operated on different hardware, in different kinds of data centers, with different operating systems. There are no secret nodes. Everyone running a node is known. The code is open source.

There are several shortcomings currently: First, there is only one implementation. Second, most of the development is being done by one company. Both of these will be remedied over time as Sovrin becomes more self-sufficient.

Is Sovrin Resistant to Attacks?

Some attacks are mundane and can be handled using the same techniques as are used for common mode failures. One of the more sophisticated kinds of attacks that decentralized systems face are known byzantine faults. Sovrin is resilient to Byzantine failure because of the underlying consensus protocol of the ledger. Byzantine fault tolerance protects the network from coercion attacks and asymmetric information attacks.

Does Sovrin Resist Collusion?

One of the core principles of Sovrin is diffuse trust—the idea that no single node, person, or organization has to be trusted in order to trust Sovrin. Diffuse trust also ensures that many parties have to agree to take action. This shows up in the consensus protocols for the network as well as the decisions about what code to release. There are no purely technical solutions to collusion. Ultimately every decentralized system has some level of governance that backstops the technology to resist collusion. Transparency and diversity are tools that help systems resist collusion. As Vitalik says:

This third kind of decentralization, decentralization as undesired-coordination-avoidance, is thus perhaps the most difficult to achieve, and tradeoffs are unavoidable. Perhaps the best solution may be to rely heavily on the one group that is guaranteed to be fairly decentralized: the protocol’s users.

Sovrin Foundation's role is to support users. Sovrin Foundation is not an industry association for just this reason. We must be vigilant in making decisions that discourage collusion of all kinds.

Power and Self-Sovereignty

You might look at the preceding questions and think "Ok, I get that Sovrin uses decentralization to protect itself from failure, attack, and collusion. But I'm interested in decentralized systems that protect human freedom and autonomy." That's an important point that doesn't have to do with resilience so much as it does power.

One of the great advantages of blockchain-based systems is not just that they're architecturally decentralized for resilience, but politically decentralized for diffuse control. Bitcoin achieves this, for example, by allowing anyone to validate transactions on the network using a sophisticated proof of work algorithm to protect itself against Sybil attacks. We call these kinds of ledgers permissionless because anyone can read and write transactions on the ledger.

Sovrin supports broad participation through a combination of business process, technology, and legal agreement. Sovrin is "public" meaning anyone can initiate identity transactions that are validated using Sovrin's consensus algorithm. While validators on the Sovrin network are known (the definition of a permissioned ledger), they don't see inside the identity transactions and can't make judgments about which transactions to allow or disallow based on content. Validators who don't abide by the rules of the Sovrin network can be taken offline or replaced.

Sovrin does not have "identity providers" because anyone can be the source of their own identity. Sovrin's primary support for identity transactions uses something called a verifiable claim that works like a physical credential such as a driver's license of password. Sovrin's trust model for verifiable claims has four important and desirable properties that all underscore its support for autonomy:

  1. Claims are decentralized and contextual—There is no central authority for all claims. 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 claims, or any set of trust relationships.
  2. Verifiers do not need to contact issuers to perform verification—Claim verifiers (the people or organizations relying on a credential) don't have any technical, contractual, or commercial relationship with claim issuers (the people or organizations making the claim).
  3. Verifiers make their own trust decisions about which credentials to accept—there's no central authority who determines what credentials are important or are used for what purpose.
  4. Owners are free to choose which credentials to carry—People and organizations are in control of the claims made about them (just as they are with physical credentials) and determine what to share with whom.

All of this points to an incredible amount of autonomy and control by the people and organizations using Sovrin.

Perhaps the most important questions about Sovrin and decentralization is does it provide people and organizations with self-sovereignty. That's ultimately why the power question matters. Last October, I wrote in On Sovereignty:

Sovereignty is about 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 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 describes the same situation. A self-sovereign identity system defines the things over which an entity (person or organization) has complete control along with the rules of engagement for its relations with other entities in the SIS system.

As the previous discussion makes clear, Sovrin not only defines those boundaries, but puts powerful choices in the hands of anyone using it about what personal information they share and how they share it. Sovrin is built from the ground up to use pairwise pseudonymous identifiers and support minimal disclosure as a means to protect sovereignty. This is an important point. While we often speak of privacy, we don't often link it to control. Privacy protects control and control protects privacy.

An Internet for Identity

Last August, I wrote about Sovrin being an Internet for identity. My point was that Sovrin is like the Internet is three important ways:

  1. No one owns it.
  2. Everyone can use it.
  3. Anyone can improve it.

The Internet has shown tremendous resilience to attack while offering unprecedented access for everyone to publish and use information. Sovrin Foundation is working to make this same vision a reality for identity.

Some FAQs About Sovrin's Governance

The following questions and answers fill in some details that may be helpful in evaluating Sovrin as a decentralized identity system:

  • Who decides who can use the Sovrin?—The Sovrin network is public. Anyone can use it.
  • Who decides who can write to the ledger?—Sovrin is, currently, a permissioned ledger so that people can afford to create pairwise pseudonymous identifiers for every relationship they have. Consequently, Sovrin's ledger has a known set validator nodes who write transactions to the ledger and achieve consensus. Sovrin Foundation has legal agreements with the organizations who run validator nodes that control how they operate. The goal of Sovrin Foundation is to have stewards of different legal jurisdictions, industries, sizes, and structure to ensure broad representation and avoid monoculture.
  • Who decides who can read from the ledger?—The Sovrin network architecture allows for observer nodes who can read, but not write, the ledger. The provisional Sovrin network does not have any observer nodes. Observer nodes will also be subject to the Sovrin Trust Framework.
  • Who decides how code is updated?—The Sovrin Foundation has a Technical Governance Board (TGB) that makes decisions about what code validators and observers will run. The code is open sourced at the Hyperledger Indy project is the code that forms the basis of the Sovrin network, but validators run known builds that Sovrin Foundation's TGB authorizes.
  • How is contention resolved?—Contention about transaction is resolved automatically by the code that validators run. Contention about code is first handled by the TGB with the Board of Trustees as the court of last resort. Ultimately validators could refuse to run code that makes certain changes that they disagree with. This could result in a fork of the ledger, as we've seen with other ledgers, but I think the formal structures embodied in the TGB and Board of Trustees make this less likely. The purpose of the Sovrin Trust Framework (PDF) is define how many of the most common points of contention are resolved or avoid them in the first place.

Photo Credit: Adler from Klappe (CC0)


Equifax and Correlatable Identifiers

Yesterday word broke that Equifax had suffered a data breach that resulted in 143 million identities being stolen. This is a huge deal, but not really too shocking given the rash of data breaches that have filled the news in recent years.

The typical response when we hear about these security problems is "why was their security so bad?" While I don't know any specifics about Equifax's security, it's likely that their security was pretty good. But the breach still occurred. Why? Because of Sutton's Law. When Willie Sutton was asked why he robbed banks, he reputedly said "cause that's where the money is."

So long as we insist on creating huge honeypots of valuable data, hackers will continue to target them. And since no security is perfect, they will eventually succeed. Computer security is difficult because computer systems are non-linear—small errors can result in huge losses. This makes failure points difficult to detect. These failure points are not usually obvious. But hackers have a lot of motivation to find them when the prize is so large.

How do we avoid honeypots of data? By decentralizing it. Decentralized identity breaks the data up so that no single hack returns enough data to be profitable1. No one would break into Equifax to steal the data from a single random individual. It's only in aggregate that the data has sufficient value to justify the effort.

But we can make even individual records worth less by getting rid of universal identifiers. Things like credit card numbers, social security numbers, and phone numbers are all examples of universal identifiers. Universal identifiers allow a single person's activity to be tracked across multiple domains. If Equifax's database has consisted of a bunch of identifiers that only meant something to Equifax, there would be no reason to steal them. They're valuable because of the correlation.

The great news is that building identity systems that use pairwise, pseudonymous, non-correlatable identifiers is doable now. The Decentralized Identifier (DID) specification describes an interoperable system of identifiers. Imagine when you need to give a merchant the ability to contact you or charge your account, you gave them a DID created just for them instead of of a credit card number2 or phone number. They could still use this DID to contact you or to charge you a monthly subscription, but it would be unique to them. If there was a breach and your DIDs were lost, you simple cancel them without affecting any other relationship. Non-correlatable identifiers are not worth the trouble to steal.

The technical details of how this might work are beyond the scope of this post, but with today's computer technology we don't have to rely on correlatable identifiers. They are a 20th century tool that is unsuited to the digital age. It's time we stopped using them and started using technology that is designed to protect privacy without sacrificing functionality. If you're interested in exploring the details, I invite you to look at Sovrin, a decentralized, public, global identity system built to support non-correlatable identifiers by default.


Notes:

  1. This is the general case. If you have a private key that protects million of dollars worth of bitcoin, that single private key would in itself be worthy of extraordinary efforts to retrieve.
  2. Note that systems like Apple Pay and Android Pay already use one-time identifiers in place of a credit card number for added security. Non-correlating payment systems already exist—they're just not widely enough used yet.

Photo Credit: Honey from unknown (CC0)

vvv


Sovrin Self-Sustainability

The Sovrin Foundation began life about a year ago. We launched the Sovrin Network just last month. For Sovrin to achieve its goal of providing self-sovereign identity for all, the Foundation and the Network have to be independent and self-sustaining.

The idea for Sovrin-style identity and the technology behind it was developed by Evernym. To their credit, Evernym’s founders, Jason Law and Timothy Ruff, recognized that for their dream of a global identity system to become reality, they’d have to make Sovrin independent of Evernym. At present, Evernym continues to make huge contributions to Sovrin in time, code, money, and people. Our goal is to reduce these contributions, at least as a percentage of the total, over time.

Achieving complete independence and becoming self-sustaining can be measured with four milestones. We have achieved the first and are working on the second which would lead to the resources necessary to achieve the third and fourth.

  1. Legal independence—Sovrin Foundation is legally separate from Evernym. Furthermore, I and the majority of people involved with the foundation governance have no relationship to Evernym. No one on the board represents an organization. They are on the board as people and recruited because of their support for self-sovereign identity. My belief is that the Board of Trustees should represent the people with identities on the network, not specific organizations.
  2. Financial independence—This is harder to achieve. I don’t believe that Sovrin can provide self-sovereign identity for people as an “industry association” where big companies come together to determine how Sovrin works. So, I’ve resisted fund-raising that would require that Sovrin trade influence for dollars. We are working on some alternative methods and hope to make some announcements about this soon.
  3. Technical independence—This will follow from financial independence as we hire people to take over some of the management roles in the foundation that are now staffed by Evernym and other volunteers. We will also begin to drive many technical developments and coordinate our open source projects from within the foundation.
  4. Ecosystem independence—This will be achieved when there are multiple competitors to Evernym on the Sovrin platform. As the network becomes more capable, we will begin to recruit more companies to use Sovrin. Evernym will be just one of many companies that use Sovrin. Our goal is to build a platform that is universal and owned by nobody. Further we don’t want the platform to be dominated by any one company. Our vision is for Sovrin to become an Internet for identity with all that that term implies.

Beyond these four milestones, the ultimate goal for Sovrin Foundation and the network is self-sustainability. Sovrin must be in a position where it is self-sustaining so that it can remain free from outside influences that might rob it of its independence. We are fortunate to have a network model that can return value to the foundation for its role in developing the code and governing the stewards who operate nodes on the network. This model will support a vibrant, growing ecosystem of applications with positive network effects. Watch for upcoming announcements about Sovrin and self-sustainability in the near future.


Thanks to Timothy Ruff for suggesting the four milestones of independence.

Photo Credit: travel-fly-balloon-sky-sunset from Gellinger (CC0)


The Case for Decentralized Identity

I go back and forth between thinking decentralization is inevitable and thinking it's just too hard. Lately, I'm optimistic because I think there's a good answer for one of the sticking points in building decentralized systems: decentralized identity.

Most interesting systems have an identity component. As Joe Andrieu says, "Identity is how we keep track of people and things and, in turn, how they keep track of us." The identity component is responsible for managing the identifiers and attributes that the system needs to function, authenticating the party making a request, and determining whether that party is authorized to make the request. But building an identity system that is usable, secure, maximizes privacy is difficult—much harder than most people realize.

The problem with decentralized identity is even more acute. Discovery is one of the key features of an identity system. And decentralized discovery is hard. Say, for example, that I have an identifier and need an associated attribute, a public key, for example. In a centralized identity system, there would be a database somewhere that associated identifiers with public keys. Make a query on the database with the identifier and I get back the key. Easy.

But doing discovery without a central database has been hard. Lack of decentralized discovery has made otherwise decentralized systems susceptible to denial of service attacks, insecure, or slow and inefficient.

Distributed ledgers—blockchains—promise to solve this by providing decentralized discovery that is secure and efficient. But just having a blockchain isn't enough. Decentralized identity might start with a distributed ledger, but making a system that is private, secure, and useful requires much more. Blockchains help with discovery, but you still have to worry about how to make key management and attribute exchange secure and private.

Having a global utility for identity solves this problem in a way everyone from the lone developer to the small startup to the global enterprise can take advantage of. In Fat Protocols, Joel Monegro argues:

[B]y replicating and storing user data across an open and decentralized network rather than individual applications controlling access to disparate silos of information, we reduce the barriers to entry for new players and create a more vibrant and competitive ecosystem of products and services on top.

Emerging blockchain-based identity systems are protocols for identity. As Joel says, this means that the applications riding on top of these identity protocols can offer more with less effort. For example, I've argued elsewhere that sharing economy companies like Lyft and AirBnB are based on identity platforms that allow for an exchange of trust. And that having a universal platform that allows anyone to do this accelerates the pace at which these kinds of services could be offered.

But more importantly, a universal, decentralized identity platform offers the opporunity for services to be decentralized. In the physical world, people start businesses all the time without some kind of platform. I lease a storefront, figure out how to get inventory, and my storefront can be up and running. I don't have to be a sharecropper for some large corporation. As an example, I can imagine a universal, decentralized identity system giving rise to apps that let anyone share rides in their car without the overhead of a Lyft or Uber because the identity system would let others vouch for the driver and the passenger.

The need for decentralized thinking has never been more acute. As I wrote in The CompuServe of Things:

My point isn't a narrow technical one. I'm not arguing for an open Internet of Things because of perceived technical benefits. Rather, this is about personal autonomy and ultimately human rights. As I said above, the Internet of Things will put computers with connectivity into everything. And I really mean "every thing." They will intermediate every aspect of our lives. Our autonomy and freedom as humans depend on how we build the Internet of Things. Unless we put these connected things under the control of the individuals they serve without an intervening administrative authority, we will end up building something that undermines the quality of life it's meant to bolster.

The emergence of a decentralized identity platform gives me hope that we can build online systems that respect human dignity. Back to Joe Andrieu:

When we build interconnected systems without a core understanding of identity, we risk inadvertently compromising human dignity. We risk accidentally building systems that deny self-expression, place individuals in harm’s way, and unintentionally oppress those most in need of self-determination.

Photo Credit: Vegetable Vending - Andul Bazaar from Biswarup Ganguly (CC BY 3.0)


Launching the Sovrin Network

This morning I participated in the launch of the Sovrin Network. About six weeks ago, we set up the Alpha network for testing. Validators participated in exercises to ensure the network was stable and could achieve consensus under a variety of circumstances.

This morning we transitioned from the Alpha network to the Provisional network. There are several important differences between the Alpha network and the Provisional network:

  • All validator nodes on the Provisional network are being run by Sovrin Stewards who have executed the Sovrin Provisional Trust Framework (a legal contract) with the Sovrin Foundation.
  • We do not intend to ever reset the ledger. All transactions on the provisional network are "in production."

In short, the provisional network is the real Sovrin network and is open for business. Transactions written to the provisional network will be part of the Sovrin ledger for all time.

The Launch Ceremony

Launching the provisional network wasn't as simple as pushing a button. Rather, launching a distributed ledger involves a ceremony that is designed to give everyone confidence that the network is secure and has no backdoors through the principle of diffuse trust. Multiple participants, in many locations, witness the process of creating the ledger's genesis block. The ceremony ensures that this is done with maximal transparency. Some launch ceremonies have gone to extreme lengths to achieve these goals.

In the case of Sovrin, almost 50 people participated in the launch ceremony from all over the world. The genesis block on the Sovrin ledger holds public identifiers and keys for six Sovrin Trustees and ten Sovrin Stewards. The entire ceremony was recorded and will be made available soon. The ceremony requires Trustees and Stewards who are part of the genesis block to verify their identifiers and keys and allows many parties to witness the incorporation of that information into the ledger. Doing so, provides evidence of the integrity of the ledger and the identities of those participating in its launch.

Now that there is a genesis block, the identifiers for trustees who weren't able to participate today along with those of stewards who join over the coming weeks will be written as new transactions on the ledger. The sandbox network is still available for non-production testing.

Over the coming weeks and months we'll be rolling out additional features and updating the trust framework to fill in a number of additional sections that must be completed, approved, and agreed to before the Sovrin network is declared ready for general availablity.

By the Numbers

Here's some information about the codebase for Sovrin network at launch:

  • Slightly over 130,000 lines of code
  • 721 tickets (stories, bugs) closed
  • 37 contributors from: Italy, Austria, Luxembourg, India, Russia, Venezuela, Finland, USA, and others.
  • Participants from six continents
  • 1012 pull requests
  • Approximately 17.8 person-years of coding and QA effort

Identity for All

This day has been a long time coming. I'm very excited to see Sovrin become a reality. I'm grateful to everyone who has worked hard for this day. Thanks especially to Timothy Ruff, Jason Law, and everyone at Evernym for their dedication and hard work. Thanks to the Sovrin Trustees and Technical Governance Board. I'm also grateful to the founding stewards who have made this possible.

Sovrin provides a global identity infrastructure that supports self-sovereign identity and verifiable claims. Over the coming weeks, we will put in place the means for issuing identifiers on the network and make available information on how people and organizations can start to use Sovrin. This is the beginning of Identity for All.

Update: Here's the recording of the Sovrin launch ceremony. Its not terribly exciting, mostly people certifying things and reading keys. But it is the official record. For reference, stewards were brought online at 1:18:47 and verifying consensus occurred at 1:22:16 in the video.