Shane Deconinck Trusted AI Agents · Decentralized Trust

Understanding TSP: The Trust Spanning Protocol Explained

Trust across organizational boundaries

The Hidden Prerequisite

Linux Foundation Decentralized Trust is building a protocol called TSP through Trust over IP. The First Person Project, C2PA, and the Linux kernel are amongst those adopting it. Here's why I believe you shouldn't sleep on it for agentic AI, even though it applies much broader.

MCP and A2A let agents pick their partners.
Neither lets them verify a stranger.

Agent acts on behalf of a user. Token exchange within the shared auth system.
MCP Linux Foundation AAIF
Agent connects to tools. You already have accounts with those tools.
A2A Linux Foundation
Agent talks to agent. Credentials were exchanged beforehand.
AgentGateway Linux Foundation
Central policy checkpoint. You still need credentials with each service.

This works great when that shared base exists. Inside your company. With services you've connected to. With partners you've onboarded.

For agentic AI to reach its true potential, this doesn't cut it.

Kept on a Leash

Today's agents only work with partners you've already onboarded. Pre-registered OAuth apps. Pre-exchanged API keys. Pre-established federation.

The exciting use cases need more. A procurement agent reaching thousands of suppliers. A research agent querying services it's never seen. A student agent applying to universities abroad.

Right now, they can't. The leash is the auth system.

Agents Navigating Trust

Agents need to make trust decisions: Is this counterparty legitimate? Can I rely on their response? Should I share sensitive data with them?

Example: Your agent is onboarding a new vendor. It needs to verify business registration, credit rating, certifications. Can it query registries directly and know the response is authentic?

If there's no pre-established relationship,
how do you establish trust?

Your Company onboarding agent New Vendor vendor agent no prior relationship ? what attestations do they bring? who endorsed them?

Why Current Approaches Don't Work

Today, enterprises solve B2B trust with EDI networks, API partnerships, SAML federation. All require setup per relationship.

Register with each counterparty? Manual. Doesn't scale.
New counterparties should trust your auth system? Your tokens mean nothing to them.
Universal B2B identity provider? GLEIF (Global Legal Entity Identifier Foundation) gives you LEIs, not auth.

EDI, federation, API partnerships work for stable relationships. For agents connecting to new counterparties at runtime, we need something else.

Three Gaps

When you look closely at cross-org agent communication, three specific gaps emerge:

1Cross-domain identity
Verify who you're talking to without a shared IdP
2Cross-domain auth
Your OAuth tokens mean nothing to their system
3Cross-domain non-repudiation
OBO works within a domain. Across orgs? No shared authority to arbitrate.

The Question

How do two endpoints that have never met
establish trust without a shared authority?

This requires a different trust model altogether.

Decentralize Trust

The current model: verify identity by phoning home to a central authority.

Authority Agent A Agent B "trust them"

The alternative: verify directly using cryptographic proof. No phoning home.

VIDs, trust registries, verifiable credentials Agent A Agent B direct

Decentralized verification. The identifier itself proves control.

Verifiable Identifiers

This model requires identifiers that are self-certifying: the identifier itself proves control, without calling home to an authority.

Example: did:web

did:web:supplier.io

Resolves to a document at https://supplier.io/.well-known/did.json containing public keys.

Both sides fetch each other's public keys. Now they can:

  • Encrypt messages only the other can read
  • Sign messages to prove authorship
  • Verify the other's signatures

No OAuth handshake. No pre-registration. Both sides look up each other's public keys, check trust registries, and start communicating securely.

Enter TSP

We have the building blocks: VIDs for identity, registries for legitimacy, credentials for attestation. What's missing is a protocol that ties them together.

TSP (Trust Spanning Protocol) is that protocol. A minimal layer for establishing trust between any two endpoints.

Developed by Trust over IP under Linux Foundation Decentralized Trust, with contributors from Futurewei, Gen Digital, and the decentralized identity community. The same ecosystem behind W3C DIDs and Verifiable Credentials.

TSP does exactly three things:

Encrypt Sign Address

That's it. Deliberately minimal.

The Thin Waist

Why "spanning"? Like IP in networking, TSP is a thin waist: one simple protocol that connects many things above (apps, agents, wallets) to many things below (different identifier types, key systems).

