The Architecture of Accountability: How OpenVTC Verifies Individuals and AI Agents

There was a time when interacting online felt simple. A username on open-source software (OSS) contribution meant a real contributor. A commit came from a real engineer sitting somewhere in the world. A message in a community forum came from a human whose intentions you could at least guess.

That world is fading. Today, AI agents generate code, negotiate with services, and imitate human patterns convincingly enough that the old signals of trust no longer hold. We can no longer assume the entities we interact with are genuine, accountable, or even human. For developers building modern systems, this shift breaks the basic contract on which collaboration has always relied. Who wrote this code? Who approved this change? Who is joining this project, this community, this decision? These used to be simple questions. Now they require new tools, new guarantees, and new ways of establishing authenticity that do not depend on central gatekeepers or invasive identity checks.

For a real-world application of this problem and what the Linux kernel community is doing about it, read The Linux Kernel Trusts Your Code. Should It Trust You?.

The Open Verifiable Trust Communities initiative (OpenVTC) is our answer. It provides a decentralised, privacy-preserving way to ensure that contributors, participants, and community members are verifiable and that relationships are trustworthy through an identity that can be relied on without exposing who someone is.

OpenVTC’s architecture: the mental model

OpenVTC implements what is called the First Person Protocol, which starts from a single foundational question: how do we prove that a digital participant is a real, unique human with genuine trust relationships, without creating centralised identity databases or compromising privacy?

The architecture answers this through four interconnected layers that each build on the previous one:

1. Cryptographically anchored identifiers: give every participant a self-sovereign identity they control.
2. Secure messaging layer: enables trust relationships to form and credentials to flow without a centralised broker.
3. Personhood Credentials (PHCs): attest that the holder is a real, verified human within a given ecosystem.
4. Verifiable Relationship Credentials (VRCs): capture the peer-to-peer trust relationships between people, building a decentralised trust graph that lives at the edges rather than in a central database.

Together, these four layers create the foundations of an entirely different way to think about digital trust. Instead of collecting identity data in one place or relying on a single authority to validate everyone, OpenVTC allows trust to emerge organically from cryptographic identifiers, private channels, and verifiable credentials held directly by participants.

The decentralised trust graph: a distributed model for personhood and relationships

A decentralised trust graph (DTG) is a model for proving personhood and establishing trust relationships without relying on a centralised database. Instead of storing information in a single place, it uses verifiable digital credentials kept in each individual’s digital wallet, much like the physical credentials we carry today. There is no global database containing everyone’s information; the graph can emerge from many issuers, each responsible for verifying that a participant is real and unique.

The model is built on two W3C standards — Decentralised Identifiers (DIDs) and Verifiable Credentials (VCs) — both of which are explained in the sections below. By distributing verification across many participants, the trust graph spreads the “trust load” across ecosystems rather than concentrating it in a central system. A helpful way to visualise this: think of your phone’s address book as a personal network that exists without depending on any central social network. In a decentralised trust graph, each participant maintains their own subgraph of trust relationships — stronger privacy, greater security, and individual control over personal data, while still enabling reliable verification of personhood and trust relationships across diverse ecosystems.

The operational layers of trust: VTC, VTN and the Verifiable Trust Infrastructure

A Verifiable Trust Community (VTC) is where policy becomes practice. Each community defines its trust boundaries, authorised roles, and credential policies, and it does so in a way that participants can verify rather than simply believe. When communities need to collaborate, they connect through a Verifiable Trust Network (VTN) that lets a verifier in one community rely on personhood and relationship proofs issued in another, subject to local policy and registry checks.

The Verifiable Trust Infrastructure (VTI) turns these concepts into running code. The Verifiable Trust Agent (VTA) manages decentralised identifiers, cryptographic keys, presentation exchange, selective disclosure, and zero-knowledge proofs (ZKPs) on behalf of a participant such as an individual, an AI agent acting on behalf of individuals, or a VTC. At the same time, the Trust Registry serves as the source of authority for issuers and verifiers within the community. This is how the graph moves from a whiteboard to a working system.

