Exploring Self-Sovereign Identity in India

Visiting a fertilizer distribution center near Vijayawada to see Aadhaar in action

I'm just finishing up my travel to Switzerland and India to talk about self-sovereign identity. The trip was amazing and full of interesting and important conversatons.

The TechCrunch event in Zug was very good. I was skeptical of a one-day conference with so much happening in a short time, but thanks to great preparation by those running the show and all the participants, it exceeded my expectations in every way. I spoke on a panel with Sam Cassatt of and Guy Zyskind from Enigma. Samantha Rosestein was the moderator.

But it was the conversations I had with people at the event that really made it interesting. Self-sovereign identity is making noise. In his one-on-one at the event, Vitalik Buterin said “Ultimately, if self sovereign user authentication technology ends up totally failing, that means that it is very difficult for the blockchain space to achieve substantial mass adoption.” In other words, if we can't make SSI work, then blockchain in general is in trouble because the hacks will keep happening.

From Zug, I went to Bangalore for the IEEE inDITA event that the IIW organizers helped plan. It was fun to meet up with Heidi, Kaliya, Doc, and Joyce in India. Along with some site seeing, I also had a great SSI dinner that Joel John and Nitin Sharma organized. It was fun to meet with people who share my enthusiasm for identity.

As you'd expect from the composition of the planning team, the inDITA event was an unconference. There were about 70 people there and we had dozens of sessions. The first day, we ran out of space to hold them all! The venue at IIIT-B was excellent and the IEEE team, especially Munir Mohammed really did a great job organizing the event. I spoke about self-sovereign identity, using SSI for educational transcripts, and how identity intersects with the Internet of Things. I hope this event gains traction because not everyone can make it to IIW in Mountain View. Getting identity discussions happening around the world is important.

By coincidence, Omidyar and the Indian School of Business sponsored an event on Aadhaar, the Indian universal identity system, the same week. Doc, Joyce, and I went over to Hyderabad after the IEEE event and learned a little about Aadhaar from the many expert panelists. Aadhaar serves as a foundation for many other digital systems in India, including food ration distribution, healthcare, and finance. While many panelists brought up concerns and shortcomings, they also highlighted how Aadhaar had positively impacted the lives of the Indian people. Some of the concerns include privacy loss through account linking and exclusion because of system malfunctions or errors.

The highlight of the week, for me, was the Aadhaar field trip that Omidyar organized for Doc, Joyce, and myself to a village outside Vijayawada near India's east coast. We talked with fetilizer distribution agents, farmers, families receiving food distribution, people running the ditribution centers, an insurance office at a local hospital, and a bank officer. They all showed how Aadhaar was used in their respective areas. We saw challenges, but also heard positive stories from people in trenches.

I think there's plenty of opportunity for Aadhaar and SSI to co-exist. As I wrote in Multi-Source Identity:

Your digital identity is made from credentials from multiple sources. You might have a Sovrin-based relationship with your bank. They could provide a Sovrin credential stating you're a customer and maintain a certain balance. Similarly, you could have a relationship with your employer and an employer-issued credential stating you're an employee. And you likely have a relationship with the state, and credentials they issue representing your birth certificate or drivers license. The list goes on. You could have hundreds of relationships and associated credentials in your wallet. You can use any of these, in multiple configurations, to prove things about yourself (with minimal disclosure) to any other party who accepts them.

In a multi-source identity world, Aadhaar is just one more (important) credential that Indian citizens would hold in their wallets. The other government issued documents that are used, for example, in the food distrubtion system could also be in the wallet. Aadhaar doesn't have change how it works now, but simply issue a verifiable credential based on the Aadhaar identity. Once they're available as verifiable credentials, they could be used in any digital scenario where foundation identity information is needed. As a bonus, thanks to minimal disclosure, most of the time the Aadhaar number wouldn't even have to be disclosed.


Identity and India

Aadhaar enrollment drive ar Bareilly, UP, India

