Trust indicators in permissionless systems

[holantonela]

We discussed security indicators in the past and I've been thinking about how to approach them in permissionless systems. I've been rambling around trust indicators vs security indicators, definition of trust, trust in permissionless systems and whatnot. I gave a talk in ETH Argentina about this (the recording is in spanish) and i'd love to discuss all this with this community. Pasting some notes here below:

---

Trust is a critical component of permissionless distribution systems. To build resilient decentralized networks and ensure their integrity, we need to establish trust protocols that empower users to form subjective experiences of trust without external embodiment.

So, if we think of trust as necessary for the cooperative functioning of these decentralized networks of peers, without intermediaries, subjective, we can definitely see it as a spectrum.

In the context of distributed technologies and permissionless systems, the question of trust can take various dimensions. Often, discussions are approached from a technocratic perspective: "I only trust the system; I don't need to trust an individual or peer." This viewpoint emphasizes minimizing trust and suggests that trust is defined by the context of the system we use. However, it's unlikely to be that simple. Are we creating trust-generating machines because we no longer trust each other? Do I need to trust another party to transact if there are no intermediaries? How can I trust this peer, who is part of the same distributed network (often anonymous)? And that's where it gets intriguing. Let's approach a definition of trust.

Trust is the instrument through which the trustor, the one who trusts, manages contingencies related to trusting a trustee to act competently in their interest within a specific context. Blockchains could be seen as examples of a shift in trust mediation structures: from interpersonal trust mediated by human intermediaries to trust mediated by technology.

When we talk about trust, we can see it as a relationship between parties:

1. Social actors [interpersonal trust]
2. An actor and an institution [institutional or systemic trust]
3. Institutions and trusted actors (trust as shared expectations), where the institutional framework defines the nature and strength of that trust relationship.

I like Balazs Bodo's perspective from the University of Amsterdam, where he refers to technological operators as "trust-mediating services." He examines this more in the context of media and policies, but it helps illustrate the protocol <> client relationship. In this case, the client is the wallet. Bodo argues that globalization and digitization have led to a crisis of trust, as traditional institutional and interpersonal logics are inadequate to address risks introduced by digital technologies. He describes how digital intermediation has transformed traditional logics of interpersonal and institutional trust formation, creating new trust-mediating services. He also raises a brilliant question: "Why should we trust these technological mediators of trust?"

Bodo also highlights something interesting: the management of distrust. Keeping a known but untrusted entity within the system becomes counterproductive and undermines the system's legitimacy.

I've been studying security indicators for a while and consistently wonder if there's a better way to expose them in a structure without a central authority. Security indicators like the lock icon in the browser's address bar or warning pages before accessing a malicious site come to mind. But wait, are security indicators trust indicators? Sometimes. I believe that usable security has commoditized trust (eg. VeriSign, DigiCert..). That makes me think that corporations have always defined trust relationships with institutions and have established a level of security based on that corporate notion of trust? A legal move, indeed. So, I ask if these systems displaying security indicators are indeed disguising corporate trust indicators. Trust is commoditized, placed within a regulatory framework, and presented to the user, creating an illusion of decision-making freedom within a decentralized network.

If I critically reflect on my role as a client of this protocol, if I consider how to expose this level of trust to the user, I certainly reach the edges.
What is the role of the client for that end user (for the protocol) when measuring, exposing, defining trust indicators? How do we expose trust indicators, without relying on a central authority, to users to ensure consensual interactions?

The design goal should not be to increase user trust levels or help people appear more trustworthy, but rather to encourage trusted actions that subsequently translate into trust. The design of these systems will determine the behaviour of people and will affect the level of trust and cooperation.

Some ideas/experiments:
- Petnames
- Delegatable

Some readings that shaped this brain-dump

Trust as a Social Reality, David Lewis, Andrew Weigert
Trust in Blockchain-based Systems, Moritz Becker, Balázs Bodó
In Digital We Trust: Bitcoin Discourse, Digital Currencies, and Decentralized Network Fetishism, Jon Baldwin
The Mechanics of Trust: A Framework for Research and Design, Jens Riegelsberger, M. Angela Sasse, John D. McCarthy
A Glossary of Technological Resistance and Decentralization, Valeria Ferrari, Florian Idelberger and others
Crying Wolf: An Empirical Study of SSL Warning Effectiveness
Where the Wild Warnings Are: Root Causes of Chrome HTTPS Certificate Errors
Client-Side Scanning: What it is and why it threatens trustworthy, private communications

