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.


  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)


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.

Identity, Sovrin, and the Internet of Things

Doc Searls put me onto this report from Cable Labs: A Vision for Secure IoT. Not bad stuff as far as it goes. The executive summary states:

IoT therefore represents the next major axis of growth for the Internet. But, without a significant change in how the IoT industry approaches security, this explosion of devices increases the risk to consumers and the Internet. To reduce these risks, the IoT industry and the broader Internet ecosystem must work together to mitigate the risks of insecure devices and ensure future devices are more secure by developing and adopting robust security standards for IoT devices. Industry-led standards represent the most promising approach to broadly increase IoT security. Given the global and constantly evolving nature of threats, industry must utilize its expertise and reach to develop, adopt, and enforce fundamental IoT security measures.

The paper goes on to outline the "technical goals of an industry-led, standards-based approach as well as the governance goals of the development organization." It says:

To achieve the needed level of security, an IoT security standard must address: (i) device identity; (ii) authentication, authorization, and accountability (onboarding); (iii) confidentiality; (iv) integrity; (v) availability; (vi) lifecycle management; and (vii) future (upgradable) security.

You can see from that list that the first four of those are all identity topics. And, not surprisingly, the paper spends a good deal of time talking about identity. I'd love to see the authors and readers of the paper at Internet Identity Workshop in October to discuss these topics. You'll find a lot of identity experts anxious to engage in solving these problems. Consider this an open invitation.

In the section on device identity, the paper says:

To support strong security, the device identifier must be immutable, attestable, and unique. Today, IoT devices typically do not use identifiers that are both unique and immutable and the device identifiers are almost never attestable. Attestability enables the device identity to be cryptographically verified, dramatically reducing the risk that the device is being impersonated (or “spoofed”).

The answer, from the paper, is to use PKI and certificates to solve the problem. True enough, but the devil is in the details. The problem is that the current best practices for certificate management leads to an architecture for the Internet of Things that is unduly hierarchical. Certificate manage implies a hierarchy of certificate authorities where each authority verifies those lower in the hierarchy until you get to the root certificates that are embedded in the devices.

I think we can do better than hierarchical certificate management for the Internet of Things. Indeed, I think we have to. A hierarchical model puts large collections of devices at the mercy of the the validity of root certificates.

The alternative is a decentralized web of trust. Sovrin provides a way to use cryptography to establish trust without a hierarchical public key infrastructure. The result is a decentralized system that is more available because it has fewer central points of control that might become single points of failure. I wrote in Sovrin Web of Trust:

PKI is good for one thing on the Web: showing the public key used to secure HTTP transmissions is correct. In contrast, Sovrin’s decentralized web of trust model is good for anything people need. The goal of Sovrin is to provide the infrastructure upon which these overlapping webs of trust can be built for various applications. Lyft, Airbnb, and countless other sharing economy businesses are essentially specialized trust frameworks. Sovrin provides the means of creating similar trust frameworks without the need to build the trust infrastructure over and over.

Imagine each device with a Sovrin decentralized identifier (DID) that links to its public keys on the Sovrin ledger. The DID provides a unique identifier for the device. And since it links to the public keys, anything can figure out how to communicate with the device securely. Sovrin's revocation features ensure that the keys can be updated as needed. Sovrin Trustworthy Claims serve as globally verifiable attestations about the device and these can be made flexibly by any party. All on a globally available, decentralized identity infrastructure that anyone can use.

If we're going to avoid the CompuServe of Things and build a true Internet of Things, we need to base it on a decentralized identity infrastructure. Sovrin is provides that. Let's talk.

Photo Credit: hairy from Windell Oskay (CC BY 2.0)