Terminology proposal: trust agents

[talltree]

Introduction

On today’s HTX call, we discussed the need to begin transitioning from our current alphabet soup of technology acronyms—VTA, VTC, VTN, VTI (not to mention all the DTG credential acronyms)—to the market-facing terms we need for real adoption.

The conversation quickly focused on the core concept of a VTA, since it is the fundamental new tool that makes VTI work. We compared the role of a VTA in VTI architecture to that of a browser in web architecture. We agreed it would be ideal to have a simple market-facing term for a VTA—our equivalent of the term “browser”.

However, we face a structural challenge that the web did not. The web’s client/server architecture made it very easy to have one term for the client—”browser”—and one for the server—”web server” (and one for the content—”website”).

VTI is fundamentally a peer-to-peer architecture. We can’t make the same distinction. We have two basic architectural patterns—as reflected by the two open source "trust stacks" under development (P2P Trust Stack and OpenVTC)—plus two mixed options.

1) Local-first. The VTA(s) run at the edge—there is no assumption of a server. If a person wants multiple VTAs on different local devices, those VTAs must communicate/sync with each other. This architecture may take advantage of utility servers or mediators in the cloud for discovery or other purposes, but those must be optional so the VTAs always have some way to connect and communicate without them.

2) Cloud-only. The VTA(s) run on a server (home, office, or in the cloud). A plain browser is the primary interface.

3) Cloud+clients. This is a cloud VTA plus any number of local clients, e.g., standalone apps, browser plug-ins, and/or VTA client functions integrated within existing apps. Each local client is “paired” (once) with the cloud VTA to establish an authenticated connection. The local clients can also do biometric authentication and liveness.

4) Local+cloud hybrid. This combines local-first and cloud VTAs and (somehow) apportions functionality between them—meaning a local-first VTA can take some actions independently and invoke other actions as a client to a cloud VTA. (Yes, this is the most complex option, but I don’t think we can rule it out.)

Terminology proposal

Assuming we need to support all of these patterns, it would be ideal if we could choose one term that works regardless of the specific pattern a person is using. Besides sheer simplicity, this also means the term does not need to change if a person migrates to a different architecture (e.g., starts out with local-first VTA(s), adds a cloud VTA, etc).

Proposal: the term trust agent could work uniformly across all architectures—regardless of whether the VTA is local-first or cloud, or whether it is a client or a server, or whether it is for a person, community, or network.

Usage examples

Local-first: You download/install a trust agent on your phone (or tablet, laptop, etc.). This app will (at least initially) be your entire experience of using a trust agent. If you decide to start using multiple local-first trust agents, you use a standard HTX ceremony to safely “introduce” them to each other (the term “pairing” doesn’t work as soon as you have more than two local trust agents).

Cloud-only: You either install a trust agent on your own personal server, or you choose a verifiable trust service provider (VTSP) and set up your trust agent using a browser much like you would interact with a blog, personal website, AI chatbot, etc.

Cloud+clients: In this scenario, your mental model is simply that you have a trust agent in the cloud and “connect” any number of local trust agents operating on your local devices—as standalone apps, browser-plug-ins, or new features within existing apps (banking, health, travel, etc.)

It won’t matter that these are technically clients of the cloud trust agent—a user doesn’t have to understand anything about “clients” or “servers”. Their mental model can simply be that each time they install a new trust agent locally, they go through a one-time ceremony to “pair” this local trust agent with their cloud trust agent (again, HTX should standardize this ceremony so it meets Kim Cameron’s 7th Law of Identity—Consistent User Experience).

Local+cloud hybrid: Again, the term “trust agent” works here because the user doesn’t need to distinguish between a local trust agent that operates standalone, a local trust agent that operates as a client, or a cloud trust agent. They are all simply the user’s trust agents that all coordinate to do the user’s bidding.

The analogy with email

Having a trust agent—and using it to join and participate in trust communities and trust networks—can be thought of as like "having email" (an analogy that is even more applicable as VTI gradually evolves into end-to-end secure messaging infrastructure).

So from an adoption standpoint, we can take advantage of user's mental models of how email works. For example, if you install an email client app (e.g., Apple Mail, Gmail, Thunderbird, etc.), your mental model is that the app needs to talk to an email server on which you have an email account. If you don’t have an email account yet, the app will typically guide you through registering one.

The same flow can apply to installing a trust agent app. If it is designed to be a local-first trust agent, then setting it up will be like webmail—once you are done, it will "just work". If the app is designed to be a trust agent client, then when you first install the app, it will prompt you: “Pair with an existing cloud trust agent? Or set up a new cloud trust agent?” As with an email account, if you don't have a cloud trust agent yet, the app will guide you through setting one up.

Bonus: The term “trust agent” anticipates fiduciary AI

We all know the age of AI agents is upon us—and that one of the most compelling reasons to have a personal trust agent will be to have a digital twin for personal AI. So we can “catch this wave” by adopting the mental model of the user having their own family of agents, starting with a trust agent for all aspects of personal trust management. It won't matter whether the trust agent actually uses any AI—it will still be an agent acting on their behalf, and it can very naturally evolve into having (or controlling) other personal AI capabilities.

"Trust agent" works for VTCs and VTNs too (and replaces "PNM" and "CNM")

A VTC will have a community trust agent and a VTN a network trust agent. In 99% of the cases, these will be cloud trust agents, but again, the modifier "cloud" will rarely be needed.

Also, we have been using personal network manager (PNM) and community network manager (CNM) as the terms for personal VTA clients and VTC VTA clients, respectively. Now these can just types be of trust agents. Only when it matters will we need to add the modifier “local”, “client”, "server", “cloud”, "personal", "community", and/or "network".

[swatchen]

I would like to call it a V-Trust Agent so it is easier to link back to "VTA". Personal agents such as an external digital twins and internal virtual assistants are examples of Trust Enabeled Agents (TEAs) from the perspective of the AIM group, they contain VTA/ utilize VTAs for the trust tasks they rely on to function.

[guru-barbes]

Early on I was wary of the agent being interpreted as / assumed to an AI agent, but have gotten over that and now think we'll soon begin to think of an agent in its truest / formal definition, and all agents will be preceded by its descriptor (booking, scheduling, coding, health...).

I think trust agent will work.

But I also think of it as a trust signalling agent. It helps surface the essential signals a human needs to make their own trust decisions.

[talltree]

I like the whole idea of trust signaling. Interestingly, it works both ways—on behalf of its principal, a trust agent both sends trust signals to others (e.g., proof of personhood credentials, membership creds, etc.), and receives/verifies trust signals from others.

[guru-barbes]

yes indeed - good point. I also think of these agents acting as trust gates, or trust marshals.