The first half of July I'm going to be on the road speaking about self-sovereign identity in Switzerland and at two events in India. This is my first time in Switzerland and India, so I'm looking forward to the trip and meeting lots of interesting people.

The event in Zug is the TC Sessions: Blockchain 2018 event on July 6th. I'll be speaking on self-sovereign identity in an afternoon session.

There are two events the following week in India. The first is the IEEE-SA InDITA Conference in Bangalore on July 10-11. DITA stands for "Digital Inclusion through Trust and Agency" and I like that theme. The Internet Identity Workshop organizers, Kaliya Young, Doc Searls, Heidi Saul, and myself, are helping organize this event, so it will be an unconference/open space event like IIW. I'll be speaking at this event on how we're using self-sovereign identity in a university setting at BYU.

Finally, I'll spend a few days in Hyderabad at the DIRI International Conference on Aadhaar. This event is being sponsored by the Digital Identity Research Initiative at the Indian School of Business. Several of us are headed to this after the InDITA event. I'm looking forward to a deeper understanding of Aadhaar.

From India, I fly home through Hong Kong. On this trip, I'll circumnavigate the globe. First time I've ever done that, so a trip of firsts! If you're going to be at one of these events, please look me up. I'd love to meet you and talk identity.


Photo Credit: Aadhaar Enrollment Drive from Ravishyam Bangalore (CC BY-SA 4.0)


Multi-Source Identity

Audio Mixer

In the physical world, people collect and manage identity credentials1 from various sources including governments, financial institutions, schools, businesses, family, colleagues, and friends. They also assert information themselves. These various credentials serve different purposes. People collect them and present them in various contexts. When presented, the credential verifier is free to determine whether to trust the credential or not.

Online, identity doesn't work that way. Online identity has traditionally been single-source and built for specific purposes. Online, various, so-called "identity providers" authenticate people using usernames and passwords and provide a fixed, usually limited set of attributes about the subject of the identity transaction. The identity information from these systems is usually used within a specific, limited context. Social login allows it to be used across contexts but the kind of information shared is limited and its provenance is often difficult to determine. These identity systems are not interoperable, making it hard to combine attributes from one with those of another. Consequently, online identity is one-dimensional and has limited value. At Sovrin we're changing that.

Sovrin doesn't give you an identity—we're not an identity provider. Rather Sovrin enables a rich ecosystem of third party credentials, just like in the physical world. Your identity in Sovrin is represented by a collection of relationships along with credentials from many trusted sources. I call this "multi-source identity." Multi-source identity is decentralized in ways that single-source identity systems can never be. Decentralization enables a richer set of identity transactions; supports ad hoc, emergent use of credentials; and ensures that an identity owner is never at the mercy of just one identity authority.

Multi-source identity emphasizes relationships instead of identifiers. Identifiers still exist, but they're not the primary focus. In Sovrin, each relationship is represented by a pairwise, pseudonymous identifier exchange2. These identifiers are linked to public-private keypairs so that each relationship can be validated by either party and supports private, confidential communications between the parties to the relationship.

Mutual exchange of keys is a big step up from SSL-mediated transactions on the Web where only one-side is cryptographically authenticated. In Sovrin, mutually authenticated connections are built into every relationship. When you use Sovrin to authenticate with your bank, they know it's you and you know it's them. Rather than an asymmetric relationship where one side uses cryptographic means to authenticate itself and the other uses a mishmash of user names and passwords, both sides symmetrically use strong, cryptographic technology to authenticate the other.

Your digital identity is made from credentials from multiple sources. You might have a Sovrin-based relationship with your bank. They could provide a Sovrin credential stating you're a customer and maintain a certain balance. Similarly, you could have a relationship with your employer and an employer-issued credential stating you're an employee. And you likely have a relationship with the state, and credentials they issue representing your birth certificate or drivers license. The list goes on. You could have hundreds of relationships and associated credentials in your wallet. You can use any of these, in multiple configurations, to prove things about yourself (with minimal disclosure) to any other party who accepts them.

Multi-source identity allows for flexible and complex identity transactions—just like in the physical world. To see some examples of this, take a look at these two videos3.

