In We've stopped trusting institutions and started trusting strangers, Rachel Botsman talks about the "trust gap" that separates a place of certainty from something that is unknown. Some force has to help us "make the leap" from certainty to uncertainty and that force is trust.

Traditionally, we've relied on local trust that is based on knowing someone—acquired knowledge or reputation. In a village, I know the participants and can rely on personal knowledge to determine who to trust. As society got larger, we began to rely on institutions to broker trust. Banks, for example, provide institutional trust by brokering transactions—we rely on the bank to transfer trust. I don't need to know you to take your credit card.

But lately, as Botsman says, "we've learned that institutional trust isn't meant for the digital age." In the digital age, we have to learn to how to trust strangers. Botsman discusses sharing platforms like AirBnB and BlaBlaCar. You might argue that they're just another kind of institution. But there's a key difference: those platforms are bidirectional For example AirBnB lets guests rate their hosts, but also lets hosts rate guests. These platforms give more information about the individual in order to establish trust.

But beyond platforms like AirBnB lies distributed trust based on blockchains and distributed ledgers. Botsman makes the point that distributed trust provides a system wherein you don't have to trust the individual, only the idea (e.g. distributed cash transactions) and the platform (e.g. Bitcoin). You can do this when the system itself make its difficult for the person to misrepresent themselves or their actions. When I send you Bitcoin, you don't have to trust me because the system provides provenance of the transaction and ensures that it happens correctly. I simply can't cheat.

At a fundamental level, trust leads us to believe what people say. Online this is difficult because identifiers lacks the surrounding trustworthy context necessary provide the clues we need to establish trust. Dick Hardt said this back in 2007. The best way to create context around an identifier is to bind it to other information in a trustworthy way. Keybase does this, for example, to create context for a public key. Keybase creates a verifiable context for a public key by allowing its owner to cryptographically prove she is also in control of certain domain names, Twitter accounts, and Github accounts, among others. Keybase binds those proofs—the context—to the key. Potential users of the public key can validate for themselves the cryptographic proofs and decide whether or not to trust that the public key belongs to the person they wish to communicate with.

Another key idea in reputation and trust is reciprocity. Accountability and a means of recourse when something goes wrong create an environment where trust can thrive. This is one of the secrets to sharing economy platforms like AirBnB. Botsman makes the point that she never leaves the towel on the floor of an AirBnB because the host "knows" her. She is accountable and there is the possibility for recourse (a bad guest rating).

Trust Frameworks and Trust Transactions

The phrase we use to describe the platforms of AirBnB, BlaBlaCar, and other sharing economy companies is trust framework. Simply put, a trust framework provides the structure necessary to leap between the known and unknown.

For example, social login presents a trust leap for the Web sites relying on the social media site that's authenticating the user. When a user logs into a Web site using Facebook, trust is transferred between Facebook and the site they're logging into. Facebook establishes that the user is the same person who created the account based on the fact that she knows things like the username and password. The relying Web site trusts that Facebook will do a good job of this and thus is willing to accept Facebook's authentication in lieu of its own. This transfer of trust from Facebook is a trust transaction.

Trust frameworks generally rely on technologies, business processes, and legal agreements. All of these are important. For example, how much recourse a relying party has against Facebook is unclear, so social login has been limited to identity providers who relying parties trust. I could become an identity provider, but few Web sites will add me to their login process because they can't trust me.

Trust frameworks are all around us, but they are one-offs, too specialized to be universally applicable. In the case of AirBnB, the platform can only be used by AirBnB for trust transactions between hosts and guests. In the case of social login, the framework is open and non-proprietary, but limited to authentication transactions. Furthermore, only a few identity providers are trusted due to insufficient business process and legal structures.

Sovrin as a Universal Trust Framework

All of which brings me to Sovrin. If you've been following my blog, you probably get that Sovrin is a decentralized identity system based on a distributed ledger. But Sovrin's killer feature is verifiable claims¹. The combination of decentralized identifiers (DIDs), verifiable claims, and a ledger that is available to all make Sovrin a universal trust framework.

