Last Build Date: Thu, 20 Oct 2016 14:32:49 -0600Copyright: Copyright 2016
Thu, 20 Oct 2016 14:32:45 -0600Summary: Verifiable, owner-provided attributes are the engine that will drive wide-spread adoption of self-sovereign identity systems. This article explains how this models the way credentials work in the physical world and describes benefits of owner-provided attributes. In the physical world, people carry credentials to prove to others that they have certain attributes or hold certain privileges. Online, this is not possible. For example, a driver's license contains attributes like name, address, and date of birth that have been validated by the Driver's License Division. The driver’s license is widely viewed as trustworthy. Consequently, people use driver's licenses for purposes other than driving. For example, a school or pharmacy can easily verify that a license belongs to the person presenting it, and confirm the validity of the license without ever contacting the Driver's License Division directly. In other words, in the physical world, people hold and are the conveyors of their own trustworthy attributes (called “claims” by identity experts). These attributes can be used when needed and without prior agreement. Online, such interactions are only possible through pre-arranged integrations between the APIs of specific computer systems. Identity systems in use today include federation for business-to-business credential sharing, and social login for consumer authentication1. Neither of these offers a foundation upon which third-party claim issuers can easily build services that allow for the kind of ad hoc attribute sharing that happens in the physical world. Consequently, entities who want to rely on attributes from many parties have to perform integrations with all of them. This is slow, complex, and costly, so it typically happens only for high-value applications. Decentralized identity systems, like Sovrin, have built-in support for third-party claims that function in the same way physical credentials work: they’re presented directly by the identity owner. The identity owner can use a claim from one party to disclose attributes to another party without those parties even having a relationship, much less a technical integration2. Claims can be used in ad hoc situations, just as they can in the physical world, allowing individuals to function as integration points. When you can instantly trust what someone says about themselves, workflows and integrations are dramatically simplified. There are other benefits to owner-provided attribute sharing. First, when owners share attributes, the receiver automatically gains consent to use the attributes for the requested purpose. This significantly reduces liability. Second, when the owner is part of the process, they can check the accuracy of the attributes as they’re being shared, resulting in better data. Owner-provided attributes are a powerful driver that will push decentralized identity systems well beyond the current uses of federation and social login. Businesses can reduce or even eliminate API integrations and manual verification processes, and instead trust what's presented to them by customers, because the claims can be verified. Customers become the source of what's true about them. Businesses will find great value in this, driving adoption by individuals as customers are brought into decentralized identity systems through day-to-day business activities. See Self-Sovereign Identity and the Legitimacy of Permissioned Ledgers for more on the difference between self-sovereign identity systems and social login. See How Sovrin Works for details on how claims can be received, stored, and shared as verifiable disclosures. Tags: distributed+ledger identity sovereign-source claims sovrin [...]
Fri, 07 Oct 2016 14:55:41 -0600
Summary: An animation showing how Sovrin works.
If you're too busy to read How Sovrin Works, here's a short animation that summarizes the post using my graphics. Thanks to Andy Tobin for putting it together.(image)
Mon, 10 Oct 2016 09:44:26 -0600Summary: This article describes how Sovrin works by showing the interactions of a Sovrin user, Jane, with organizations she does business with. The examples highlights Sovrin's features and method of operation. Sovrin is an open-source identity network built on distributed ledger technology. Sovrin is public and permissioned. Public means everyone can use it. Permissioned means that the network nodes that ensure consensus of transactions on the ledger are governed, in this case by the non-profit Sovrin Foundation. In this discussion we're going to look at the interactions of a Sovrin user named Jane with her bank, her local government, a potential employer, her school and a retailer. The following figure shows Jane's view of her identity on Sovrin. Right now there's nothing there, but we're going to add things as we discuss Sovrin's capabilities in the following sections. Jane's identity doesn't really exist as depicted. The view is a virtual representation. Jane's Sovrin identity is the collection of all of her Sovrin identifiers, claims, disclosures, and proofs. The things in the box labeled "Jane's identity" are stored in various places. Most, but not all will be on the Sovrin ledger itself, some might be stored off the ledger in other repositories like the private ledger we'll discuss later. Jane and an empty ledger The diagram also shows the Sovrin Ledger. The ledger is shown to emphasize that everything we talk about is using the ledger. There are far too many lines for the diagram to show all the various interactions with the ledger itself, so I've chosen to merely represent it and use it as a place to show the diagram's legend. The Sovrin Identity Network (SIDN) consists of multiple, distributed nodes located around the world. Each has a copy of the ledger. Nodes are hosted and administered by stewards. Each node has a copy of the ledger. Stewards are responsible for validating identity transactions to assure consistency about what is written on the ledger and in what order. They do this using a combination of cryptography and an advanced Byzantine fault tolerance algorithm. See the Sovrin whitepapers The Inevitable Rise of Self-Sovereign Identity (PDF) and The Technical Foundation of Sovrin (PDF) for more details. Keys, Identifiers, and Relationships Sovrin tracks keys and identifiers. One of the major concerns with identity is correlation. If Jane were to use one identifier in multiple places, those places might collude to correlate that identifier and amass significant data about her without her permission. Sovrin avoids this by allowing Jane to use a different identifier with everyone she relates to. By default, Sovrin identifiers are cryptonyms, an encoded Ed25519 digital signature verification key. Sovrin also supports DID’s (Distributed Identifiers), which are identifiers with no cryptographic properties. These identifiers also have an associated Ed25519 verification key. In the diagram the signing key is represented by a small letter and the verification key is represented by a big letter. These two keys represent a private-public key pair. Jane never shares her signing key, only the verification key. Jane's relationships Jane has a relationship with her bank. She shares a verification key, A, with the bank that created specifically for this relationship. This key represents Jane's identity to the bank and can be used to verify any interactions that they have. The bank also has its own key, K. This is a well-known key that represents the bank to the world. Jane would also have a copy of that so that she can validate communications she has with her bank. The verification keys of both Jane and the bank are found on Sovrin, so they can both know they are using the latest verification keys of the other party. As we add new relationships to this diagram, you'll see that Jane uses a unique key pair for each of her relationships1. Claims In addition to identifiers, Jane has claims on Sovrin. Claims are [...]
Thu, 29 Sep 2016 05:36:36 -0600In London today, we're announcing the formation of the Sovrin Foundation. Sovrin Foundation is a private-sector, international non-profit that was established to govern the Sovrin Identity Network (SIDN). SIDN is a public, permissioned distributed ledger purpose built for identities. The Internet was created without any way for people and organizations to be identified. On the Internet, only machines get identities in the form of IP numbers. This is understandable given what the creators of the Internet were trying to achieve. But the lack of a decentralized, heterarchical, and interoperable identity system has created an environment where the services most people use online are a lot more centralized than the Internet they're built upon. Sovrin Foundation aims to rectify that. Using the virtues of Internet as a model, The Sovrin identity protocol uses a distributed ledger to replace today's centralized identity intermediaries. I believe an Internet-like identity system will create new opportunities for everyone by streamlining interactions and enabling stronger levels of trust. As I wrote earlier, self-sovereign identity creates a vast new identity ecosystem because it frees millions of organizations to write claims on the ledger. Sovrin is designed to allow this ecosystem of claims providers to thrive. A permissioned ledger needs a governance process to determine the business processes and overarching legal framework that validators on the network must follow to ensure that2 SIDN can be trusted. Sovrin Foundation provides the lightweight governance that is needed to do that. Sovrin Foundation governs the network and the open-source code that makes it work, but we don't own or control people's identities, they are sovereign. The Foundation has four primary duties: Develop and maintain the Sovrin Trust Framework, governing the selection and monitoring of Sovrin stewards and operation of the Sovrin Ledger. Coordinate and monitor steward activity to ensure the ledger is stable, correct, and trustworthy. Manage the Sovrin Project—the open source code that operates, validates, and provides access to the ledger. Promote universal acceptance of the Sovrin ledger for self-sovereign identity. I've agreed to serve as the inaugural chair of the foundation. I co-founded the Internet Identity Workshop with Kaliya Hamlin and Doc Searls a dozen years ago with the goal of promoting what we then called "user-centric identity." My motivations in doing that were the same as they are here: find a way to unlock the vast potential of people who own and control their online identity. We have a tremendous, global Board of Trustees who have agreed to serve and help organize the foundation. Each person on the board brings unique talents and perspective. I'm excited to work with them in organizing Sovrin Foundation and bringing this to fruition. Evernym developed the code that makes Sovrin work and has generously gifted that code to Sovrin Foundation. Making it open source wasn't enough. Sovrin Foundation can't govern SIDN without also owning the code that makes it work. Timothy Ruff and Jason Law, Evernym's founders, saw early on that the best way to make Sovrin successful was to give it away. Sovrin Foundation is grateful for their support and this demonstration of trust. You can get more information from the following links: Technology White Papers If you'd like to know more, feel free to contact us. We invite your participation. Tags: sovrin distributed+ledger identity sovereign+source sovrin+foundation [...]
Wed, 21 Sep 2016 14:12:47 -0600Summary: This post justifies the claim that an identity system based on a permissioned distributed ledger is legitimately self-sovereign. The post also examines the claims to legitimacy that social login and distributed ledger identity systems make. My last blog post was about creating an Internet for identity, a decentralized system that allows people and organizations to create identities independent of intervening administrative authorities. The post describes this system as self-sovereign and I call the system a self-sovereign identity system or SIS. I believe the right way to construct SIS is using a public, permissioned distributed ledger. Permissioned ledgers have important properties that make them specifically useful for identity systems. But permissioning implies governance. Someone has to determine who has permission to participate in approving transactions. If there are people making these kinds of decisions, how can a governed, permissioned ledger justify a claim that it supports self-sovereign identity? John Locke and Sovereignty John Locke was an English philosopher who had a big impact on the thinking of America’s founding fathers. Locke was concerned with power, who had it, how it was used, and how society is structured. More importantly, Locke’s theory of mind forms the foundation for our modern ideas about identity and independence. Locke argued that “sovereign and independent” was man’s natural state and that we gave up freedom, our sovereignty, in exchange for something else, protection, sociality, commerce, among others. This grand bargain forms the basis for any society. As a community, the Internet proposes a similar bargain. The goal of being self-sovereign isn't to be completely independent. With regard to the Internet: only machines without a network connection are completely independent. In the case of identity: only people without any relationships are completely independent. Seen from Locke's viewpoint, sovereignty is a resource each person combines with that of others to create society. Voluntarily giving up some of our rights to a state confers legitimacy on that state and its constitution. Constitutional Orders and Legitimacy Wikipedia defines legitimacy as the right and acceptance of an authority, usually a governing law or a regime. While this is most often applied to governments, I think we can rightly pose legitimacy questions for technical systems, especially those that have large impacts on people and society. With respect to legitimacy, Philip Bobbit says:1 The defining characteristic ... of a constitutional order is its basis for legitimacy. The constitutional order of the industrial nation state, within which we currently live, promised: give us power and we will improve the material well-being of the nation. In other words, legitimacy comes from the constitutional order: the structure of the governance. Citizens grant legitimacy to constitutional orders that meet their expectations by surrendering part of their sovereignty to them. Regarding constitutional orders, Bobbitt says the following:2 The constitutional order of a state and its strategic posture toward other states together form the inner and outer membrane of a state. That membrane is secured by violence; without that security, a state ceases to exist. What is distinctive about the State is the requirement that the violence it deploys on its behalf must be legitimate; that is, it must be accepted within as a matter of law, and accepted without as an appropriate act of state sovereignty. Legitimacy must cloak the violence of the State, or the State ceases to be. Legitimacy, however, is a matter of history and thus is subject to change as new events emerge from the future and new understandings reinterpret the past. Without legitimacy, the state cannot take action because neither it's citizens nor those on the outside who interact with i[...]
Tue, 30 Aug 2016 19:23:36 -0600Summary: Online services and interactions are being held back by the lack of identity systems that have the same virtues as the Internet. This post describes what we can expect from an Internet for identity. In World of Ends, Doc Searls and Dave Weinberger enumerate the Internet's three virtues: No one owns it. Everyone can use it. Anyone can improve it. If we wanted to build an identity system that was like the Internet, we'd want it to have those same virtues. To make the discussion below easier, let's call that system SIS (for sovereign identity system). No One Owns It Every online identity you have was given to you by someone else. This simple fact makes every online identity completely different from identity in the physical world where you exist first, independently, as a sovereign human being. As a result, online relationships are skewed. There's an imbalance of power between people and organizations online. Here's why. Online identity looks like this: Fig 1: Current online identity model To do business with Amazon, you have to create an account. So do I. We both get a relationship with Amazon based on an identity that we create within Amazon's namespace. That identity is subject to the (mostly unread) Terms and Conditions that Amazon places on the use of its service. Your use of the account is subject to whatever restrictions Amazon chooses to place on it. These can be changed retroactively. Furthermore, Amazon can take the account away at any time and you have very little recourse. Clearly Amazon owns the account and is letting you use it so long as such use suits their goals. Of course, Amazon isn't unique here. This is how identity works online. Everyone knows that. For identity to be different, we'd need a way for people to create online identities that they control. Such an identity system could turn this diagram inside-out, resulting in a picture where you are at the center: Fig 2: A sovereign identity model In SIS, individuals, businesses, and other organizations establish identities that exist independently of the other identities in the system. Those identities are peers. Of course, being at the center is perception. The reality looks more like the Internet: Fig 3: Peer to peer relationships in a sovereign model Everyone Can Use It Every online identity you have is subject to someone else granting you permission. Anyone can use the Internet. No one has to give you permission. And no one can cut you off. You do need to get an IP address, but that's not a significant burden—they're widely available from multiple sources (and IPv6 was created to reduce that even further). Once you and I have an address, we can exchange IP packets to our heart's content. If your ISP cuts you off, you get another because they're substitutable, give me your new address, and we're back to exchanging packets. An Internet-like identity system like SIS would be public. Anyone should be able to use it without getting permission from a system administrator or having to agree to terms and conditions that are changed arbitrarily or controlled and adjudicated by a closed process without recourse. An Internet-like identity system should be built so that everyone can participate on equal footing. Anyone Can Improve It You can only improve identity systems in ways their owners allow. The Internet gets improved by lots of people everyday—most of whom have no formal relationship with the Internet's governance bodies. This happens in a couple of ways: First, there is an open process for improving the system. On the Internet that happens through open protocols and open source code. This isn't a free-for-all. There are governance processes that control how these improvements are vetted and incorporated. Second, anyone can design and build a new service on top of these protocols. DNS, email, and other services are all [...]
Tue, 06 Sep 2016 17:16:00 -0600Summary: Some claim that decentralized system that have to be governed aren't really decentralized. This article explains why that thinking is misguided. Last week, I referenced an article in American Banker on the responsibilities of blockchain developers. I focused mainly on the governance angle, but the article makes several pokes at the "decentralization charade" and that's been bothering me. The basic point being that (a) there's no such thing as a blockchain without governance (whether ad hoc or deliberate) and (b) governance means that the ledger isn't truly decentralized. In Re-imagining Decentralized and Distributed, I make the distinction between distributed and decentralized by stating that decentralized systems are composed of pieces that are not under the control of any single entity. By that definition, DNS, for example, is a pretty good example of a decentralized service since it's composed of servers run by millions of separate organizations around the world, cooperating to map names to IP numbers. There are others including email, the Web, and the Internet itself. But DNS is clearly subject to some level of governance. The protocol is determined by a standards body. Most of the DNS servers in the world are running an open-source DNS server called BIND that is managed by the Internet System Consortium. Domain names themselves are governed by rules put in place by ICANN. There are a group of people who control, for better or worse, what DNS is and how it works. So, is DNS decentralized? I maintain that DNS is decentralized, despite a relatively small set of people who, together, govern it. Here's why: First, we have to recognize that decentralization is a continuum, not a binary proposition. Could we imagine a system for mapping names into IP numbers that is more decentralized? Probably. Could we imagine one less decentralized? Most certainly. And given how DNS is governed, there are a multitude of entities who have to agree to make significant changes to the overall operation of the DNS system. Second, and more important, the governance of the DNS system is open. Structurally, it's difficult for those who govern DNS to make any large-scale change without everyone knowing about them and, if they choose, objecting. Third, the kinds of decisions that can be made by the governance bodies are limited, in practice, but the structure of the system, the standards, and the traditions of practice that have grown up around it. For example, there is a well-defined process for handling domain name disputes. Not everyone will be happy with it, but at least it exists and is understood. Dispute resolution, as one example, is not ad hoc, arbitrary, or secret. Lastly, the DNS system may be governed by a relatively small set of people and organizations, but it's run by literally millions. People running DNS servers have a choice about what server software they run. If enough of them decided to freeze at a particular place because they objected to changes or to fork the code, they could effectively derail an unpopular decision. Distributed ledgers will have varying levels of decentralization depending on their purpose and their governance model and how that model is made operational. The standard by which they should be judged is not "does any human ever make a decision affecting the ledger" but rather: Is the ledger as decentralized as we can make it while achieving the ends for which the ledger was created? Is the governance process open? Who can participate? How are the governing entities chosen? How light is the governance? Are the kinds of decisions the governing bodies can make limited by declared process? Is the operation of the system dependent of the voluntary participation of entities outside the governing bodies? Distributed ledgers are young and the methods and modes of governance, along with those entities[...]
Thu, 11 Aug 2016 10:50:12 -0600
Summary: Governance in permissioned distributed ledgers provides a real solution to some of the ad hoc machinations that have occurred recently with non-permissioned blockchains.(image)
This article by Angela Walch from American Banker makes the (excessively snarky) case that distributed ledger developers and miners ought to be held accountable as fiduciaries.
Non-permissioned distributed ledgers like Ethereum will continue to serve important needs, but organizations like banks, insurance companies, credit unions, and others who act as fiduciaries and must meet regulatory requirements, will prefer permissioned ledgers that can provide explicit governance. See Properties of Permissioned and Permissionless Blockchains for more on this.
Governance models for permissioned ledgers should strike a careful balance between what’s in the code and what’s decided by humans. Having everything in code isn’t necessarily the answer. But having humans too heavily involved can open the system up to interference and meddling—both internal and external.
Permissioned ledgers also need to be very clear about what the procedures are for adjudicating problems with the ledger. They can’t be seen as ad hoc or off the cuff. We must have clear dispute resolution procedures and know what disputes the governance system will handle and those it won't.
Governance in permissioned distributed ledgers provides a real solution to some of the ad hoc machinations that have occurred recently with non-permissioned blockchains.
Mon, 25 Jul 2016 20:31:51 -0600Summary: System integration by writing and reading claims on a distributed ledger solves some big problems. Consider a distributed ledger that provides people (among other principles) with an identity and a place to read and write, securely and privately, various claims. As a distributed ledger, it's not controlled by any single organization and is radically decentralized and distributed. In the following diagram, the Department of Motor Vehicles has written a driver's license record on the distributed ledger. Later, John is asked to prove his age at Walmart. John is involved in permissioning both the writing and reading of the record. Further, the record is written so that John doesn't have to disclose the entire driver's license, just the fact that he's over 18. A Distributed-Ledger Integration Walmart and the DMV are interacting despite the lack of explicit integration of their systems. They are interacting via the a distributed ledger that provides secure and private claim presentment. Further, John (the person they're talking about) is structurally part of the conversation. I call this sovereign-source integration since it's based on sovereign-source identity. Even if there were 20 different distributed ledger systems that Walmart had to integrate with, that still less work than integrating with every DMV. And, they can now write receipts when you shop or read transcripts when you apply for a job—all with your permission, of course. Security and privacy is ensured by the proper application of cryptography, including public-private key pairs, digital signatures, and cryptographic hashes. This isn't easy, but it's doable. There's nothing about the scenario I'm painting that is waiting on some technology revolution. Everything we need is available now. I wrote a post a few weeks about about how sovereign-source integration helps solve the problems of building a virtual university. In that article, the student profile (including an LRS) is the distributed, personally controlled integration point. The information in the student profile might all be written as claims on a distributed ledger, but they could also be in some off-ledger system that the distributed ledger just points to. Either way, once the student has provide the various institutions participating in the virtual university with their integration point, the various university systems are able to work together through the integration point instead of needing point-to-point integrations. The Virtual University The world is too big and vast to imagine that we can scale point-to-point integrations to cover every imaginable use case. The opportunities for this architecture in finance, healthcare, egovernment, education, and other areas of human interaction boggle the mind. Sovereign-source integration is a way to cut the Gordian knot. Tags: distributed+ledger blockchain sovrin distributed+systems unhosted integration sovereign+source+identity [...]
Thu, 14 Jul 2016 10:30:06 -0600Summary: We've built a mockup of a computer closet with temperature sensors and fans to demonstrate how pico structures can be used in the Internet of Things and to experiment with Wrangler, our pico operating system. The students in my lab at BYU are running a booth at OpenWest this year. OpenWest is one of the great open source conferences in the US. There are 1400 people here this year. When the call for papers came out this year, I missed the deadline. Not to worry, I decided to sponsor a booth. That way my students can speak for three days instead of an hour. Here's what they're demoing at OpenWest this week. A while back, I wrote a blog post about my work with the ESProto sensors from Wovyn. Johannes Ernst responded with an idea he'd had for a little control project in his house. He has a closet with computers in it that sometimes gets too hot. He wanted to automatically control some fans and turn them on when the closet was too hot. I asked my students—Adam Burdett, Jesse Howell, and Nick Angell—to mock up that situation in an old equipment box. Physically, the box has two pancake fans on the top, a light bulb as a heat source, a ESProto temperature sensor inside the box, and one outside the box. There's a Raspberry Pi that controls the light and fans. The RPi presents an API. We could just write a little script on the RPi that reads the temperatures and turns fans on or off. But that wouldn't be much fun. And it wouldn't give us an excuse to work on our vision for using picos to create communities of things that cooperate. Granted, this example is small, but we've got to start somewhere. The overall design uses picos to represent spimes for the physical devices: two fans and two temperature sensors. There is also a pico to represent the community of fans and one to represent the closet, the overall community to which all of these belong. The following diagram illustrates these relationships. Pico Structure for the Closet Demo The Fan Collection is an important part of the overall design because it abstracts and encapsulates the individual fans so that the closet can just indicate it wants more or less airflow without knowing the details of how many fans there are, how fans are controlled, whether they're single or variable speed, and so on. The Fan Collection manages those details. That's not to say that the Fan Collection knows the details of the fans themselves. Those details are abstracted by the Fan picos. The Fan picos present a fairly straightforward representation of the fan and its capabilities. This demo provides us with a project to use Wrangler. Wrangler is the pico operating system that Pico Labs has been working on for the last year. Wrangler is a follow-on to CloudOS, a pico control system that we built at Kynetx and that was the code underlying Fuse, the connected-car platform we built. Wrangler improves on CloudOS by taking its core concepts and extending and normalizing them. The primary purpose of Wrangler is pico life cycle management. While the pico engine provides methods for creating and destroying picos, installing rulesets, and creating channels, those operations are low-level—using them is a lot of work. As an example of how Wrangler improves on the low-level functions in the pico engine, consider pico creation. Creating a useful child pico involves the following steps: create the child name the child install rulesets in the child initialize the child link the child to other picos using subscriptions Wrangler uses the concept of prototypes to automate most of this work. For example, a developer can define a prototype for a temperature sensor pico. Then using Wrangler, temperature sensor picos, with the correct configuration, can be created with a single action. This not only r[...]