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)


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)


A Mesh for Picos

Picos are Internet-first actors that are well suited for use in building decentralized soutions on the Internet of Things. Here are a few resources for exploring the idea of picos and our ideas about they enable a decentralized IoT if you’re unfamiliar with the idea:

  • Picos: Persistent Compute Objects—This brief introduction to picos and the components that make up the pico ecosystem is designed to make clear the high-level concepts necessary for understanding picos and how they are programmed. Over the last year, we've been replacing KRE, the engine picos run on, with a new, Node-based engine that is smaller and more flexible.
  • Reactive Programming with Picos—This is an introduction to picos as a method for doing reactive programming. The article contains many links to other, more detailed articles about specific topics. You can thus consider this an index to a detailed look at how picos work and how they can be programmed.
  • Promises and Communities of Things—Promise theory provides a tool for thinking about and structuring the code that implements communities in groups of social things. This blog post discusses some initial thinking about promises and picos.
  • Social Things, Trustworthy Spaces, and the Internet of Things—Social things interacting in trustworthy spaces represent a model for an Internet of Things that is scalable to trillions of devices and still works. This post describes that concept and proposes picos as a platform for building social things.
  • Market intelligence that flows both ways—Doc Searls talks about how pico-based shadows of products are useful in creating new customer service interaction patterns. The pico-based system he references, SquareTag, is no longer in active development, but we're replacing it with a new system called Manifold that reflects the community of things ideas I reference above.

The New Pico Engine

Picos run on an engine that provides the support they need for Internet services, persistent storage, and identity. Over the past year, we've been rebuilding the pico engine. The Classic Pico Engine was a big cloud service. The New Pico Engine is a small, nibble Node program.

We recently built several demos with the pico engine to show this. Both used the pico engine running on a Raspberry Pi in IoT scenarios. The first was a demo of a computer closet (here's a wrietup of an early version of that demo) that uses temperature sensors and several fans to show how picos can cooperate to achieve some goal (in this case keeping the closet sufficiently cool). The second was an overengineered Jack-in-the-Box that had a pico engine running internally to play music and spring the door.

A Mesh for Picos

Picos operate in a mesh, regardless of where they're hosted. Picos don't have to be running on the same pico engine in order to form relationships with each other and interoperate.

We've begun a program to more fully support this ideal by making the engine itself part of a larger mesh of engines, each capable of hosting any of the picos in that ecosystem. The vision is that someone using a pico doesn't need to know what engine it's hosted on and that picos can move easily from engine to engine, moving computation close to where it's needed.

There are two problems to solve in order to make this a reality:

  1. Picos are addressed by URL, so the pico engine's host name becomes part of the pico's address
  2. Picos have a persistence layer that is currently provided by the engine the picos is hosted on.

We propose to solve the first problem using the Sovrin identity platform. I wrote about that idea in some detail in Sovrin Use Cases: Portable Picos. The synopsis is that Sovrin allows us to find picos by name rather than location using the distributed ledger as a storage location for names based on decentralized identifiers (DIDs) that point to the current location of the pico.

We propose to solve the second problem by incorporating the Interplanetary File System (IPFS) into the engine as the persistence layer for picos. By using IPFS, the pico's persistent state would be available to it regardless of where it is being run.

With this two changes in place, we can create a mesh of pico engines. Individual pico engines can come or go as necessary without impacting the ability of the picos themselves to operate normally. The Classic Pico Engine was a child of the early 2000's and used all the tools and techniques we'd learned to create availbility and reliability including load balancing, primary and secondary databases, server farms, monitoring, and automated service configuration.

The new pico engine will be something much more decentralized, lightweight, and adaptable. Pico engines can join a pool to support additional computational needs without complicated configuration or management. I envision a world where IoT device shadows in the form of picos run on a global, secure mesh of pico engines. These meshes could be public or private and supply generalized computer resources on demand.


Photo Credit: Blurred Bokeh Fence Lights from Pexels (CC0 Public Domain)


Sovrin Status: Provisional Trust Framework

Last week, the Sovrin Foundation Board of Trustees voted unanimously to approve the Sovrin Provisional Trust Framework (PTF). Trust is the primary benefit of Sovrin. I've written before about Sovrin as a universal trust framework and Sovrin's web of trust model. The Provisional Trust Framework is a set of legal documents that provide the foundation for Sovrin's trust model.

Sovrin is a permissioned ledger, meaning it achieves consensus using a known set of validators—in this case, trusted institutions around the world. This is in contrast to permissionless ledgers like Bitcoin's blockchain that rely on validators who are not identified. The permissioned model has advantages in both speed and cost of transactions. But it means that Sovrin needs governance. The PTF is the set of documents that spells out how various participants in the network must behave and the agreements that Sovrin Stewards make in order to operate a validator node. Each Steward will sign the Sovrin Founding Steward Agreement before they operate a validator node on the Sovrin network.

Sovrin is also a public ledger, meaning anyone can use it. This is in contrast to other permissioned ledgers that are operated as private systems for their owner's specific purposes. Sovrin is designed to operate as a global public utility for identity. Sovrin can be used by anyone. The PTF supports this goal, enumerating the participants in the network and their obligations and qualifications. The PTF also spells out how Sovrin's Web of Trust model works.

The PTF outlines:

  • the principles that govern the Sovrin network and by extension the Sovrin Foundation and Stewards;
  • key definitions and terminology;
  • the obligations of the Sovrin Foundation;
  • business policies for identity owners, stewards, trust anchors, and guardians;
  • legal policies for identity owners, stewards, agencies, and developers;
  • legal policies for dispute resolution;
  • legal policies for confidentiality;
  • technical policies for node operation, monitoring and reporting, write permissions, transaction limitations, and service levels; and
  • policies for amending the PTF.

The PTF governs the operation of the Sovrin network while in "provisional" status, meaning during its first months of official operation when it is still being “battle-tested” in live operation by the Founding Stewards. The PTF has a number of additional sections that must be completed, approved, and agreed to before the Sovrin network is declared ready for general availablity. At that point these documents will graduate and be called the Sovrin Trust Framework.

The completion of the PTF is an important step for the network. The Trust Framework Working Group and it's chair, Drummond Reed, have spent long hours hammering out this vital set of documents. With the PTF's completion and approval, Sovrin takes one more important step to being a reality.