Let's unpack these to see why they're all necessary:

• Decentralized Identifiers—DIDs allow anyone to create identifiers for anything. Furthermore, they are in a standard, interoperable format. People will have hundreds or thousands of DIDs representing all of the various digital relationships to which they're a party. These relationships might be with organizations they do business with, friends they interact with, or things they own. Organizations and many people will have public DIDs that represent their public digital presence. For example, I might have a DID that represents me to my employer, BYU, and another that represents me to my bank.

• Verifiable claims—verifiable claims allow trustworthy assertions to be made about anything that has an identifier. These claims are standard and interoperable. Furthermore, they're based on strong cryptography to bind the claim issuer, the claim subject, and the claim itself. For example, BYU might issue a claim that says I'm an employee. My bank might issue a claim saying I have an account balance of $X. Issuing a claim is a trust transaction that is recorded on the ledger.

• Sovrin ledger—the ledger provides the means of discovering the keys and endpoints associated with a particular DID. The ledger also records information about claims (although not the claims themselves). Consequently, Sovrin creates provenance about trust transactions and their constituent parts. For example, the claim that BYU makes that I'm an employee would reference BYU's public DID, the DID by which BYU knows me, a claim schema (for employees), and the assertions BYU is making within that schema. These would be packaged up and cryptographically signed. I'd hold the claim, but it's existence would be recorded on the ledger, as would the DIDs it references and the claim schema.

  When I need to prove to the bank that I'm employed by BYU, I don't give them the claim. Instead I generate a proof—an incontrovertable certification of some fact—from the claim. The proof discloses only the information the bank needs. Further, the proof uses the DID that represents the relationship I have with the bank, not the one I have with BYU (since the bank doesn't know about that one). All this is done cryptographically² so that no party to the transaction has any doubt whether or not the information is correct.

Properties of a Universal Trust Framework

DIDs, verifiable claims, and the Sovrin ledger give our trust framework several important properties.

First, Sovrin scales in applicability as well as raw transaction power. The use of a decentralized ledger and standards like decentralized identifiers and verifiable claims mean that anyone can make use of Sovrin for any kind of trust transaction. As I've discussed in detail before, Sovrin shares important virtues with the Internet: No one owns it, everyone can use it, and anyone can improve it. The use of a permissioned decentralized ledger allows Sovrin to scale to meet the needs of a global trust network with billions of users.

Second, Sovrin is general purpose. Where other platforms like AirBnB or BlaBlaCar are aimed at a specific problem, Sovrin can be used for any type of trust transaction. This means that you can use it for whatever is important to you. Sovrin is a tool that anyone can use to fill the trust gap. In this way it's more like the Internet or a programming language.

Third, Sovrin provides accessible provenance for trust transactions. Provenance is the foundation of accountability through recourse. In my previous example, my bank can look up the claim that is the basis of the proof, the claim schema, the DID BYU uses in the claim about my employment on the ledger, and the DID I use with them. They can cryptographically check that these are all correct. Further, they can determine whether to trust BYU based on the public claims recorded about its DID. Sovrin provides irrefutable evidence of trust transactions. If BYU's claim about my employment is wrong, my bank can track that down, and BYU knows this. This possibility encourages good behavior by all parties to the trust transaction.

Universal solutions solve previously intractable problems and make new applications more broadly available. A trust framework with the three properties listed above changes how we conduct business online. The Internet changed the world because it provided a universal means of communicating. Sovrin changes the world by providing a universal means of trusting. Sovrin can be used by anyone to solve their online trust problems. I've outlined a number of use cases for Sovrin, but these only scratch the surface because the world is full of use cases that share the problem Rachel Botsman describes—filling the trust gap so people can move from the known to the unknown.

Photo Credit: Lorimerlite Framework from Astris1 (CC BY-SA 3.0)

This post originate in and was made better through discussions with Craig Burton and Steve Fulling.

Notes:

1. In identity circles, a claim is an assertion about a digital subject that is open to doubt. Thus a verifiable claim is an assertion that can be validated by the recipient.
2. Technically, this is a zero knowledge proof.