Where do you put a trust registry in a decentralized digital ecosystem? Not where it turns into a wrench

By Trevor Butterworth

The Trust over IP Foundation has just published a long document describing a set of design principles “to inform, guide, and constrain the design of… decentralized digital trust infrastructure.”

We’re not convinced that “constraint” is the right theoretical approach for an emerging technology, especially one that is being deployed in different sectors for different use cases. To underscore this, we want to address a particular constraint implied by ToIP’s design concepts that is likely to be fatal to any deployment.

This follows from the design concept of “transitive trust,” which can be summarized by the deduction that If A trusts B and B trusts C, then A can trust C.

In other words, if a Verifier trusts an Issuer, it should logically trust a Holder bearing a digital credential that is verified as being from that Issuer. This is how passports work.

To scale this “trust triangle” for ecosystems where there are many, many issuers of digital credentials, ToIP proposes that the triangle must become a “governance trust diamond,” where a governance authority rules on which Issuers can be trusted by Verifiers.

ToIP illustration of the Trust Diamond

This sounds reasonable and straightforward; someone, inevitably, is going to set the rules for an ecosystem and we need to acknowledge that someone in the architecture. How could any verifier know all the possible issuers of a particular kind of credential (say a lab test result) in anything but a very small network? Wouldn’t the simplest way be to ping a trust registry or a rules engine under the control of a governance authority to get that information?

Yes and no.

Yes, because all ecosystems are going to need governance; no, because governance handled through a centralized trust registry or rules engine will, at best, be inefficient, and at worst, be unworkable.

Do not put a trust registry here

If it doesn’t work offline, it doesn’t work. The fundamental problem with a centralized trust registry is that it’s dependent on real-time calling and this makes the whole system dependent on being able to make those calls. What happens when the connection goes down — or the Internet connection is weak or intermittent? You can’t have a trusted ecosystem that is only capable of delivering trust some of the time.

There is, however, a simple solution to this fatal system error—decentralize the governance so that the trust registry rules are cached locally, in the software for issuers, holders, and verifiers. This means these rules will work offline. We call this “machine-readable governance.” Instead of calling the trust registry to verify in real time, governance authorities publish their rules in files that can be quickly uploaded and propagated across participants in a network. This has the added benefit of making verification quicker as there is no need to check in with an intermediary.

Do not put a trust registry here

Think of machine-readable governance as a “smart” trust registry — it makes the governance authority portable.

There’s also another significant benefit to using machine-readable governance: it allows for more complex governance interactions such as “A trusts B and B trusts C, but A only trusts C for some purposes or in some contexts.” A machine-readable governance file makes these “if this, then that” governance rules easy to implement without any sharing of private information with a trust registry.

Do not put a trust registry here

Diamond of Trust or Ring of Power? We understand that in any ecosystem for verification and data sharing, there needs to be a governance function—where people get to enact governance as to who can participate and how. But it’s not clear that it is wise to encode this function in a third-party entity that functions as the sole source of truth for the entire network. What if some participants want to reject some or all the governance—should they be excluded from the ecosystem?

Another advantage in avoiding a single centralized trust registry model is that it allows multiple governance authorities to coordinate governance rules in hierarchical ways, such as national rules superseding state or local rules. These multiple “opinions” are all available to verifiers who can then choose which combination is important as they evaluate presented credentials. The buck stops at the verifier, and nuanced interpretation is possible. This makes an ecosystem capable of mapping to the governance requirements that exist in the real world.

The phone home problem. A centralized trust registry also raises the problem inherent to any centralized exchange: It knows your business—who’s verifying whom, and who’s using which credentials where. This kind of surveillance runs counter to the spirit of decentralized and self-sovereign identity—especially when you combine it with the next point:

For whom the Trust Registry tolls. A centralized trust registry opens the door to monopolistic business practices and rent seeking. If you allow a third party to erect a toll booth, it will charge a toll. Great for the third party, not so great for everyone using the road. Unsurprisingly, when third-party trust registries and rules engines are created in the real world, this is what happens.

Where sovereign authorities must be in control. In our experience, national governments and global enterprises want to be in control of the things they are supposed to control and are held accountable for. That’s why they prefer machine-readable governance to governance by third parties.

For all these reasons, we recommend ToIP add the concept of machine-readable governance to its design principles and to explore the many ways it can be implemented.

 

A machine-readable governance reference implementation

For those interested in machine-readable governance, Indicio will shortly make a reference implementation available through the Linux Foundation Public Health’s open source Cardea Project for digital health credentials.

On March 17, Cardea will then run a second “Interop-a-thon” for companies using Hyperledger Aries Agents to practice implementation in interoperable environments.

Keep checking in with Cardea for more details—or join the Cardea Community Group!

And, If you want to discuss how machine-readable governance could solve your information flow needs now, then contact us!