In the first, the identity owner, a recent college graduate, collects credentials from the government, her college, her employer, and bank. The credentials are used sequentially: she uses her Government ID to get her college transcript, the transcript to apply for a job, and then the employment verification credential to apply for a loan.

In the second, the identity owner has credentials from their telco, bank, and drivers license division. He connects to an airline and uses these credentials these credentials in concert to provide passenger info so that he can buy a ticket and get a boarding pass (which is issued as a Sovrin credential).

These are just a few examples of how multi-source identity enables online identity transactions that are nearly impossible to imagine using the single-source identity systems of the past. The Internet enabled a rich, decentralized ecosystem of message exchange that could never have been supported by the walled gardens of Compuserve and AOL. Similarly, Sovrin enables a richer, decentralized ecosystem of identity transactions that can never be realized with the single-source identity systems we've used to date. That's why I call Sovrin the Internet for Identity.

If you're interested in exploring the details of how this work further, please see the Sovrin whitepaper.


Endnotes
  1. Credentials may be too strong a word for some of the documents we treat as identity documents. For example, a note from a parent to a teacher about a child might not be considered a "credential" by most people, but it would qualify in what I'm trying to describe. In the interest of succinctness, I'll just use it for this post.
  2. I was recently reminded of a paper on Personal Channels that Drummond Reed and I wrote back in 2012. In it we list ten benefits of personal channels. Most of these are relevant to multi-source identity and relationships as envisioned in Sovrin.
  3. Both of the demos in these two videos are real—they are not conceptualizations, but are using Sovrin's test network for the DID and verifiable credential exchange.

Photo Credit: Audio Mixer from pxhere (CC0)


Coherence and Decentralized Systems

Coherence in Chaos

We take the Internet for granted, not realizing that such a global, decentralized system is a rare thing. Protocols, rightly, get credit, but they alone are insufficient. TCP/IP did not create the Internet. The Internet is not just a set of protocols, but rather a real thing. People and organizations created the Internet by hooking real hardware and communication lines together. To understand the importance of this, we need to understand what's necessary to create social systems like the Internet.

Social systems that are enduring, scalable, and generative require coherence among participants. Coherence allows us to manage complexity. Coherence is necessary for any group of people to cooperate. The coherence necessary to create the Internet came in part from standards, but more from the actions of people who created organizations, established those standards, ran services, and set up exchange points.

Coherence enables a group of people to operate with one mind about some set of ideas, processes, and outcomes. We only know of a few ways of creating coherence in social systems: tribes, institutions, markets, and networks1. Startups, for example, work as tribes. When there's only a small set of people, a strong leader can clearly communicate ideas and put incentives—and disincentives—in place. Coherence is the result. As companies grow, they become institutions that rely on rules and bureaucracy to establish coherence. While a strong leader is important, institutions are more about the organization than the personalities involved. Tribes and institutions are centralized--someone or some organization is making it all happen. More to the point, institutions rely on hierarchy to achieve coherence.

Markets are decentralized—specifically they are heterarchical rather than hierarchical. A set of rules, perhaps evolved over time through countless interactions, govern interactions and market participants are incented by market forces driven by economic opportunity to abide by the rules. Competition among private interests (hopefully behaving fairly and freely) allows multiple players with their own agendas to process complex transactions around a diverse set of interests. Markets don't displace institutions completely but do help institutions process transactional exchanges.

Networks are also decentralized. The rules of interaction are set in protocol. But, as I said earlier, protocol alone is not enough. Defining a protocol doesn't string cable or set up routers. There's something more to it. One form of organization doesn't usually supplant the previous, but augments it. The Internet is the result of a mix of institutional, market-driven, and network-enabled forces. The Internet has endured and functions because these forces, whether by design or luck, are sufficient to create the coherence necessary to turn the idea of a global, public decentralized communications system into a real network that routes packets from place to place.