First layer: decentralised identity with did:webvh

Every participant in OpenVTC begins with a Decentralised Identifier (DID) — a cryptographically anchored identifier that the participant controls, not a third party. OpenVTC uses an enhanced DID method, did:webvh, that improves on the standard did:web specification in several ways.

Standard did:web ties identity to a specific domain, which creates portability problems when domains change and provides no mechanism for verifying that DID document changes are legitimate. did:webvh takes the simplicity of did:web and adds the security, durability, and trust guarantees needed for long-lived decentralised identifiers. It introduces a verifiable, tamper-evident history of every update to a DID, allowing anyone to audit its evolution from creation to the present. A self-certifying identifier, or SCID, anchors this history and keeps the identifier stable even if its hosting domain changes, preventing attackers from recreating or hijacking the DID. did:webvh also strengthens key management through authorised update proofs, optional pre-rotation keys for safer key recovery, and an optional witness mechanism that allows multiple parties to validate updates before publication.

Affinidi has donated our did:webvh implementation, developed for the OpenVTC project, to the Decentralized Identity Foundation (DIF) as open-source software.

The Rust implementation is available in our public repository, and we are pleased to see it adopted more broadly across the decentralised identity community.

Second layer: secure messaging with DIDComm v2.1

With identities in place, the next question is how credentials and trust signals flow between participants without a central broker. DIDComm v2.1 is the messaging layer that enables this.

DIDComm provides end-to-end encryption, sender authenticity, and non-repudiation — which are table stakes for trust infrastructure — along with sender anonymity when the protocol context requires it. Critically, it is entirely decentralised: messages route between participants using their DID rather than through any intermediary service.

Affinidi maintains open-source DIDComm v2.1 client and server components in both Dart and Rust. The Rust implementation, in particular, reflects our commitment to high-assurance cryptography: Rust’s memory safety guarantees and compile-time checks eliminate entire categories of vulnerabilities that plague identity systems implemented in less strict languages. The Dart implementation extends this interoperability to mobile and cross-platform environments, where much of the real-world credential exchange actually occurs.

Third layer: Personhood Credentials — verifying real humans

Within this decentralised trust graph, Personhood Credentials (PHCs) serve as the anchor of the ecosystem, proving that a participant is a real, unique human while allowing them to interact through service-specific pseudonyms that cannot be linked across services, even by issuers or colluding providers.

PHCs are specialised Verifiable Credentials issued by qualified entities, such as companies, universities, nonprofits, and open-source communities, that are stored locally in the user’s wallet rather than on any server. They are cryptographically verifiable, privacy-preserving through zero-knowledge proofs, and independent of centralised identity databases. Where biometric checks are needed to strengthen Sybil resistance, they are always processed locally; the result of the check (pass or fail) is what gets attested, not the underlying biometric data.

PHCs are structured using W3C Verifiable Credential formats, with credential objects, signing mechanisms, and verification logic that are fully specified and auditable. Implementation details, including the credential schema and signing libraries, are available in the OpenVTC repository.

Fourth layer: Verifiable Relationship Credentials — mapping trust networks

Where Personhood Credentials establish that someone is real, VRCs supply the relational structure — how people are connected, and why that connection matters in a given context. Proving that someone is real does not necessarily indicate whether they are trustworthy in a given context. VRCs allow individuals to make peer-to-peer attestations, such as “I know this person professionally,” “we collaborate in an open-source community,” or “I can vouch for this person’s expertise,” which collectively form the trust graph.

The implementation uses participant key pairs and cryptographic signatures to ensure attestations are genuine and non-repudiable. OpenVTC provides APIs for computing trust paths and confidence levels within the graph, enabling verifying parties to make nuanced assessments rather than binary trust/no-trust decisions. Critically, the trust graph is stored entirely at the edges, distributed across participants’ digital wallets, rather than any centralised database. No organisation owns the graph; each participant owns the node and the relationship edges associated with it.

