Shane Deconinck

TSP (Trust Spanning Protocol)

An emerging protocol for trust across organizational boundaries

The Hidden Prerequisite

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 no prior relationship ? no shared auth system

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 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 authorization. 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 Hourglass

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).

L4 Trust Applications wallets, agents, apps, ecosystems L3 Trust Tasks credential exchange, VCs, issue, verify L2 TSP Trust Spanning Protocol L1 Trust Support DIDs, DPKI, key management

The ToIP model: TSP sits at Layer 2, enabling everything above it.

Deliberately Minimal

TSP doesn't care about transport (HTTPS, WebSocket, Bluetooth), identifiers (DIDs, KERI, X.509), or encoding (JSON, CBOR). It works with whatever you have.

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

The Scenario

Back to our example: your agent is onboarding a new vendor. No existing relationship. How does this work with TSP?

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. 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.

What TSP Doesn't Solve

TSP handles the cryptographic layer. It doesn't handle everything.

Trust registries are separate
TSP proves who sent a message. DIDs and VCs guide you to registries. Which ones you trust is up to you.
Key management lives in wallets
Private keys need secure storage. The emerging wallet ecosystem (EUDI Wallet, EUDI Business wallets) handles this layer.
Authorization via credentials
Identity ≠ permission. Verifiable Credentials can carry capabilities and permissions alongside identity.

TSP Today

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

Active integration work across different domains:

Linux kernel credential subsystem
Git signed commits
C2PA content authenticity
Matrix secure messaging
TMCP / TA2A AI agent protocols

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 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