My interest in coherence is driven by efforts to create a global, public, decentralized identity system that we call Sovrin. Sovrin is an identity network that, like the Internet, achieves coherence through a combination of institutional, market-driven, and network-enabled forces. I think of Sovrin as the Internet for Identity. The Sovrin network is not owned by anyone, but, like the Internet, is created through the cooperation of many people and organizations. Sovrin is seeking to create a global, decentralized, identity network that is open to all. That's a little bit different thing that creating a standard or a protocol.

When I say Sovrin is "public" I mean that we intend for it to be a public good that anyone can use so long as they adhere to the protocols, just like the Internet. Public spaces require coherence. Coherence in Sovrin springs from the ledger, the protocols, the trust framework, standards, and market incentives. These gives Sovrin greater coherence than a protocol alone can achieve.

  • The ledger creates a decentralized service where various participants can exchange important information without the need for a central authority. But like the Internet, the ledger requires multiple organizations to commit real resources. The Sovrin ledger is a significant piece of the Sovrin network. The ledger provides a global registry for identifiers. This has several significant advantages over DNS as a registry. DNS-based identifiers aren't permanently owned. This can present real security concerns. With a ledger, identifiers can be persistent and non-reusable. Second, DNS-based solutions require that every site that wants to run registry functions has to install and maintain software for that purpose. This incents centralization of the directories. With a ledger-based solution, a global network does this without special effort on the part of participants.
  • The trust framework is an agreement that is administered by the Sovrin Foundation. The trust framework makes shared goals and principles explicit so that the various participants in the system can work together. The trust framework is the basis for shared action and processes.
  • Standards like those being developed for Decentralized Identifier (DID) and the verifiable credentials are important for interoperability, but more so specifications and standards on how to communicate with the ledger and the peer-to-peer communication of agents are critical to portability and the rise of a functional ecosystem of software that isn't controlled by a single vendor.
  • Market incentives have traditionally been difficult to incorporate into a networked ecosystem, but the rise of tokens is a recent development that promises to change this. Token-based ledgers come with incentives to participate and thus are self-sustaining in ways that DNS-based identifier registries can't be. This also alleviates power imbalances where large companies have an advantage relative to individuals. As Chris Dixon says "Token networks ...[align] network participants to work together toward a common goal—the growth of the network and the appreciation of the token." In short, tokens provide a means for establishing coherence.

Someone asked me recently how Sovrin differed from an identity protocol like OpenID Connect. The factors that give rise to coherence are the primary difference between a protocol like OpenID Connect and something like Sovrin. Simply put, Sovrin is a network and OpenID Connect is not. This is where I think we've largely gone wrong in building decentralized systems in the past. We've shied away from putting a stake in the ground and building a thing. Instead we've defined protocols and allowed the network effects to accrue to centralized companies who can establish the coherence necessary to create a real thing. My strong belief is that real networks are necessary for enduring decentralized systems.


Endnotes

  1. To explore this more, see this John Robb commentary on David Ronfeldt's Rand Corporation paper "Tribes, Institutions, Markets, Networks" (PDF).

Photo Credit: Coherence in chaos from Dhiren Mistry (CC BY 2.0)


Building Your Business on Sovrin: Domain-Specific Trust Frameworks

Working in a Framework

In Decentralized Governance in Sovrin, I described how the Sovrin Network is governed. The centerpiece of that discussion is the Sovrin Trust Framework. The trust framework serves as the constitution for Sovrin, laying out the principles upon which Sovrin is governed and the specific requirements for various players in the Sovrin Ecosystem.

In A Universal Trust Framework, I say “a trust framework provides the structure necessary to leap between the known and unknown.” The idea is that online we often lack the necessary context to reduce the risk around the decisions we make. A trust framework defines that context using agreement, process, and technology so that people can make decisions with significantly less risk.

In this post, I want to talk about how organizations can use the Sovrin Network as a trustworthy infrastructure for creating businesses or processes that require strangers to trust one another. This happens by building domain-specific trust frameworks on top of Sovrin.

Exchanging Claims and Proofs