How can a participant prove trust-related claims while keeping all their actual VRCs and relationships completely private? Zero-knowledge proofs solve a core problem in digital trust: how to verify something about a person without forcing them to hand over sensitive data. Instead of showing the data itself, the prover shows a mathematical proof that convinces the verifier that the claim is valid and nothing more. This allows a person to prove things like being over 18, owning a credential, or having enough trusted relationships in a network without exposing personal details, documents, or connections. The use of zero-knowledge proofs allows participants to keep their PHCs and VRCs private while still proving that they meet certain trust thresholds. A user can prove they have enough VRCs, or that their trust score is valid, without revealing who trusts them or why. This gives DTGs the ability to provide verifiable trust while preserving privacy and individual control.

The Trust Registry

The Trust Registry provides authoritative information about which entities are authorised to perform specific actions on defined resources within a community’s trust boundaries. Each entity is identified by its DID, ensuring cryptographic integrity and interoperability across decentralised identity ecosystems.

Affinidi’s Trust Registry implementation is open source (Dart and Rust) and fully compliant with the Trust Registry Query Protocol (TRQP) v2.0 specification. The TRQP standard was deployed in the Ayra Trust Network that demonstrated the protocol operating at ecosystem scale.

Getting started

The stack is implemented in Rust. If you have Cargo installed, you can be up and running in a few minutes:

git clone https://github.com/LF-Decentralized-Trust-labs/openvtc.git
cargo install --path openvtc-cli
openvtc setup

The setup wizard handles the details: generating cryptographic keys, creating and configuring a profile, generating your Persona DID, and connecting to a DIDComm mediator. The overall experience is designed to be approachable for developers who are not identity specialists, whilst giving specialists the complete control they need.

For a more guided introduction, our documentation includes worked examples of issuing and verifying PHCs, creating VRCs between participants, and querying the Trust Registry.

Why Rust and why open-source

The choice of Rust for the core implementation is deliberate. Trust infrastructure handles cryptographic keys, sensitive credentials, and operations where a memory-safety bug is not just a performance issue but a security catastrophe. Rust’s compile-time guarantees eliminate entire categories of vulnerability — buffer overflows, use-after-free, data races — that have historically plagued security-critical systems. The performance characteristics are also excellent, which matters for an always-on agent service.

We are not philosophically opposed to commercial software. We are simply committed to the proposition that trust infrastructure specifically should not be proprietary. The code that establishes and verifies trust should be readable, auditable, and improvable by anyone who depends on it. That is what we mean when we say we are building this in public.

What comes next

We are continuing to build out the OpenVTC specification alongside the First Person Collective and the broader community. Immediate priorities include expanded tooling for credential issuance, additional DIDComm transport implementations, and deeper integration guidance for organisations deploying OpenVTC in enterprise contexts. The First Person Cooperative uses the DTG model to build and govern the First Person Network, which is the first global network designed to provide universally interoperable personhood credentials.

If you want to contribute, the repositories are open, and the contribution guidelines are straightforward.

We are particularly interested in collaborators working on agent-to-agent trust scenarios, credential wallet implementations, and Trust Registry federation. The community channels are listed below. For those interested in the broader standards landscape, Affinidi participates in the Decentralised Identity Foundation and contributes to related working groups. The did:webvh specification, in particular, is evolving rapidly and benefits from implementation feedback.

For the full story of how this came about, read The Linux Kernel Trusts Your Code. Should It Trust You?.

Resources

• OpenVTC GitHub Repository
• Affinidi did:webvh Implementation
• DIDComm v2.1 Dart and Rust Components
• TRQP v2.0 Specification and Trust Registry Implementation
• OpenVTC Documentation and Getting Started Guide
• OpenVTC Contribution Guidelines
• Decentralised Identity Foundation
• First Person Collective
• VTI/VTC/VTA source