← All Articles
Thought Leadership 6 min read

Open by Design: Building Trust Infrastructure In Public

Affinidi joins the Linux Foundation and contributes OpenVTC — a decentralised, privacy-preserving trust framework — to explain why trust infrastructure cannot be proprietary in the agentic AI era.

Anna Varosyan

The internet was never built for the level of autonomy we are now asking of it. For decades, trust online was implicit, provisional, and frankly good enough. You logged in with a password, exchanged emails, and assumed the person on the other end was roughly who they claimed to be. That assumption worked when humans were interacting. It does not hold when AI agents and bad actors are in the mix.

We are entering an era where software acts autonomously on your behalf: booking, negotiating, purchasing, and signing. When an AI agent transacts with another AI agent, or acts on behalf of a human whose identity it must credibly represent, the question of trust stops being a feature requirement and becomes existential. Who authorised this action? How do we know this agent is who it claims to be? Can the decision be audited, challenged, or reversed?

These are not hypothetical questions; they are the questions that infrastructure builders must answer today, before the agentic era matures past the point where retrofitting becomes impossible.

Why Trust Infrastructure Cannot Be Proprietary

The logic is straightforward: if the foundation on which digital trust is built is owned and controlled by a single company, it is really just a product. Products come with lock-in, pricing decisions, discontinuation risk, and the ever-present possibility that the company’s commercial interests diverge from the ecosystem’s needs. That divergence becomes genuinely dangerous when the product in question underpins how organisations, people, and AI systems verify each other.

The Linux Foundation exists precisely to prevent this. It has spent decades building a governance model that holds critical software infrastructure as genuinely common property — managed transparently, developed collaboratively, and shaped by the people who depend on it rather than by those who profit from it. Our participation is a commitment to the same governance standard that underpins much of the internet’s critical infrastructure.

AI systems are increasingly cross-boundary. They move across organisations, jurisdictions, and technology stacks. If the identity and trust layer beneath them is proprietary and fragmented, interoperability becomes a liability and adoption stalls. Open standards, by contrast, allow any compliant implementation to interoperate seamlessly, lowering the barrier to entry and raising the ceiling for what the whole ecosystem can achieve.

Linux Foundation OpenVTC

What We Are Building, And Why It Matters

Consider a problem the Linux kernel community has been living with for decades. Authenticating the developers who contribute to the world’s most widely deployed operating system has long relied on PGP key-signing — a process built on face-to-face rituals and manual verification that would struggle to scale, and has already shown what happens when it fails. Kernel maintainers, working with the Linux Foundation and Affinidi, are now exploring Linux ID as a decentralised replacement, using credentials and cryptographic proofs of personhood rather than centralised key databases. The proposal is still in its early stages, but its emergence in one of the world’s most scrutinised codebases speaks for itself — the technology it is built on solves problems that go well beyond any single community.

That technology is what OpenVTC puts into practice. OpenVTC provides a decentralised, privacy-preserving framework for establishing and verifying trust relationships between real people and the digital communities they participate in. The initiative implements what is called the First Person Protocol, which asks the question: how does one prove that a digital participant is a real, unique human with genuine trust relationships, without creating centralised databases or compromising personal privacy?

Developers and technical architects wanting to understand how these components fit together should read The Architecture of Accountability, which covers the OpenVTC architecture in depth.

Open Source Contribution

What This Means For Organisations Building With Affinidi

For teams evaluating or building on our technology, the implications of open-source trust infrastructure are concrete. Open components mean the stack is portable, composable, and transparent — with no hidden dependencies, no “black boxes” in the part of the system that handles identity. Enterprise teams can audit exactly how trust is being established and represented, which matters considerably in regulated industries and cross-border deployments.

The security argument is equally direct. Open-source cryptography and identity protocols benefit from the kind of scrutiny that closed systems never receive. Participating in the Linux Foundation ecosystem, one of the most rigorously reviewed technical environments in the world, strengthens the security posture of everything built on Affinidi, and makes the broader ecosystem more resilient as a result.

A Commitment To The Standards Ecosystem

OpenVTC is not a one-off. Affinidi participates across the standards landscape, including the Decentralised Identity Foundation, where our did:webvh implementation now lives, because the goal is to help shape the standards alongside the engineers and institutions who will be building with them for the next decade.

Some technical contributions to date include a did:webvh implementation donated to the Decentralised Identity Foundation (DIF), DIDComm v2.1 secure messaging protocol, Personhood Credentials (PHCs) for verifying real humans, Verifiable Relationship Credentials (VRCs) for mapping peer-to-peer trust networks, a Trust Registry that is fully compliant with the Trust Registry Query Protocol (TRQP) v2.0 specification, just to name a few.

Looking Forward

As I often say to our team: the AI era demands a trust infrastructure that no single company can, or should, control. Our Linux Foundation membership and OpenVTC contributions represent a commitment to solving these challenges openly, through shared standards and collaborative development that benefits the entire ecosystem. We are building it because it needs to exist, not to own it.

If you are working in decentralised identity, contributing to open standards, or evaluating trust infrastructure for your organisation, we would welcome the conversation here.

Explore our open-source repositories and documentation here.

OpenVTC Architecture

Read our technical blog post:

The Architecture of Accountability: How OpenVTC Builds Decentralised Trust for the Agentic Web

for a detailed look.

The following resources are available here:

Open StandardsAI AgentsTrustDecentralised IdentityLinux Foundation

Build with Affinidi

Start building trust infrastructure with our open-source tools and developer-friendly APIs.

Cookie Preferences

We use cookies to enhance your experience. You can manage your preferences below. For more information, read our Cookie Policy.

Strictly Necessary Always Active

These cookies are essential for core website functions such as security, session integrity, and cookie preference storage. They cannot be disabled.

  • _cf_bm: Distinguishes humans from bots (Cloudflare) · 30m
  • _cfuvid: Ensures secure browsing (Cloudflare) · Session
  • __hs_initial_opt_in: Prevents HubSpot's banner · 7 days
  • _gtm_debug: GTM debug mode (testing only) · Session
Analytics

These cookies help us understand how visitors interact with the site so we can improve content and performance. All data is aggregated and anonymous.

  • _ga, _gid, _gat: Google Analytics · Session – 2 years
  • __hstc, hubspotutk, __hssrc: HubSpot visitor tracking · 13 months
  • __hs_opt_out: HubSpot opt-out preference · 6 months
Marketing & Targeting

These cookies allow us and our partners to serve personalised ads and measure campaign performance.

  • _gcl_au, _gcl_dc: Google Ads conversion tracking · 90 days
  • IDE: Google Display Network personalisation · 1 year
  • _fbp: Meta / Facebook remarketing · 90 days
  • li_gc, _li_fat_id, bcookie: LinkedIn tracking · 1–24 months
  • guest_id, personalization_id: Twitter/X analytics · 2 years