Let’s begin by reviewing Sovrin-based credentials and how they are used.

Issuers issue and identity owners accept Sovrin credentials that are based on emerging Verifiable Claims standards. Identity owners store these credentials in their digital wallet. A credential consists of a set of claims. Identity owners present proofs based on those credentials to verifiers. Proofs can be about any assertions in the credentials the identity owner holds.

Claim Issuing and Presenting
Claim Issuing and Presenting (click to enlarge)

The preceding figure shows how this might work in a specific use case. Suppose your employer is using Sovrin. They issue a Sovrin credential that includes claims about your employment status and current salary. The credential includes a reference to a credential definition (on the Sovrin ledger) that contains your employer’s public decentralized identifier, or DID, (also on the Sovrin ledger) and a reference to a schema (also on the Sovrin ledger) that describes the claims in the credential. The credential is signed by your employer, using their public DID. You store that credential in your Sovrin wallet.

Later, you apply to your bank for a loan. Before the bank processes the loan, you need to prove to them that you’re employed and that you make at least $75,000 per year. Using your Sovrin wallet1, you are able to prove what the bank needs to know without revealing your actual salary or any other claims that might be in the credential your employer provided. The proof process also ensures, through countersigning, that the bank sees these proofs based on their DID for you even though the credential was issued to you by your employer based on the DID they have for you.2

Of course, your wallet also holds other credentials from other issuers. For example, you might have a credential from your bank that you can use to prove your account information to your employer or any other party.

The beauty of this approach is that verifiers never need to contact issuers to verify the assertions or understand how they’re formatted. Anything they need to use to verify the credential is on the ledger. This results in immense benefits for scalability and reliability3.

What Sovrin Promises

The preceding example credential exchange shows how the credential-supported proof provides trustworthy attributes to the bank. But it’s worth teasing that apart and determining why the attributes can be trusted. Let’s start with what Sovrin is promising with respect to the credential that is being issued and the proof that is based on it.

Sovrin’s promise is based on the Sovrin Trust Framework. As I pointed out in Decentralized Governance in Sovrin, the framework governs the operation of the network and the code that it runs on.

Sovrin promises the following:

  • The DIDs can be resolved using the Sovrin ledger and the resulting DID document that can contain a public key and an endpoint associated with that DID.
  • The schema can be retrieved from the Sovrin ledger and hasn’t been tampered with.
  • The definition for the credential can can retrieved from the ledger and hasn’t been tampered with.
  • The credential can be validated as not having been tampered with.
  • The credential was given to the identity owner with whom the employer has a relationship.
  • The proof is about the identity owner with whom the bank has a relationship.
  • The identity owner who presents the proof is the same person to whom the credential was issued4.
  • The credential has not been revoked by the issuer.

The Sovrin Trust Framework is a general-purpose or universal trust framework that is meant to provide a set of universal features that form the foundation for trust transactions. The preceding list of Sovrin promises are all part of that trust framework. They are shored up by legal documents, business processes, and technology.

What Sovrin Does Not Promise

The promises made by Sovrin are important and foundational. But what the bank really wants to know is “are you employed?” That requires promises that Sovrin can’t make:

  • The identity owner is a real person.
  • The employer is a real business.
  • The bank is a real bank.
  • The identity owner is employed by the employer.
  • The salary figure comes from the employer.

If Sovrin doesn’t keep its promises, then the bank can’t trust anything. But even if Sovrin runs perfectly, the bank is still short of the assurances it needs to make decisions. That’s where domain-specific trust frameworks come in.

Domain-Specific Trust Frameworks

A domain-specific trust framework works on top of the Sovrin trust framework and contains the technology, business processes, and legal agreements necessary to trust the content of the claim. For example, in the scenario above, a domain-specific trust framework would enable the bank to trust the proof that you’re employed.

Let’s walk through each of the promises Sovrin can’t make and discuss who can make them and how.

You Are a Real Person

