Last week was the 28th semi-annual Internet Identity Workshop (IIW). There were 129 session conducted by people from all over the world and about many different aspects of identity. There were technical discussions, standards works, policy debates, and lots of demonstrations. I'll post a link to the Book of Proceedings when it's available so you can read about them yourself.1
One thing that stood out to me is the impact self-sovereign identity is having. There were several dozen sessions on SSI. I was excited to see seven different implementations of Indy Agents that were working together and combined to create several demonstrations of credential exchange.
Evernym and Onfido did a demonstration of the Connect.me wallet and the Onfido identity verification service. You can do it too. Download the Connect.me app to you phone and then in the "Menu" select the Onfido item and start getting a real, live, production identity verification based on an existing identity credential such as a passport or drivers license. Once you do, you'll have a connection to and credential from Onfido.
You can also go to try.connect.me and walk through a demonstration of how credential exchange can work, using actual (though not real) credentials in your wallet
Vonx (BC Gov), StreetCred, and Spark NZ showed a demonstration using a StreetCred wallet to connect to and get credentials from two different services: a Vonx email verification service and an IIW attendee verification service. Once attendees had both of those credentials, they could use them to unlock a box that Spark had built and brought to the workshop.
IDRamp showed a demonstration of their product that can add credentials to any system that speaks SAML. They were demonstrating using a wallet to present a credential to log into Slack and Rocketchat. This is a production service that can credentialize any SAML service.
Pico Labs, my lab at BYU, demonstrated picos that acted as Hyperledger Indy agents and were able to connect to each other as well as other Indy agents like the AgentBook demo from Vonx. Picos are designed to act as digital twins or device shadows for the Internet of Things (IoT). Having agent-enabled secure messaging and credential exchange could be very useful for IoT products.
What got me excited about these demonstrations was that there were seven different organizations interoperably working in an ecosystem for credential exchange. While the rely on common libraries like Hyperledger Indy, they are separate code bases from different development teams that work together. This is a big development in the world of self-sovereign identity, demonstrating the reality of data exchange that is credential-based, secure, and private.
Decentralized identifiers are one of several foundational technologies for building a metasystem for self-sovereign identity. I wrote about verifiable credentials and their exchange previously. Just like the Web required not only URLs, but also a specification for web page formats and how web pages could be formatted, self-sovereign identity needs DIDs, a protocol for creating DID-based relationships, and a specification and protocol for verifiable credential exchange.
Identifiers label things. Computer systems are full of identifiers. Variable names are identifiers. Usernames are identifiers. Filenames are identifiers. IP numbers are identifiers. Domain names are identifiers. Email addresses are identifiers. URLs are identifiers.1 Any time we use a unique (within some context) string to label something for quick reference, we're giving it an identifier. A computer system uses identifiers to correlate all the information it knows about a given thing. The mis-use of identifiers can lead to unwanted, even dangerous correlations.
Identifiers need context to be meaningful. For example, a string of digits might be a phone number, but we have no way of knowing for sure without context. Online context is often provided by a prefix. For example, mailto:email@example.com is an email address, but acct:firstname.lastname@example.org is an account identifier.
Web-based identity systems have largely defaulted to using email addresses as identifiers. Everyone has one. And someone else has done the work of ensuring uniqueness since email addresses must be globally unique. But email addresses are also less than ideal as identifiers for several reasons:
First, email addresses have a real, intended use (sending email) and so might change for reasons unrelated to their use as an identifier.
Second, email addresses are generally correlatable. If you use the same email address for all your account identifiers, it's easy to track your activity at all those different places.
Third, email addresses are generally administered by someone else who can take them away. Even if you use your own domain name, you're just renting that and may give up control in the future.
Fourth, email addresses have limited global resolvability. All you can do is send an email message to the owner.
Lastly, email addresses are reusable. If you stop using an email address the administrator of the email system may reassign it, decreasing security and privacy.
Decentralized Identifiers, or DIDs, are a new kind of identifier that solves the problems outlined in the last section. As noted above, DIDs are one of the foundational technologies of self-sovereign identity. The DIDs specification is being developed inside the W3C Credentials Community Group. Let's explore the properties of DIDs and look at how they are formatted.
Decentralized identifiers should be implemented so that they have these important properties:
non-reassignable—DIDs should be permanent, persistent, and non-reassignable. Permanence ensures that the identifier always references the same entity. As a result, DIDs are more private and more secure than identifiers that can be reassigned such as a domain name, IP address, email address, or mobile number. Permanence is vital for user control and self sovereignty.
resolvable—DIDs are made useful through resolution. Resolution ensures that a DID is actionable. We'll discuss how DID resolution works in more detail below.
cryptographically verifiable—DIDs are designed to be associated with cryptographic keys and the entity controlling the DID can use those keys to prove ownership. That can happen in several ways. The result of resolving a DID may be cryptographically signed to ensure its integrity. The resolution also provides one or more public keys associated with the DID. Using cryptographic keys, the owner can prove they are in control of the DID. Parties who have exchanged DIDs can mutually authenticate each other and encrypt their communication.
decentralized— DIDs are designed to function without a central registration authority. Depending on the DID method specification for a given class of DIDs, they might also be created and updated outside the purview of any single party or entity, increasing censorship resistance.
The syntax of a DID is fairly simple and designed to support different decentralization methods. The following diagram shows the primary, required components of a DID:
Each component is separated by a colon. The scheme, did, is fixed for all DIDs and alerts software seeing the DID that it is a DID. The method specifies how the DID is created, updated, and resolved. In the preceding figure, the method is sov. The method-specific identifier is an alphanumeric string that is guaranteed to be unique within the context of the method.
Useful identifiers have a means of discovering what the identifier means. Discovery is performed in the manner outlined in the DID method. The DID specification outlines the necessary operations any method must implement. Different methods can support their own way of performing resolution using a specific blockchain or other storage system. The method outlines the way to create, retrieve, and update the DID and it's associate DID Document. For example, the did:sov method outlines how to create, lookup, and update the DID on the Sovrin ledger. A resolver can use the method to find the routines necessary for interacting with a given identifier. Methods allow a variety of systems to serve as repositories for DIDs.
DIDs are resolved to a DID Document. Resolution is the act of looking up the DID Document for a specific DID using the method given by the DID's method component. Taken as a whole, DID infrastructure functions as a global, decentralized key-value store where DIDs act as the keys and DID Documents are the values.
While the expectation is that these repositories will be decentralized, there's nothing in the specification that forces that. Any storage system could potentially have a DID method associated with it. Beware that some repositories may not be able to fulfill the non-reuse and permanence properties that are expected of DIDs.
DID Documents describe the public keys, authentication protocols, and service endpoints necessary to initiate trustworthy interactions with the identified entity. A DID Document is a JSON-LD document that contain the following six, optional components:
The DID that points to the DID Document, identified by the key id.
A list of public keys identified by the key publicKey.
Lists of protocols for authenticating control of the DID and delegated capabilities identified by the key authentication.
A set of service endpoints, usually URLs, that allow discovery of way to interact with the entity that the DID identifies identified by the key service.
Timestamp indicating when the DID Document was created and updated for auditing the DID Document identified, respectively, by the keys created and updated.
A digital signature for verifying the integrity of the DID Document identified by the key proof.
DID Documents can use other JSON-LD contexts to extend the DID Document and aid in discovery. For example, the data model could be extended to include the entity's RSS feed by referencing a JSON-LD context that describes RSS feeds.
The following is an example of a minimal DID Document taken from the DID specification2:
The DID Document is the root record for a decentralized identifier that can reference not only what's in the DID Document itself, but also any information from the service endpoints. This is accomplished by adding selectors, paths, query parameters, and fragments to the DID. With the exception of selectors, which are specific to DIDs, the syntax of these is familiar to anyone acquainted with the syntax of a URI.
The selector is used to identify a particular part of the DID Document. Selectors follow the DID itself and are delineated with a semicolon. In the preceding DID Document, there is only one service. Nevertheless, it can be selected using the following DID:
If the DID also includes a path, that is appended to the URL given in the service's serviceEndpoint attribute before the endpoint is called. For example, the following DID:
Through this mechanism, DIDs provide a permanent, resolvable identifier for any Internet service. For example, If one of the service endpoints in my DID Document is for email, then I can change my email address at will and anyone holding that DID will still be able to reach me. All I need to do is to be sure to update the DID Document when I change my email.
Public and Private DIDs
The preceding use case—putting my email in a DID Document—might be a privacy problem if I don't want my email to be publicly readable. Fortunately, not all DIDs are public. Identifiers can be, in the language of Kim Cameron (PDF), omnidirectional or unidirectional. Kim says in reference to his fourth law, Directed Identity:
A universal identity system must support both “omnidirectional” identifiers for use by public entities and “unidirectional” identifiers for use by private entities, thus facilitating discovery while preventing unnecessary release of correlation handles.
Sovrin supports public DIDs, written to the ledger and resolvable by all—omnidirectional identifiers. Sovrin also supports private DIDs, exchanged between parties to a relationship and resolvable only within that relationship—unidirectional identifiers.
The availability of private DIDs has significant advantages. Practically speaking, private DIDs allow for greater scalability of the DID resolution infrastructure since the vast majority of DIDs are private and those are resolved on a peer-to-peer basis rather than through access to some shared piece of infrastructure such as a distributed ledger.
More importantly, as Kim says about directed identity, private DIDs reduce access to correlatable identifiers by third parties increasing privacy protections. Private DIDs are critical infrastructure for a key part of the Sovrin architecture: peer relationships.
The key to sovereignty is that all entities are peers. I have the same rights you do. The beauty of sovereignty isn't complete and total control, but rather balance of power that leads to negotiations about the nature of the relationships between various entities in the system.
In a world of identity systems based on decentralized identifiers, people do not create accounts at online service providers and then merely exist within that administrative system. Rather, people create relationships with other online entities and relate as peers.
To see how this works, imagine that you have recently been hired at a new job. Your new employer, ACME Corp, has a public DID that they use for issuing verifiable credentials. But as part of your employee onboarding, they and you will each create and exchange private DIDs. Because DIDs are cryptographically verifiable, you now each have a secure, channel to the other. You can use these DIDs to mutually authenticate when a connection is established, and to encrypt your communications.
This DID-based peer relationship is based on software agents that act for each party, maintain DIDs, resolve them, and facilitate cryptographically secure communication. The connection is truly peer-to-peer without some other platform in the middle. Apps and services built on top of these peer relationships can use these secure communication channels without being party to the private keys that secure them and ensure their integrity.
Since a DID Doc is JSON-LD and can be extended with other contexts, it can be extended to include other information. For example, you could extend the DID Document you share with your employer to include your home address and bank account information. Whenever those change, you'd update that DID Document and your employer would automatically see the changes.
Since the DID with selectors, fragments, and paths provides a way to resolve this information at will, the employer could merely store DIDs for that information rather than the information itself and resolve it at the local agent each time it is needed. Anyone breaking into their systems and stealing the reference wouldn't have permission to resolve the reference and get sensitive information. This provides the means for an employee, say, to share information with an employer that can be trusted and resolved at will without the employee having to issue a verifiable credential.
DIDs and the Identity Metasystem
In The Laws of Identity, I make the case for Sovrin being an identity metasystem—a universal foundation upon which other identity systems can be built. DIDs and DID Documents are a big part of the metasystem. Sovrin is designed to support the use of DIDs and DID Documents. Furthermore, Sovrin agents manage DID-based peer relationships, verifiable credential exchange, public and private DID resolution, and DID-based secure communication and authentication. DIDs allow Sovrin to be used by multiple parties for their own purposes.
Decentralized identifiers and the attendant infrastructure that supports them provide a significant improvement over the ad hoc, email, and domain name based identifiers we've used for identity systems in the past. DIDs represent a universal addressing, abstraction, and verification layer for key pairs, endpoints, and any other information we wish to include in the DID Document. Layer verifiable credential exchange on top of this for multi-source identity and this constitutes a significant upgrade to online identity.
Because there's no central authority controlling DIDs and because people can issue private DIDs themselves, they constitute a truly decentralized means of not only creating identifiers, but using them for mutual authentication, privacy preservation, and secure communication of almost any information parties need to share.
Speaking of DIDs, DID Documents, and Verifiable Credentials in an email to Project VRM mailing list, Joe Andrieu, put it like this:
The win is that these new technologies let us engage in digital society with identifiers we create and control--rather than those gifted or rented to us from a third party. Combined with an open system of verifiable attributes, we can also control the selective disclosure of certain "provable" assertions (provable in the sense that some entity like the DMV stands behind the assertion). Collectively, the identifiers and attributes constitute a full and verifiable identity in the common sense we imagine. For the first time, we can come to the party as a peer of the realm instead of a serf.
An identity metasystem that can provide real peer relationships is critical to protecting individual privacy, creating real security, and, more importantly, supporting human dignity. DIDs are a key part of the architecture.
All of these may be other things as well like addresses or names, but they're still identifiers.
I've modified this DID Document slightly to support the examples I want to make.
In 2005, Microsoft's Chief Identity Architect, Kim Cameron wrote an influential paper called The Laws of Identity (PDF). Kim had been talking about and formulating these laws in 2004 and throughout 2005. It's no coincidence that Internet Identity Workshop got started in 2005. Many people were talking about user-centric identity and developing ideas about how we might be able to create an identity layer for the Internet. Fifteen years later, we're still at it, but getting closer and closer all the time.
The Internet was created without any way to identify the people who used it. The Internet was a network of machines. Consequently, all the identity in Internet protocols is designed to identify machines and services. People used the Internet through some institution (their company or university) and were part of that institution's administrative identity system. This can still be seen in the format of email addresses that identify both recipient and sender as someone@someplace. As the Internet grew to include people who weren't formally associated with an institution, every Web site and service created their own administrative identity domains. The result is the fractured plethora of identifiers, policies, and user experiences that constitute digital identity in 2019.
An Identity Metasystem
In his paper, Kim asks why it's so hard to create an identity layer for the Internet and answers his own question:
Mainly because there is little agreement on what it should be and how it should be run. This lack of agreement arises because digital identity is related to context, and the Internet, while being a single technical framework, is experienced through a thousand kinds of content in at least as many different contexts—all of which flourish on top of that underlying framework. The players involved in any one of these contexts want to control digital identity as it impacts them, in many cases wanting to prevent spillover from their context to any other. (emphasis in original)
Kim's answer is not a new identity system, but rather an identity metasystem. He describes the metasystem:
...different identity systems must exist in a metasystem. It implies we need a simple encapsulating protocol (a way of agreeing on and transporting things). We also need a way to surface information through a unified user experience that allows individuals and organizations to select appropriate identity providers and features as they go about their daily activities. The universal identity metasystem must not be another monolith. It must be polycentric (federation implies this) and also polymorphic (existing in different forms). This will allow the identity ecology to emerge, evolve and self-organize.
Let's look at how Sovrin stacks up as a universal identity metasystem that supports Kim's laws of identity.
1. User Control and Consent
Technical identity systems must only reveal information identifying a user with the user’s consent.
As a self-sovereign, multi-source identity system, Sovrin is architected so that the identity owner is structurally part of exchanging verifiable credentials1. This is enforced by the default to use non-correlatable, decentralized identifiers (DIDs) to establish relationships between identity owners, credential issuers, and credential verifiers. Since there is no universal identifier in Sovrin, the identity owner is the only legitimate point of correlation.
The ledger plays a role in putting the identity owner in control by providing a decentralized means for the credential verifier to obtain the information it needs to validate the legitimacy of the credential. As a result, the system avoids creating a back channel from verifier to issuer that might be used to exchange information about the identity owner without her consent.
The only personally identifying information (PII) available to the credential verifier is the information that the identity owner has consented to provide to the verifier.
Besides the control that credential exchange provides identity owners, people are not locked into a single provider for tools. They can choose from multiple, interoperable tools to use their Sovrin-based credentials. Sovrin is a public network that anyone can use. The network is architected to resist censorship that might deny people the control they need to use their digital credentials however they like.
2. Minimal Disclosure for a Constrained Use
The solution which discloses the least amount of identifying information and best limits its use is the most stable long term solution.
In Sovrin, credentials are issued to identity owners. But identity owners do not share the credential with the verifier. Presenting the entire credential would reveal more information than is necessary. Instead, the identity owner presents a zero-knowledge proof of the information the verifier needs. The ability to limit the information presented from a credential is important to maintaining privacy through the principle of minimal disclosure.
The credential verifier can verify the credential proof by looking at the credential definition on the ledger, retrieving the public DID and associated DID Document of the issuer, and using the public key in the DID Document to check the signature of the credential to ensure it hasn’t been tampered with. The verifier can also cryptographically verify that the credential was issued to the identity owner. As part of making a proof from the credential, the identity owner also proves that it has not been revoked by referencing the revocation registry, which is also available on the ledger.
3. Justifiable Parties
Digital identity systems must be designed so the disclosure of identifying information is limited to parties having a necessary and justifiable place in a given identity relationship.
As a multi-source identity system, Sovrin provides the means for each party in an identity transaction to play their role without the aid or assistance of an intermediary. Consider the following diagram that shows Alice receiving a credential from her employer and proving information about her employment to her bank.
The only parties to the transaction are the three that need to be part of the transaction: Alice, her employer, and her bank. No other person or institution is party to the transaction. The ledger is run by validator nodes and one of more of those nodes might see the reads and writes to the ledger, but these are not correlatable and involve the public identifiers and information that the credential issuer used to create the credential definition.
4. Directed Identity
A universal identity system must support both "omni-directional" identifiers for use by public entities and "unidirectional" identifiers for use by private entities, thus facilitating discovery while preventing unnecessary release of correlation handles.
Sovrin supports both public ("omni-directional" in Kim's terminology) and private ("unidirectional") decentralized identifiers. Public DIDs are written to the ledger and available for anyone to look up. Private DIDs are not written to the ledger, but rather maintained in pairwise relationships between parties in peer-to-peer agents that are under the control of identity owners.
In the preceding diagram, the credential issuer, Alice's employer, has a public DID. A public DID is necessary to issue credentials since the verifier will want to look up the issuer as part of verifying the credential. The bank likely also has a public identifier but it plays no role in this credential exchange. Alice has exchanged private DIDs with both her employer and the bank. These private DIDs form the basis for the cryptographic relationship that Alice has with these institutions. The DIDs that the employer and bank give to Alice are also private, meant just for the relationship with Alice. The employer and bank created private DIDs to represent themselves to Alice, rather than using their public DIDs.
The use of public and private DIDs allows public discovery where necessary (the credential issuer) and prevents the correlation of records that credential issuer and verifier might have about the identity owner, this protecting her PII. The parties in a relationship can use the private DIDs and their associated public keys to mutually authenticate. Private DIDs are GDPR compatible since they are not shared on an immutable ledger.
5. Pluralism of Operators and Technologies
A universal identity system must channel and enable the inter-working of multiple identity technologies run by multiple identity providers.
Sovrin is a multi-source identity system. This means that rather than a single-source provider of identity credentials, as has been the norm for the Internet, anyone can issue any kind of credential for any purpose. Sovrin doesn't give you an identity—it's not an identity provider. Rather Sovrin enables a rich ecosystem of third party credentials, just like in the physical world. These credentials can be mixed together to easily prove things to others.
Credential schemas can be authored by anyone. And anyone can use an existing schema to create a credential definition which combines the schema, issuer DID, and revocation registry ID. This means that credentials are flexible and decentralized. No one is in charge of deciding what credentials are allowed or disallowed. No central party says which credentials are valid and which are not. Instead, each issuer decides what to issue, each identity owner decides which credentials to carry and present, and each verifier decides which credentials to trust.
Credentials are structured using a standard and exchanged using open protocols. Anyone can build software to use these standards and protocols or build them into their own systems. As a result, Sovrin presents an identity metasystem that anyone can use for any purpose and integrate with any tool or identity system they already use.
Beyond credentials, Sovrin's architecture supports independent software agents to hold and process credentials 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.
6. Human Integration
The universal identity metasystem must define the human user to be a component of the distributed system integrated through unambiguous human-machine communication mechanisms offering protection against identity attacks.
As we've seen, the identity owner is a structural part of the identity transactions in Sovrin. Sovrin is architected to make by-passing her very difficult.
Identity owners don't manage keys but manage relationships and credentials, familiar artifacts from the physical world. Key management is handled by the software, below the interface. The identity owner can see, manage, add, delete, select, and share credentials on their device in the same manner they do other digital artifacts like files and folders. Rather than a world of user names and passwords, identity owners work with digital representations of the same things they use for identity transactions in the physical world.
People establish Sovrin relationships within contexts they already understand (e.g. their bank's website or their employer's HR system). They store those relationships in an app that functions like an address book on their phone. The app also stores credentials, another familiar item rendered digitally in the app. Because these artifacts and the act of exchanging credentials is analogous to what people do in their every day lives, the process of doing so with Sovrin is familiar as well.
7. Consistent Experience Across Contexts
The unifying identity metasystem must guarantee its users a simple, consistent experience while enabling separation of contexts through multiple operators and technologies.
The user experience with Sovrin is dictated by the protocol. Regardless of who identity owners are exchanging credentials with or what software they're using, the process is unified and consistent. The user experience is supported by the actors and roles in the protocol and the actions that each can take. Further, the open source code provides reference code for the applications that helps vendors of products that participate in credential exchange to create consistent, interoperable experiences.
At the same time, the unified experience supports multiple credentials from multiple parties who make decisions in a decentralized way. A person can mix verifiable claims from multiple credentials to create an identity transaction that is right for any particular online context. By seeing familiar digital artifacts, selecting, mixing, and sharing them in that context, the identity owner can see exactly what is being requested and make informed choices about what to share without excessive effort.
Sovrin as an Identity Metasystem
Putting all the laws together, we can see that the request, selection, and proffering of identity information must be done such that the channel between the parties is safe. The user experience must also prevent ambiguity in the user‟s consent, and understanding of the parties involved and their proposed uses. These options need to be consistent and clear. Consistency across contexts is required for this to be done in a way that communicates unambiguously with the human system components.
As users, we need to see our various identities as part of an integrated world which none the less respects our need for independent contexts.
Sovrin is architected to meet these needs and provide the kind of unified digital identity experience that Kim envisioned. When I read what Kim wrote almost 15 years ago, I get the feeling that he was a being from the future, telling us things that most of us were not prepared to understand for some time. I know I wasn't. The concepts and ideas that Kim laid out in the Seven Laws and follow-on work (PDF) provide a blueprint for understanding how we can really solve the problem of identity on the Internet.
Sovrin is the identity metasystem that Kim wrote about. I believe that creating and using an identity metasystem with the properties that Kim describes will have far reaching economic and functional impact. More importantly, I think the implications that it has for privacy, security, and human freedom and dignity cannot be overstated. When we look back, I think we'll all be surprised that it took us so long to build. I urge you to join us in making it a reality.
The word credential is used here where Kim used the word "claim." Technically a credential is a collection of claims. The credentials might be the kinds of things we typically think of as a credential, but might also be things that aren't often thought of that way like an airline boarding pass or a prescription for medicine. The world is full of credentials.
I realized last week that I'd never explained verifiable credential exchange as a stand-alone topic—it was always buried in something else.
Multi-source identity (MSI) depends on issuing, exchanging, and verifying digital credentials. The specification for verifiable credentials is being formulated by the World Wide Web Consortium’s Verifiable Credentials Working Group. Verifiable credentials provide a standard way to express credentials in a way that is cryptographically secure, privacy respecting, and automatically verifiable.
Credentials are defined by their issuer in a credential definition. The credential definition links the public decentralized identifier (DID) of the issuer, the schema for the credential, and a revocation registry for the credential. The definition, public DID, schema, and revocation registry are all stored on a distributed ledger that is used for decentralized discovery. (See What Goes on the Ledger (PDF) for more detail on these.)
Credential exchange is the process by which credentials are issued, held, presented, and verified. Credentials are exchanged peer-to-peer by software called "agents." The specific details of how this works technically is defined in Indy agent protocol. Agents create relationships in this peer-to-peer network by exchanging DIDs and their associated public keys.
Here's an example of how credential exchange works. Suppose Alice is applying for a loan at her local bank. The bank requires proof that Alice is employed and makes at least $70,000 per year. Alice has pre-existing relationships with her employer and her bank, meaning her agent is connected to their agents via an exchange of DIDs. Alice’s employer has issued an employment credential that includes her employment status and her current salary. It might also include many other attributes related to Alice’s job. As shown below, Alice holds this credential in her agent. She can present the credential to prove to the bank that she is employed and makes more than $70,000.
When Alice proves her employment status to the bank, she doesn’t present the entire credential since doing so would reveal more information than is necessary. Instead, Alice presents a zero-knowledge proof of just the information the bank needs. The ability to limit the information presented from a credential is important to maintain privacy through the principle of minimal disclosure.
Alice’s bank can verify the credential proof by looking at the credential definition on the ledger, retrieving the public DID and associated DID Document of the issuer, and using the public key in the DID Document to check the signature of the credential to ensure it hasn’t been tampered with. The bank can also cryptographically verify that it was issued to Alice. As part of making her proof from the credential, Alice also proves that it has not been revoked by referencing the revocation registry, which is also available on the ledger.
In multi-source identity, a particular credential is not intrinsically true. Rather each verifier determines who and what they will trust by relying on the attestations of other parties. Thus, truth is established through a preponderance of evidence. How much evidence is needed for a situation depends on the risk, something the verifier determines independently.
For example, in the previous scenario, if the bank does not already know the public DID of the employer, they could validate it in several ways. The most obvious is to interrogate the endpoint in the employers DID Document and ask for proof that they are a legal business and any other information they need to trust the employer. The employer could use credentials they have to prove this to the bank, or they could do it out of band. Once the bank knows to trust the public DID of the employer, this information could be cached according to the policies of the bank.
The trust model for verifiable credentials has five important characteristics that mirror how credentials work in the offline world:
Credentials are decentralized and contextual. There is no central authority for all credentials. Every party can be an issuer, a holder (identity owner), or a verifier. Verifiable credentials can be adapted to any country, any industry, any community, or any set of trust relationships.
Credential issuers decide on what data is contained in their credentials. Anyone can write credential schemas to the ledger. Anyone can create a credential definition based on any of these schemas.
Verifiers make their own trust decisions about which credentials to accept—there's no central authority who determines what credentials are important or which are used for what purpose.
Verifiers do not need to contact issuers to perform verification—that's what the ledger is for. Credential verifiers don't need to have any specific technical, contractual, or commercial relationship with credential issuers.
Credential holders are free to choose which credentials to carry and what information to disclose. People and organizations are in control of the credentials they hold (just as they are with physical credentials) and determine what to share with whom. This is sometimes referred to as self-sovereign identity (SSI).
Multi-source identity is composed of credentials from multiple sources. In addition to her relationship with her employer and bank, Alice likely has a relationship with the state, and holds credentials they issue representing her birth certificate and driver’s license. She might hold credentials from her university representing her transcript. The list of potential credentials that Alice holds is long and depends on her relationships online and offline. She could have hundreds of relationships and associated credentials in her wallet. She can use any of these, in any combination, to prove things about herself (with minimal disclosure) to any other party who accepts them.
Decentralized credential exchange is not new—we've been doing it in the physical world for centuries. But doing it online is novel. Decentralized digital credential exchange gives people and organizations the freedom and autonomy to create authorization regimes that meet their particular needs. Furthermore, credential holders have autonomy and choice in whether to participate. The result is a flexible identity architecture that covers thousands of use cases, even ad hoc use cases, while supporting choice and privacy for identity owners.
Verifiable credential exchange enables online identity transactions that are nearly impossible to imagine using the single-purpose, IdP-based 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, self-sovereign, multi-source identity enables a richer, decentralized ecosystem of identity transactions than can ever be realized with the single-source identity systems we've used to date. Self-sovereign, multi-source identity enables an Internet for Identity.
Evernym, Inc.—Evernym is a commercial software vendor that developed the initial technology for Sovrin and continues to be a large contributor to the open source code that Sovrin is based on.
Hyperledger Indy—Indy is one of the open source code projects in Hyperledger, an open source code effort sponsored by the Linux Foundation.
Sovrin Community—The community is the heart of what makes Sovrin work and comprises identity owners, developers, stewards, businesses, and other organizations, all in multiple roles and with varied interests.
The preceding diagram shows the relationships between these and other organizations:
Sovrin Foundation is the sponsor of the Hyperledger Indy open source project. The Sovrin Network runs code from Indy.
Evernym and other organizations build products that run on the Sovrin Network. For example, Evernym is building the Connect.me wallet for use with Sovrin and a commercial enterprise-grade verifiable credentialing system called Verity. The Government of British Columbia is building software to use Sovrin credentials for business licensing. These commercial organizations also provide services, like agencies, to the Sovrin community. Developers at these organizations contribute code to Hyperledger Indy.
Hyperledger Indy houses the open source code for the Sovrin Network and provides collaboration services for Sovrin, Evernym, and others working on Indy code. Indy relies on volunteer contributions from the Sovrin Community.
Sovrin Community supports and is supported by the Foundation, contributes to Indy, and provides services to or uses services from the various software vendors and agencies.
Even though Sovrin is only a few years old, this ecosystem is making great progress toward making self-sovereign identity a reality. Here are a few accomplishments from just the last year:
The Sovrin network now boasts stewards on every continent except Antarctica. There are over 60 stewards representing organizations large and small from around the world.
The Sovrin network is running code contributed by over 150 developers who made over 20K contributions just in the last 12 months.
The Sovrin Governance Framework has undergone a major overhaul and represents the very best thinking from contributors around the globe in how a self-sovereign identity network should be governed.
Dozens of organizations from around the world are conducting pilots or proofs of concept to explore how Sovrin can help them better serve and connect to their customers.
All of this adds up to an extraordinary, vital ecosystem dedicated to promoting self-sovereign identity, defining the processes, protocols, and specifications to make it happen, and building a network that makes it a reality.
Decentralized architectures require that care is taken in each component or layer to ensure that the resulting system will not contain hidden weaknesses. That doesn't just apply to the system itself, but also to the ways it is governed. And all decentralized systems are governed. The governing might be ad hoc or hidden, but it's there.
I've written a lot about distributed ledgers, Sovrin, governance, and decentralization over the past several years. Here's a partial list:
You can see this topic has been on my mind. The remainder of this post is going to focus on the decentralized nature of the Sovrin Network.
As a hybrid system, the Sovrin Network benefits both from having a blockchain-based ledger and from having formal governance. Both of these are important for Sovrin to thrive and meet its objectives. And, contrary to what you might think, governance helps in achieving a public, decentralized system that has real utility.
The Sovrin Network
Our goal is for the Sovrin Network to be an open, public, decentralized utility for digital identity. Those three adjectives deserve some explanation:
open—The Sovrin network is based on the open-source Hyperledger Indy project. That is important, but it's not sufficient. The governance of the Sovrin Network should also be open. This extends to decisions about the code, who runs it, and the features that it enables.
public—Anyone should be able to access and use Sovrin for any purpose that it supports. Public access is a foundational element for self-sovereignty because it avoids gatekeepers that might censor some transactions. This applies not only to reading information from the ledger, but also authoring ledger transactons.
decentralized—no single entity should represent a single point of failure. This doesn't just apply to the availability of the network, but also the ability of people to use the network.
The Sovrin protocol is layered as shown in the following diagram.
Each of these layers builds upon the one below. Consequently, it's important that each layer have appropriate support for decentralized operation to ensure that the network supports self-sovereignty.
The Ledger Layer
The Sovrin Network is based on a distributed ledger. The ledger is a small, but critical, part of Sovrin's overall functionality. Every identity system needs a way to discover what identifiers mean—if you get an identifier, you want to look it up. For identity systems, that has traditionally been implemented as a centralized database controlled by a single entity. For Sovrin to be decentralized, it must have a decentralized means of discovery. The Sovrin ledger provides that.
Sovrin's ledger is a hybrid combining known validator nodes with public access. Because of this architecture, Sovrin is difficult to categorize in the various discussions of permissioned and permissionless blockchain systems. One common refrain is "blockchains don't need trust (governance) frameworks." Another goes "the point of blockchain is to avoid governance." Those might be true in some architectures, but they don't apply to Sovrin, as I'll discuss below.
Sovrin never stores personally identifying information, encrypted or not, on the ledger, unlike many other blockchain-based identity systems. Rather Sovrin uses the ledger for Decentralized Identifiers (DIDs), schema definitions, credential definitions, and revocation registries. Without a ledger to store these, Sovrin would have a single point of failure for these critical objects. For more information, see What Goes on the Ledger (PDF).
Objects like a DIDs are written to the ledger by transaction authors and validated by transaction validators. These functions are separate. Because the Sovrin Network is public, anyone can be a transaction author. But only organizations who function as Sovrin Stewards can validate transactions. Validation is done using a modified Redundant Byzantine Fault Tolerance algorithm implemented as Indy Plenum.
If the ledger is the basis for decentralized discovery in Sovrin, then we should ensure that no single organization controls the ledger and that it is protected from being taken down or corrupted by a single or even a few entities. Sovrin is designed to be censorship resistant. No company or special interest can control who can use the protocol. Sovrin is available for any application or purpose. And the priority of transaction validation is fair. Public authorship of Sovrin transactions on a ledger represents the best means available to combating censorship.
Validation on the Sovrin ledger is based on a known set of nodes run by the Stewards. This architecture was chosen to reduce the resource usage (and hence, cost) of the ledger. We have designed the ledger and its governance to ensure that the ledger is public, open, and decentralized despite the presence of known validators.
One key idea in decentralized systems is that different parts of the system are under the control of different organizations. Censorship resistance requires that even though Stewards must meet certain requirements to participate, we must still assume that any node might be hostile because of a hack or other circumstances beyond the control of the Steward. A distributed ledger provides this important property and is, consequently, the right data structure for this.
In addition, using a blockchain ensures that multiple organizations are responsible for a shared space for discovery. Losing one or even several Stewards would not impact the ability of people to manage and use their identifiers on Sovrin. One of Sovrin's guiding principles is diversity of validators to protect this vital function.
Some might be concerned that Sovrin Foundation itself holds a special place and thus represents a single point of failure. While it's true that the Foundation administers the governance framework and manages the open source project, the Foundation does not run the Sovrin Network. Consequently, it could cease to exist and the network would continue operating. In the case of the ledger itself, the Stewards would keep operating the Network and re-organize. The open source project would continue, as open source projects do, because the code is available to and maintained by people rather than a specific organization.
Because transaction authoring is a public function, the use of a ledger also ensures that people can access, write, and update identifiers without being subject to gatekeepers. Even if those gatekeepers are friendly, they might restrict access to certain people, certain groups, or certain jurisdictions due to a hack or other circumstances beyond the control of the gatekeeper.
The Agent Layer
Agents are a core element of the Sovrin architecture. Since Sovrin does not store personally identifying information on the ledger, people need a place to hold, manage, and use keys and credentials. Agents fill that role. Sovrin's architecture supports both cloud and device agents. Most people will have more than one. Sovrin identity owners usually have at least two agents, one on a device and one in the cloud The device agent is connected to an app and contains a wallet for storing keys and credentials.
Sovrin agents operate independently from each other in a peer-to-peer (heterarchical) topology. Agents communicate with each other for DID and credential exchange without an intermediary. Neither do they need the ledger to communicate. Communication between agents is done via signed and encrypted messages. The two agents in a peer relationship authenticate each other using the keys they exchanged when they established a relationship. Each agent has its own keys and keys are never copied between agents.
Clearly device agents and wallets are not centralized because they store their keys and credentials on the device. The cloud agent can be run by a service provider called an agency or self-hosted. Most people will opt to use an agency. There can be multiple agencies and agent operation is standardized so that users can switch agencies.
Further, the agency does not have access to what's in the agent. There are no master keys. So, barring a code problem that opens a security hole, there's no honey pot. We believe agent code should be open source to reduce security risk by getting as many eyes on the problem as possible.
The peer-to-peer architecture of agents and their availability from multiple agencies creates a decentralized system for storing, managing, and using keys and credentials. This not only is a boon to identity owner privacy and autonomy, it also ensures that Sovrin can scale to trillions of relationships.
The Credential Exchange Layer
The top layer in Sovrin is where credential exchange happens. Credential exchange is central to how Sovrin works. Sovrin does not have "identity providers" because anyone can be the source of their own identity. Your digital identity is made from credentials from multiple sources. I call this multi-source identity. You might have a Sovrin-based relationship1 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.
Credential exchange is done peer to peer via agents. Agents use the ledger in various ways in credential exchange. Issuers use it to write public DIDs, credential definitions, schema, and revocation registries. Credentials holders use the ledger to prove a credential they're presenting hasn't been revoked, among other things. Verifiers use the ledger to check the public DIDs of the credential issuer and look up schema and credential definitions. Because of the ledger, credential issuers don't see when a verifier verifies a credential, a further boon to identity owner privacy.
Sovrin's trust model for verifiable claims has five important and desirable properties that all underscore its support for decentralization and personal autonomy:
Credentials are decentralized and contextual. There is no central authority for all credentials. 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 credentials, or any set of trust relationships.
Credential issuers decide on what data is contained in their credentials. Sovrin allows anyone to write credential schemas to the ledger. Anyone can create a credential definition based on any of these schemas.
Verifiers make their own trust decisions about which credentials to accept—there's no central authority who determines what credentials are important or which are used for what purpose.
Verifiers do not need to contact issuers to perform verification—that's what the ledger is for. Credential verifiers (the people or organizations relying on a credential) don't need to have any technical, contractual, or commercial relationship with credential issuers (the people or organizations making the credential).
Credential holders are free to choose which credentials to carry and what information to disclose. People and organizations are in control of the credentials they hold (just as they are with physical credentials) and determine what to share with whom.
Decentralized credential exchange is not new—we've been doing it in the physical world for centuries. But it is new online. Decentralized credential exchange gives people and organizations the freedom and autonomy to create authorization regimes that meet their particular needs. Furthermore, credential holders have autonomy and choice in whether to participate. The result is a flexible system that covers thousands of use cases while supporting choice and privacy for identity owners.
The lack of a decentralized, heterarchical, and interoperable identity system has led to an environment where the services most people use online are a lot more centralized than the Internet they exist upon. Sovrin corrects this by providing the means for people to exercise greater autonomy and freedom. Decentralized identity is the key to creating a more decentralized Web—a Web that flexibly supports the kind of ad hoc interactions people have with each other all the time in real life.
Without peer-based interactions and public access, Sovrin would not be self-sovereign. By supporting control of identity information by people, Sovrin creates a self-sovereign identity environment. Self-sovereignty requires that the parties to the credential transaction behave as peers. In traditional identity systems the rights of the so-called "identity subject" are subordinate to those of the identity provider. In Sovrin, every player independently determines the role they'll play, who they trust, and what they will believe.
When I say "relationship" that means that both sides have an agent and have exchanged DIDs to create a pairwise pseudonymous relationship.
The world is full of credentials. Some, like a driving license, an employee ID card, a passport, or a university diploma are widely recognized as such. But many other things are also credentials: a store receipt, a boarding pass, or a credit score, for example. Credentials, designed properly, allow verifiable data to be employed in workflows without centralized hubs, point-to-point integrations, or real-time communication between the various players. Credentials enable decentralized, asynchronous workflows.
Multi-source identity (MSI) allows multiple credentials from multiple providers to be brought to bear, flexibly and conveniently, in a situation where trusted attestations are needed for the participants in a workflow to make progress. In MSI, there are three players: credential issuers, credential holders, and credential verifiers. Any person or organization can play any or all of the roles.
Credential issuers determine what credentials to issue, what the credential means, and how they'll validate the information they put in the credential.
Credential holders determine what credentials they need and which they'll employ in workflows to prove things about themselves.
Credential verifiers determine what credentials to accept and who to trust.
Because of these features, MSI is decentralized. In contrast, traditional identity systems have a single identity provider (IdP) who administers an identity system for their own purposes, determines what attributes are important, and decides which partners can participate.
Self-sovereign identity means the individual or organization controls and manages their identity. Multi-source identity becomes self-sovereign identity (SSI) when the individual is able to control the credentials and use them in a privacy-preserving manner whenever and where ever they want. Privacy is a critical feature of SSI because without privacy, there is no control. In SSI, the identity owner must be able to control who sees what and that means that privacy is a fundamental property of the architecture for SSI.
SSI also implies that the parties to the credential transaction behave as peers. In traditional identity systems the rights of the so-called "identity subject" are subordinate to those of the identity provider. In SSI, every player independently determines the role they'll play, who they trust, and what they will believe. As we've seen, in SSI, an identity owner holds credentials from multiple providers and can use them where ever she wants. While these credentials can be revoked individually, the identity owner still controls her own identity wallet and all the other credentials she has collected.
Self-sovereign identity represents a monumental shift in how identity functions on the Internet. Internet identity systems have traditionally only supported a limited set of attributes and required prior agreement and custom integration. SSI frees Internet identity from this narrow view by introducing support for the exchange of credentials by individuals and organizations acting as peers. The result will be an Internet identity regime that is more flexible, more secure, more private, less burdensome, and less costly.
Recently Joe Andrieu gave a presentation about the role of multiple assertions in a real-life situation—an automobile accident. As I listened, I thought it was an excellent example because it showed clearly the power of being able to bring multiple, independent credentials to bear in a situation that is complex and involves a number of parties.
Hopefully, you've never been in an automobile accident, but if you have you recognize that there are a number of credentials that play a role in a scenario that plays out over days or even weeks. The following diagram shows some of the credentials that would be used in the initial investigation following the accident.
In this scenario, two drivers, Alice and Bob, have had an accident. Fortunately, no one was hurt, but the highway patrol has come to the scene to make an accident report. Both Alice and Bob have a number of credentials in their digital wallets that they control that will be important in creating the report:
Proof of insurance issued by their respective insurance companies
Vehicle origination document issued by their vehicle's manufacturer
Vehicle registration issued by the Department of Motor Vehicles (DMV)
Driver's license issued by the Department of Public Safety (DPS) in Alice's case and the DMV in Bob's
In addition, the police officer has a badge from the Highway Patrol. Alice and Bob would make and sign statements. The police officer would create an accident report.
Typically each of these documents are paper, or at best PDFs, and they are exchanged, copied, and filed away. The thought of doing it all digitally conjures visions of complex, special-purpose software systems with uneven acceptance by the various players and jurisdictions.
Sovrin changes that by providing an open, decentralized system that supports the flexible exchange of standards-based verifiable credentials. Each of the credentials mentioned previously can be independently created by the appropriate issuer, held by Alice, Bob, and the Police Officer, and presented to any party who the holder desires. Alice would control her credentials and Bob his.
After the accident, Alice and Bob would use the Sovrin wallets on their phones to create a relationship. When the officer arrives on the scene, they will both also create a relationship with him. They can use these relationships to exchange information based on the credentials they each hold. Alice and Bob create statements about what happened. The Police Officer creates an accident report. These are also credentials that can be shared between the parties.
Later, Alice and Bob will share the accident report and information about the other driver with their respective inurance comopanies. The may enlist the services of mechanics and auto-body shops who will need to get information from the accident report and provide attestable statements about repair quotes and completion of repairs to the insurance companies.
The decentralized nature of the Sovrin Network allows all this information to be exchanged regardless of the fact that Alice and Bob are from different states that have different government organizations and structure. The exchange works regardless of the fact that Alice and Bob use different insurance companies. The exchange works regardless of whether they're in or out of their own state.
Because of the structure of Sovrin, the receiver of each credential can verify it hasn't been altered, that it is about the party who presented it, and was issued by a particular party. Standards ensure that each party can can issue their own credential and that others can understand it. Standards allow the exchange to happen without appeal to special-purpose software systems. Rather than building a special purpose "vehicle accident reporting system" and convincing all the players to participate in a closed ecosystem, the standards that enable self-sovereign identity allow each participant to work through an ad hoc scenario with finesse and sophistication.
This scenario gets even more interesting if the cars are connected and have an identity of their own. There may be data from the connected car that is relevant to the accident. For example, an accelerometer could have measured be data points before and during the accident that might be included in either Alice or Bob's statements or the Police Officer's accident report. In a Sovrin world, the vehicles can have agents and consume, hold, or generate verifiable credentials. But the vehicles' identity is owned and controlled by their owner (who might not be the driver involved in the accident). This adds a new dimension to the data that would be shared, but Sovrin's flexible structure makes it easy to include these new players in the scenario.
Real life is complicated and messy. The only hope we have of enabling digital interactions that mirrors activities in the physical world is with decentralized systems that allow each person, organization, or thing to act independently and autonomously. While multi-source identity can't repair you car for you, an open system that supports it like Sovrin can significantly reduce the friction in handling the many credential and data exchanges that follow any accident.
The Sovrin Network is a global public utility for identity that we all own, collectively, just like we all own the Internet.
When I say Sovrin is "public," I mean that it is a public good that anyone can use so long as they adhere to the proper protocols, just like the Internet. Sovrin is created through the cooperation of many people and organizations. Enabling that cooperation requires more than luck. In Coherence and Decentralized Systems, I wrote:
Public spaces require coherence. Coherence in Sovrin springs from the ledger, the protocols, the trust framework, standards, and market incentives.
In that post, I describe how these components combine to create the coherence necessary for Sovrin to thrive. The Sovrin Foundation is the organization we’ve created to accomplish the work necessary to bootstrap the components necessary for coherence and launch a global public utility.
The Vision and Mission of the Sovrin Foundation
The vision for the Sovrin Foundation is “Identity for All”. Thus its mission is to enable access to permanent digital identity for all—both people and organizations—by building, administering, and promoting a decentralized, public, global identity utility. This new type of digital identity, which I call a multi-source identity, is owned and controlled by the individual or organization, and is not accountable to or administered by any particular agency or other intermediary. No one can take away your digital identity on Sovrin.
In order to achieve that mission, the Foundation has several important objectives:
Ensure everyone, regardless of circumstance, has access to the Sovrin Network and the utility it entails.
Protect individual privacy and freedom by promoting digital identity infrastructure not beholden to any government, entity, or agency, and without regard to nationality, citizenship, or any other discriminating factor.
Support the infrastructure of Sovrin by administering the Sovrin Trust Framework, recruiting and assisting Sovrin Stewards in operating the network, and leading the open-source community effort that develops and builds the Sovrin protocol and the code that embodies it.
Lead thought and action in the advancement and acceptance of self-sovereign identity and the network on which it is built.
To achieve these objectives, the Sovrin Foundation is organized as a non-profit led by a diverse, volunteer Board of Trustees who represent identity owners worldwide. Sovrin is not a membership organization or an industry association, two common forms of non-profit. Rather it is a social welfare organization. We chose that model because it most closely fits with the Foundation’s mission.
Presently, funding for the Sovrin Foundation comes from donations. Ultimately, our goal is that the Foundation be self-sustaining through minimal fees on network transactions.
The Foundation is governed by three complimentary agreements:
The Sovrin Foundation is organized to achieve the objectives outlined above. Like any other organization, the exact structure evolves based on needs and resources, but it generally comprises four kinds of bodies:
Foundation governance bodies that are formally defined in the Bylaws, Board-approved charters, and Trust Framework.
Working groups comprised of volunteers who come together to solve specific problems. Some working groups are long-lived and others exist only for a specific period of time.
Communities formed by specific roles defined by the Sovrin Trust Framework.
The Sovrin Alliance, a set of people and organizations who have signed up with the Foundation to explicitly offer support for Sovrin.
Overall, we strive for diversity in participation and a balance of power that all voices are heard in support of the principles of Sovrin, particularly the principle of diffuse trust.
Foundation Governance Bodies
Board of Trustees—The Trustees are the approving body for decisions about the Foundation. As the Sovrin Foundation bootstraps itself, the board is self organizing (per the bylaws) but will eventually be chosen through a vote of people aligned with Sovrin’s purposes. The exact process is yet to be determined.
Technical Governance Board—The Technical Governance Board (TGB) is responsible for governing the technical design, architecture, implementation, and operation of the Sovrin Network as a global public utility for self-sovereign identity. The TGB charter has more details on how they accomplish this mission. One of the key tasks of the TGB is to review the technical qualifications of Steward candidates to ensure they meet the requirements and principles in the Sovrin Trust Framework.
Economic Advisory Council—The Economic Advisory Council advises the Board of Trustees on the financial sustainability of Sovrin Network, and specifically on the design and governance of the Sovrin token ecosystem.
Identity for All (I4A) Council—The I4A Council supports the Sovrin Foundation’s mission of inclusive identity by working to extend the benefits of Sovrin to those populations who need an independent digital identity, but who are unlikely to be provided one via a commercial relationship. This includes the estimated 1.1 billion people worldwide—mostly in the Global South—who currently lack a state-based or other widely-recognized identity credential.
Executive Committee—The Executive Committee is empowered by the Board of Trustees to review issues and make preliminary decisions for the board to consider. The Executive Committee functions as a steering committee that can make quick decisions when having the entire board meet would be impractical.
Steward Qualification Committee—The Steward Qualification Committee (SQC) is responsible for reviewing steward applications to ensure that potential stewards are qualified in accordance with the requirements and principles laid out in the Sovrin Trust Framework. They make their recommendations to the Board of Trustees.
Audit and Finance Committee—The Audit and Finance Committee is a subunit of the Board of Trustees that performs critical functions in ensuring the integrity of the financial reporting process, oversees the process for identifying and addressing financial and related risks, and ensure the Foundation has appropriate policies and programs to prevent and detect fraud.
Trust Framework Working Group—The Trust Framework Working Group is a group of volunteers who work along with Sovrin Foundation staff to develop the Sovrin Trust Framework. Currently the largest working group, it consists of four subteams that meet regularly to evolve the set of documents that set forth the purpose, principles, and policies (business, legal, and technical) that serve as the “constitution” of the Sovrin Network.
Agent Working Group—The Agent Working Group is organized in the Hyperledger Indy Project and comprises a group of volunteers who work along with Sovrin Foundation staff to develop the agent protocol and the code necessary to support it. The Agent WG meets regularly and is open to anyone who is interested in helping define the peer-to-peer agents who form the heart of Sovrin Network’s transactional capability.
Other working groups are created from time-to-time as necessary to help define and design Sovrin Network functionality. These working groups may be part of the Sovrin Foundation or part of the Hyperledger Indy project depending on their nature.
Communities Defined by the Sovrin Trust Framework
The Sovrin Trust Framework defines the following specific roles that an individual or organization may play in the Sovrin ecosystem. These roles give rise to communities or constituencies that work with and influence Sovrin and the Foundation. Note that in many cases an individual or organization may play more than one role.
Identity Owners—Every person or organization who uses Sovrin is an identity owner. As a social welfare organization, the Foundation is responsible for upholding the principles of the Trust Framework on behalf of identity owners and ensuring that they have access to the Network for any legitimate use. The Sovrin Trust Framework says identity owners may be held legally accountable for their actions, so identity owners can’t be animals or inanimate objects.
Stewards—The Sovrin ledger is operated by Stewards, trusted organizations within the ecosystem who have agreed to abide by the requirements in the Sovrin Trust Framework and are responsible for operation the nodes that maintain the Sovrin distributed ledger. Stewards also, as a group, accept or reject any changes to the ledger-specific portions of the Sovrin open source code by virtue of that role. They thus provide a counterbalance to the Sovrin architects who maintain the Indy code base.
Trust Anchors—Trust Anchors are identity owners who serve as a starting point in the Sovrin Web of Trust. In the Sovrin Web of Trust Model, there are two types of trust anchors:
Sovrin Trust Anchors are invited by the Sovrin Foundation or by a Steward. They protect access to the Sovrin Public Ledger for everyone in the Sovrin community. A Sovrin Trust Anchor can invite new Identity Owners to the Sovrin Network.
A Sovrin Trust Anchor must meet the Trust Anchor Qualifications and agree to the Trust Anchor Obligations defined in the Sovrin Trust Framework. All Stewards are automatically Sovrin Trust Anchors.
Agencies—Agencies are service providers (commercial, governmental, non-profit, or self-hosted) who host Sovrin cloud agents on behalf of Identity Owners.
Developers—Since the Sovrin Network relies on several open-source code bases, developers are a particularly important community in the Sovrin ecosystem, as I wrote in Decentralized Governance in Sovrin:
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.
The Sovrin Alliance is an association of people and organizations who are willing to state publicly that they agree with the principles enumerated in the Sovrin Trust Framework. The Alliance is still in the formative stages, but we anticipate that it will have an important role to play in the long term governance of Sovrin.
Alliance Members—Alliance members join because they believe in the principles enumerated in the Trust Framework and are willing to publicly commit to them and support of Sovrin.
Sovrin Alliance Advisory Council—The Sovrin Advisory Council is a group of people and organizations in the Sovrin Alliance who have an interest in Sovrin and are willing to lend their expertise to help the Foundation.
Decentralization and Governance in Sovrin
Sovrin is sometimes accused of being “centralized” because people see the Foundation as a controlling force that might promote collusion. But Sovrin’s governance isn’t in conflict with decentralization; but rather supports it—what we call “Decentralization by Design”. The Trust Framework makes the principles that are important to Sovrin explicit and the open process allows anyone to determine whether or not they’re being followed. This provides accountability that resists collusion.
The Sovrin Network is governed by a collection of organizations and people who make independent decisions based on the principles in the Sovrin Trust Framework. Some of them write code, some operate validator nodes, some develop policy, and many others make decisions about how they’ll use Sovrin. But all of these people work together through the network to achieve something they can’t do alone: self-sovereign identity. Both the Trust Framework and the Indy code run by all Sovrin Stewards are developed using open, public processes that are carefully designed to reflect these activities.
Participation in Sovrin is open to all. Sovrin does not have "identity providers" because they are entirely unnecessary; identity owners are empowered to create their own identifiers and obtain (or self-issue) and carry their own credentials. No one can remove a person from Sovrin or close their account--there isn’t any account to close.
In place of accounts, Sovrin’s design for multi-source identity provides people with choice and flexibility in using their online identity. No one determines which credentials are supported and which aren’t. No one says which credentials must be issued, presented or accepted. Everyone using Sovrin makes these decisions on their own.
In short, 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. The public and open nature of Sovrin supports an unprecedented level of autonomy, privacy, security, and control by the people and organizations using Sovrin.
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.
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.