The Sovrin Ecosystem

People often ask me how Sovrin relates to Evernym or Hyperledger Indy. It can be confusing, so I created a diagram that seems to help. First a few definitions:

  • Sovrin Foundation—The Sovrin Foundation is an international non-profit organization supporting self-sovereign identity through a global, decentralized network. I've discussed the Foundation, it's mission, and organization at some length in a previous blog post.
  • 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.
Relationship between Sovrin Foundation, Evernym, and Hyperledger
Relationship between Sovrin Foundation, the Sovrin community, Hyperledger Indy, software vendors, and service providers. (click to enlarge)

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.


Decentralization in Sovrin

Queen and Attendents

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.

The Three Layers of the Sovrin Network
The Three Layers of the Sovrin Network (click to enlarge)

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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).
  5. 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.

Decentralized, Self-Sovereign Identity

The architecture of Sovrin, at all three levels of operation, creates a decentralized identity system that has the same decentralized properties as the Internet:

  • No one owns it
  • Everyone can use it
  • Anyone can improve it

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.


Notes

  1. When I say "relationship" that means that both sides have an agent and have exchanged DIDs to create a pairwise pseudonymous relationship.

Photo Credit: Bees in a bee hive from USDA (CC BY 2.0)


Multi-Source and Self-Sovereign Identity

A Wallet Holding Credentials

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.

The Issuer/Holder/Verifier Trust Triangle
The Issuer/Holder/Verifier Trust Triangle

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.

In MSI, a particular credential is not intrinsicly 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.

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.


Photo Credit: A picture of a wallet from TheArmadillo (CC BY-SA 3.0)


You've Had an Automobile Accident: Multi-Source Identity to the Rescue

Car crash scene with police nobody hurt

Earlier I wrote about the idea of multi-source identity that allows multiple authorities to make assertions about people, organizations, and things that can be verified. Multi-source identity becomes self-sovereign identity when the individual is able to control those assertions and use them in a privacy-preserving manner whenever and where ever they want.

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.

Credential Uses in a Car Accident
Credential Uses in a Car Accident (click to enlarge)

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.


Photo Credit: Car crash scene cleanup effort, with police present from Tomwsulcer (CC0 1.0)


The Sovrin Foundation

Freifunk Mesh

In Decentralized Governance in Sovrin, I wrote:

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:

Organization of the Sovrin Foundation

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:

  1. Foundation governance bodies that are formally defined in the Bylaws, Board-approved charters, and Trust Framework.
  2. 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.
  3. Communities formed by specific roles defined by the Sovrin Trust Framework.
  4. 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.

Working Groups

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.
  • Domain Trust Anchors are appointed under a domain-specific trust framework, such as the credit unions that operate under CULedger's MyCUID Trust Framework.

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.

Sovrin Alliance

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.


Image Credit: Freifunk Mesh from SimonKurka (CC BY-SA 4.0)


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)