The bank knows you’re a real person because they have a relationship with you, memorialized by the exchange of Sovrin DIDs. As part of their new customer process, they performed a Know Your Customer (KYC) process as mandated by law. They associate the results of that with the DID you gave them to represent you. So when you contact them with that DID, they know the account belongs to a real person.

Your Employer is a Real Business

Knowing the employer is a real business is a little harder. Even if the bank knows the employer by name, how do they know that the credential was issued from that entity. As I pointed out in Sovrin Web of Trust, there are several options:

  1. The employer could publish their public DID (the one associated with the claim definition that underlies the employment verification) on their Web site or some other well known place so that it is easy to verify. This method takes you out of the Sovrin system and into the hierarchical public key infrastructure since you’d verify the website using a standard SSL certificate from a traditional certificate authority.
  2. They could offer supporting claims that show they are a legitimate business. These claims would come from what are called trust anchors in Sovrin, trusted entities who can prove who they are based on others who vouch for them. For example, the government, acting as a trust anchor, could provide claims to registered businesses. The Government of British Columbia is piloting this right now.
  3. The preceding two steps could be used together in a hybrid verification. InfoCert, that largest European cerificate authority, is already a Sovrin Steward and could issue a Sovrin credential to go along with the TLS certificate the issue to the employer. This Sovrin credential would be backed up by the same process they use to verify the business as part of issuing the TLS certificate.

Businesses often have credentials from others that are part of their web of trust—think of all the “Chamber of Commerce” decals you see on the windows of local shops. The employer would have credentials from numerous government agencies, business partners, and trade associations that could all be used to back up the credentials they issue.

The Bank is a Real Bank

The person knows the bank is a real bank for the same reason the bank knows the person is real: the DID exchange. One of the important and often overlooked benefits of a DID exchange is that both sides can authenticate the other. Mutually authenticated connections are the default in Sovrin and one of its most powerful features. This is in contrast to TLS, which has been a one-sided affair in practice.

In our example, the bank is verifying the credential, so it obviously knows that it’s a real bank, but the identity owner want to know it's real when they open an account. If they did it physically, then they know of themselves, but if they enrolled online, they might have questions. The bank could be validated in the same way as the employer. For example, in the US, financial institutions are certified by different government institutions depending on whether they’re national banks, state-chartered banks, or credit unions. In any case, these certifying agencies could issue credentials to the institution that could be checked by the customer (using their wallet) as part of the enrollment process or at any other time.

You are Employed by the Employer and Have a Certain Salary

The credential itself is making the claim that you are employed by the employer and that the salary is a certain amount. Sovrin links all this up, but the bank would need to validate the claim schema and definition and understand what it means. This validation process would be internal to the bank.

In Sovrin, the schema is a document that is written to the ledger. Think of it as the description of what fields the schema contains and what the fields mean. The schema is readable and understandable by anyone—they are public documents.

Schemas can be reused. Ideally the schema is not specific to the employer, but is used by many employers for employment verification. An industry trade group or a large vendor of ERP systems might, for example, author the schema with inputs from many parties. Doing so would ensure that a wide range of organizations understand and recognize it. The schema becomes a standard, de facto or de jure, for employment verification.

I believe that there will be a relatively rapid agreement on schemas, reinforced by trust frameworks, in many fields. But this does not preclude anyone from creating any schema they want whenever they want for their own purposes.

Claim schema are automatically versioned. When a new schema is created, the original schema doesn't go away, so credentials issued with the old schema can still be used. Credentials issued with the new schema refer to that new schema and not the old one.

The claim definition references a claim schema and is written to the ledger by a specific entity. In our example, the employer writes a claim definition that references the schema and includes its public DID.

Depending on the use case, an industry group might do more than merely publish the schema. They might also create standards around how the schema is to be used. These standards would be enforced by legal contract and required business processes with compliance attested to by claims from the standards group to any organization creating claim definitions that use the schema. That way claim inspectors could know that the claim was created in accordance with an accepted process, increasing trust in the claim. How would they know? By means of a Sovrin credential from the standards group, of course.

Sovrin’s Role in Domain Specific Trust Frameworks

