The Web of Trust model for Sovrin is still being developed, but differs markedly from the trust model used by the Web.

The Web (specifically TLS/SSL) depends on a hierarchical certificate authority model called the Public Key Infrastructure (PKI) to determine which certificates can be trusted. When your browser determines that the domain name of the site you're on is associated with the public key being used to encrypt HTTP transmissions (and maybe that they’re controlled by a specific organization), it uses a certificate it downloads from the Website itself. How then can this certificate be trusted? Because it was cryptographically signed by some other organization who issued the public key and presumably checked the credentials of the company buying the certificate for the domain.

But that raises the question "how can we trust the organization that issued the certificate?" By checking its certificate, and so on up the chain until we get to the root (this process is called “chain path validation”). The root certificates are distributed with browsers and we trust the browser manufacturers to only include trustworthy root certificates. These root certificates are called “trust anchors” because their trustworthiness is assumed, rather than derived.

Webs of Trust

In contrast, a Web of Trust model uses webs of interlocking certificates, signed by multiple parties to establish the veracity of a certificate (see Web of Trust on Wikipedia for more detail). An entity can be part of many overlapping webs of trust because its certificate can be signed by many parties.

Sovrin uses a heterarchical, decentralized Web of Trust model, not the hierarchical PKI model, to establish the trustworthiness of certificates. The methodology for doing this is built into the Sovrin system, not layered on top of it, by combining a decentralized ledger, decentralized identifiers, and verifiable claims. While Sovrin Foundation will establish some trust anchors¹ (usually the same Stewards who operate validator nodes on the Sovrin network), these are merely for bootstrapping the system and aren’t necessary for the trusting the system once it is up and running. Sovrin uses this trust system to protect itself from DDoS attacks, among other things.

By allowing an identifier to be part of multiple webs of trust, Sovrin allows for reputational context to be taken into account. For example, being a good plumber doesn’t guarantee that a person will be a good babysitter, but a person who was a good plumber and a trustworthy babysitter could be part of different webs of trust that take these two contexts into account. The makes the overall trust model much more flexible and adaptable to the circumstances within which it will be used. PKI is good for one thing on the Web: showing the public key used to secure HTTP transmissions is correct. In contrast, Sovrin’s decentralized web of trust model is good for anything people need.

The goal of Sovrin is to provide the infrastructure upon which these overlapping webs of trust can be built for various applications. Lyft, Airbnb, and countless other sharing economy businesses are essentially specialized trust frameworks. Sovrin provides the means of creating similar trust frameworks without the need to build the trust infrastructure over and over.

Building Trust

Trust anchors are not the only way one could build trust in an identifier for a given purpose. I can think of the following ways that an identifier could come to be trusted:

1. Personal knowledge — The identifier is personally known to you through interactions outside Sovrin. People close to me would be in this category. This category also includes identifiers like those for my employer or other entities who I interact with in the physical world and can thus establish a trust connection through means outside of Sovrin. If I know and trust the Web site of an entity, a well-known discovery scheme could let me know what identifiers they claim and consequently I’d gain trust in those identifiers. Such a system could piggyback on the PKI used for Web certificates.
2. Verifiable claims — The identifier is verified by reliance on other trustworthy claims. This is analogous to how banks use KYC to establish trust in a person opening an account. They check other documents that they can trust (like a driver license or passport). They trust those documents by relying on trust established via the method described in (1).
3. Web of trust — The identifier is introduced to me by someone I trust or who can be transitively associated with someone I trust. This category most closely follows the PGP Web of trust model described in the wikipedia article I reference above. Various entities have signed the certificate associated with the identifier and I can trace those signatures back to other entities I trust.

Trust anchors, as the term is used in the Sovrin documents, have been designated by Sovrin or other trust anchors as a trustworthy source. But they are not the only source of trust.

In conclusion, trust on Sovrin works much the same way as it does in the physical world. This has advantages and disadvantages. The chief advantage, as I’ve pointed out, is that Sovrin is flexible and adaptible to various circumstances.

The chief disadvantage is that it relies on people being responsible for determining whether or not to trust something. There are lots of clues that people can use. How well it ultimately works depends on the user experience and whether people understand what’s being asked of them. But there will be cases where people mistakenly trust things they shouldn’t. Of course that happens today, online and off, as well. I’m hopeful that a richer set of trust clues will lead to less fraud than we currently see. Whether that’s true or not depends on design decisions yet to be made. Fortunately those can be made with 15 years of experience from identity on the Web to guide us.

Endnotes:

1. Because the term “trust anchor" is heavily associated with PKI, it might make sense to use another one to avoid confusion.

Photo Credit: Spiderweb with Frost from Yintan (CC BY 4.0)