Trust Applications wallets, agents, apps Trust Tasks VCs, issue, verify TSP Trust Support DIDs, KERI, X.509 The ToIP Stack

IP is the thin waist for packets. TSP is the thin waist for trust.

Deliberately Minimal

TSP doesn't care about transport (HTTPS, WebSocket, Bluetooth), identifiers (DIDs, KERI, X.509), or encoding (JSON, CBOR).

There is no "TSP network." Like HTTP, it's a protocol you speak. Two parties speaking TSP establish trust directly.

TSP isn't agent-specific. It works for any cross-boundary trust: IoT, supply chain, B2B. This explainer focuses on the AI agent use case.

TA2A in Action

Let's see TA2A (A2A over TSP) in action. Back to our example: your agent is onboarding a new vendor. No existing relationship. A2A handles discovery and task semantics. TSP handles the trust layer.

Your Agent
did:web:yourcompany.com
New Vendor
did:web:newvendor.io

The Flow

TA2A: A2A over TSP
Acme Agent client Supplier Agent server GET /.well-known/agent.json Agent Card name: "Supplier Agent" url: "https://supplier.io" No existing credentials with Supplier Resolve VIDs Trust Registry D&B, industry dirs query query TSP Acme Wallet private key did:web:acme.com Supplier DID doc public key did:web:supplier.io A2A in TSP envelope

TA2A: A2A over TSP

Click through to see how TSP enables agent-to-agent trust without pre-existing credentials.

Details
A2A: discovery + task protocol
TSP: identity + encryption + signing
1/8

What Just Happened

No OAuth dance
Public key lookup replaced token exchange
Cross-domain proof
Acme signed with their private key. Supplier verifies without a shared IdP.
End-to-end encryption
Only Supplier can decrypt. Not even intermediaries.

This demo showed A2A over TSP. A2A handles discovery and task semantics. TSP handles the trust layer underneath.

Same pattern applies to MCP: that's TMCP (MCP over TSP). An agent connecting to a tool server it's never seen? TSP verifies the server's identity and encrypts the channel. MCP handles the tool protocol on top.

No shared authority. No pre-registration.
Just keys.

See TMCP/TA2A: Running AI Agent Protocols over TSP (Wenjing Chu, Futurewei) for the full technical walkthrough.

Beyond TSP

TSP establishes trust. It doesn't handle everything, but the rest comes from the same decentralized ecosystem.

Trust registries
TSP proves who sent a message. DIDs and VCs guide you to registries that verify legitimacy.
Wallets
Private keys need secure storage. EUDI Wallet, EUDI Business wallets, and similar handle key management.
Verifiable Credentials
Identity ≠ permission. VCs carry capabilities and permissions alongside identity.

TSP Today

TSP spec reached Revision 2 in November 2025. Developed under Linux Foundation Decentralized Trust.

This isn't a side project. At the LF Member Summit keynote, Jim Zemlin endorsed the First Person Project to prevent another XZ-style attack: personhood credentials + relationship credentials that would have stopped "Jia Tan" from ever obtaining maintainer rights. TSP is the protocol layer underneath.

Active integration work across different domains:

First Person Project open source supply chain
Linux kernel credential subsystem
Git signed commits
C2PA content authenticity
TMCP / TA2A MCP and A2A over TSP

Building on a Decade

Don't sleep on this. The wallet and credential ecosystem has been building for nearly 10 years. It's not hype: it's infrastructure that's ready.

Standards
W3C DID, VC/VP, ...
Decentralized identifiers and verifiable credentials
Government
EUDI Wallet, EBSI, ...
Government digital identity
Enterprise
GLEIF (Global Legal Entity Identifier Foundation) vLEI, Entra Verified ID, ...
Business identity and corporate wallets
Networks
cheqd, ION, ...
Production DID infrastructure

Decentralized identity meets agentic AI.
The plumbing is maturing.

Resources

Talks (ToIP Symposium, Nov 2025)

TSP Integration Updates Wenjing Chu (Futurewei)

Spec & Code

TSP Specification Implementers Draft, 2025
TSP for AI Interactions White Paper, 2025
TSP Rust Implementation OpenWallet Foundation

Related Explainers