A domain-specific trust framework is a collection of policies, legal agreements and technologies that provides the context for claims in a given domain. Sovrin Foundation provides a structure and supporting systems for groups defining trust frameworks.

Sovrin works as a globally decentralized dictionary for schema definitions, with no central authority dictating what schemas, definitions, and claims can or can't be issued. This makes it uniquely flexible. Anyone can issue credentials about anything, enabling the "long tail" of use cases to be easily addressed.

Sovrin Foundation provides the basis for the Sovrin web of trust. As discussed in the Sovrin Trust Framework, Sovrin Trustees provide the foundation for this web of trust. They select Stewards who validate transactions on the Sovrin ledger5. Stewards can vouch for others. Anyone using the Sovrin network is part of this general web of trust.

Beyond this general web of trust, domain-specific trust frameworks can determine their own web of trust. This already happens in the physical world. For example, colleges and universities in the US are accredited by independent organizations. Brigham Young University, where I work, is accredited by the Northwest Commission on Colleges and Universities. They already have a process for accrediting member organizations. They could simply rely on that process and any attendant legal agreements to issue and revoke Sovrin credentials that reflect their determinations concerning the accredidation status of member institutions.

Other uses of Sovrin may not have a physical world counterpart. For example, suppose you wanted to start a decentralized version of AirBnB. One of the roles that AirBnB plays is identifying and attesting to certain attributes for renters and hosts. A decentralized AirBnB may want to establish a process for vetting renters and hosts and issue and revoke claims in accordance with that process. This decentralized AirBnB might define and include claim insurance for both renters and hosts in the event the process breaks down. The processes that define how vetting works, the legal agreements that hold parties to the processes, and the provisions for recourse and restitution via insurance are all part of the domain-specific trust framework for this ecosystem.

For anyone wishing to build domain-specific trust frameworks for an existing or planned business, Sovrin Foundation can help with technical advice about schema and claim definitions as well advice on how to go about creating and governing the legal agreements and business processes necessary to create environments where trust abounds.


Endnotes

  1. A wallet in Sovrin is an agent that holds credentials on behalf of the identity owner and speaks the Sovrin agent-to-agent protocol.

  2. Your employer and bank have a different DID for you to prevent correlation.

  3. Specifically, issuers do not need to maintain always-on infrastructure to answer questions about credential validity and credential transactions are done peer-to-peer.

  4. Technically it could also be presented by the identity owner's guardian if the identity owner is in a guardian relationship. But the Trust Framework considers that to be the same as the identity owner presenting it themself

  5. When Stewards "validate" a transaction, they are merely achieving consensus with other Stewards about the validity of the transaction, not it's content. Stewards aren't making judgments about the assertions inside of any transaction on Sovrin.

Photo Credit: Framework from kaz z (CC BY 2.0)


What We Learn about Self-Sovereignty from CryptoKitties

Late last year CryptoKitties burst into the blockchain world. If you haven't been paying attention, CryptoKitties is a Web site that uses a browser-based wallet (MetaMask) to sell (for Ether) little virtual kitties. Once you have a kittie, you can breed it with others, to create new kitties. Each one is a unique individual created with some genetic algorithm. Some Gen 0 or Gen 1 kitties have sold for ridiculous amounts of money. If you were around in the 90's when the Web was taking off, think Beanie Babies meets Blockchain and you'll get the idea1.

Except it's a little more interesting than Beanie Babies ever were because each CryptoKittie is really a non-fungible token on the Ethreum blockchain. This means each kittie has some interesting properties:

  • Each kittie is disiguishable from all the rest and has a unique identity and existence
  • Each kittie is owned by someone. Specifically, it is controlled by whoever has the private keys associated with the address that the kittie is tied to.

Because of these properties, a CryptoKitty can be remixed and used in other applications. Just today, I heard that they are being sold on OpenBazaar for Bitcoin. Someone could create a game that uses the kitties that were part of the CryptoKitty game as characters in a new game. Because they are not just a line in some centralized company's database, they really do belong to the people who bought them and who can use them for anything they like.