[DougAnderson444]

Interesting that you mention "Delegatable" as an idea. Can you expand on what you mean?

I know that there is delegation amongst trusted certificate authorities, delegation amongst devices, then there's delegation amongst people.

I'm also intrigued by web of trust. Do we delegate trust to 1st and 2nd degree connections in a web of trust?

[holantonela]

Thanks for jumping here @DougAnderson444!

Interesting that you mention "Delegatable" as an idea. Can you expand on what you mean?

Yes. Delegatable is a consent-based framework for delegating trust inspired by OCAPs. It is currently in development and is an interesting example of exposing trust indicators because delegations here open a tree of trust. I'm walking this problem space while it is being built, so happy to discuss this together.

I'm also intrigued by web of trust. Do we delegate trust to 1st and 2nd degree connections in a web of trust?

It is beautiful that you mention web of trust. I did not include it in my notes, but for sure, there is a shared problem space. Of course, we are closer to PGP than to PKI in this discussion, with the hope that new fashions of PKIs emerge with the intent of succeeding in decentralizing everything.

For PGP specifically, see how key signing parties are foundational moments of this trust relationship. It allows the system to share with the trustee signals prior to the trusting action. If the key signing party enables a 1st degree of trust (as interpersonal), sharing that trust scheme enables the subsequent degrees.

---

We are discussing all this stuff (and more rambling) in our monthly meeting, you are welcome to join!

[DougAnderson444]

I'm thinking of a web of trust beyond PGP actually. There's a new framework based on Delegatable Anonymous Credentials that I've been researching ( https://eprint.iacr.org/2022/680) and building some experiments on top of. The gist of it is: DAC combines verifiable credentials (VCs) with a Delegation model. This is cool because the Delegation portion decentralizes updates within a credential system. Instead of having to return to the Issuer every time the user wants to update some details, they can use the Issuer's proof to update their own details. It decentralizes any updates away from the root issuer (certificate authority) and places the power of updates in the hands of the holder --who always remains anonymous. This ties into the trust model because any verifier trusts that the Issuer gave valid initial credentials to the holder, and that the Issuer trusts the holder to add attributes that makes sense. Anyway this is all very new (circa 2022) but very exciting. Looking forward to chatting about all this at the meetups.

…

On Tue., Sep. 19, 2023, 10:51 a.m. antonela, ***@***.***> wrote: Thanks for jumping here @DougAnderson444 <https://github.com/DougAnderson444>! Interesting that you mention "Delegatable" as an idea. Can you expand on what you mean? Yes. Delegatable <https://delegatable.org/docs/counterfactual-delegation> is a consent-based framework for delegating trust inspired by OCAPs. It is currently in development and is an interesting example of exposing trust indicators because delegations here open a tree of trust. I'm walking this problem space while it is being built, so happy to discuss this together. I'm also intrigued by web of trust. Do we delegate trust to 1st and 2nd degree connections in a web of trust? It is beautiful that you mention web of trust. I did not include it in my notes, but for sure, there is a shared problem space. Of course, we are closer to PGP than to PKI in this discussion, with the hope that new fashions of PKIs emerge with the intent of succeeding in decentralizing everything. For PGP specifically, see how key signing parties are foundational moments of this trust relationship. It allows the system to share with the trustee *signals prior to the trusting action*. If the key signing party enables a 1st degree of trust (as interpersonal), sharing that trust scheme enables the subsequent degrees. ------------------------------ We are discussing all this stuff (and more rambling) in our monthly meeting, you are welcome to join! <https://lu.ma/tyyxp3uf> — Reply to this email directly, view it on GitHub <#14 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABTDW7J544U5MAZ77GT6V63X3GPO3ANCNFSM6AAAAAA4QSYRC4> . You are receiving this because you were mentioned.Message ID: ***@***.*** com>