Why is this important? You can go on Amazon and "buy" a digital copy of a movie or song. But do you really own it? Do you have a unique copy that is controlled only by you? Not likely. In the wake of Louis C.K's sexual miscoduct allegations, many services cut their ties to the comedian. I'm not defending his actions in any way, but people who "bought" that content didn't own it, because someone else's decisions took the content away from them.

That can't happen with a CryptoKittie (almost, keep reading). The token representing the kittie is mine and under my control. That's the idea of self-sovereignty. You control something without others being able to take the asset away from you. As 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.

The border, in this case, is defined by Ethereum, the ERC-721 specification, the smart contract, and my private keys in my wallet. The only thing that can take my CryptoKitty away from me is Ethereum going away. They are a non-fungible asset like art and other collectible. They can be traded and they can be repurposed, but only with my consent.

The Fly in the Ointment

What I wrote above is almost true. The structure of individual ownership is all there2. There is one problem with CryptoKitties as a model of self-sovereignty: the CryptoKittie smart contract has a "pause" function that can be executed by certain addresses. This is probably a protection against bugs—no one wants to be the next theDAO—but it does provide someone besides the owner with a way to shut it all down.

I have no idea who that someone is and can't hold them responsible for their behavior—I'd guess it's someone connected with CryptoKitties. Whoever has control of these special addresses could shutdown the entire enterprise. I do not believe, based on the contract structure, that they could take away individual kitties; it's an all or nothing proposition. Since they charged money for setting this up, there's likely some contract law that could be used for recourse. Nevertheless, we need more discussion of formalized governance in decentralized systems. How do we balance the need for security (the kill switch) with the rights of the people who own kitties?


Endnotes:

  1. Next time you see me in person, I've got a funny story about Beanie Babies and iMall.
  2. Addresses that pay for kitties are linked to those kitties in the smart contract. My understanding is that if the smart contract that controls CryptoKitties were updated, the old contract is still there and would control the kitties created by it. Because the contract is public, owners can always interact with their tokens.


Sovrin Foundation Welcomes Nathan George

The Sovrin Foundation is excited to announce that we have hired of Nathan George as our Chief Technology Officer. Nathan was previously Chief Architect at Evernym, Inc. He has been instrumental in maintaining the Hyperledger open-source Project Indy, which is sponsored by the Sovrin Foundation. Nathan comes with a wealth of experience that will help Sovrin thrive and reach its full potential.

I’m very excited to have Nathan join the foundation. The Sovrin Foundation is much more than an advocacy organization for self-sovereign identity. As I wrote in Decentralized Governance in the Sovrin Foundation, the foundation exists to administer the Sovrin Trust Framework and a significant aspect of that entails designing and implementing protocols, managing Project Indy, and supporting the Sovrin Stewards in their operation of the network nodes. These tasks are technical and having a full-time technology executive focused on this is critical to the success of the network, and the foundation itself.

The Sovrin Foundation technology goals, on which Nathan will have primary focus, include:

  • Planning and following a roadmap that outlines Sovrin development
  • Implementing a Sovrin RFC and Improvement Project process
  • Supporting steward onboarding and operation
  • Managing the release process that prepares code for Stewards
  • Monitoring network operation and reliability
  • Impacting design of the various components of the Sovrin ecosystem
  • Supporting feature development through bounties and other developer incentive programs
  • Participating in standards processes that impact Sovrin

Hiring a CTO represents a big step along the path to self sustainability for the Sovrin network. A huge part of being self sustaining is technical independence. Having a CTO in the Sovrin Foundation will allow us to drive many technical developments and coordinate our open source projects from within the foundation.


Photo Credit: Circuits from Max Pixel (CC0)


Decentralized Governance in Sovrin

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


Endnotes:

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

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

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


Announcing the Sovrin Whitepaper

Sovrin Logo

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

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

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

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

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

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

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


Secure Pico Channels with DIDs

Encryption Flow

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

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

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

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

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

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

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

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