Trust Spanning Protocol (TSP)

The Problem: Metadata Leaks in Cross-Org Credential Exchange

When verifiable credentials are exchanged across organizational boundaries, metadata leaks identity:

Example: Healthcare credential exchange

Alice (patient) wants Hospital A to share her medical records with Hospital B.

Traditional approach:

1. Alice requests: “Hospital A, send my records to Hospital B”
2. Hospital A’s system knows: Alice is requesting transfer to Hospital B (reveals her choice of provider)
3. Network observers see: Hospital A → Hospital B traffic (reveals patient movement patterns)
4. Hospital B knows: Request came from Hospital A (reveals prior provider)

Metadata leaked:

• ❌ Which hospitals Alice visited
• ❌ Timing of transfers (reveals health episodes)
• ❌ Network of providers (aggregate data reveals Alice’s health journey)

This is true even when credential content is encrypted.

Why This Matters

Metadata is data:

• Surveillance: Aggregate metadata across patients reveals health trends, demographics, who treats whom
• Correlation: Link Alice’s hospital visits to pharmacy visits, employer health plans, insurance claims
• Discrimination: Health insurers see “Alice visited Cancer Center” in network metadata—deny coverage
• Competitive intelligence: Hospitals see which competitors patients transfer to—valuable business data

The fundamental problem: Credential exchange requires routing—and routing reveals who talks to whom, when.

Trust Spanning Protocol (TSP) solves this: a routing layer that delivers credentials across organizational boundaries without revealing routing metadata to intermediaries or even the participants themselves.

---

What Is Trust Spanning Protocol?

TSP is a metadata-private routing protocol for verifiable credentials, designed by the W3C Credentials Community Group and first implemented in production by Affinidi.

Core properties:

1. Metadata privacy: Intermediaries cannot see sender, recipient, or credential type
2. Unlinkability: Multiple credential exchanges from same sender cannot be correlated
3. Cross-org routing: Works across organizational boundaries without merged directories
4. Trust registry integration: Validates routing authority without revealing routes
5. Production-ready: No trusted setup, no blockchain, no central clearinghouse

TSP is not:

• ❌ A transport protocol (uses DIDComm as transport)
• ❌ A credential format (works with any W3C VC)
• ❌ A trust model (uses Trust Registries for validation)

TSP is: A routing layer that sits between DIDComm (transport) and verifiable credentials (content), ensuring metadata privacy during cross-org exchange.

---

How TSP Works: High-Level Flow

Scenario: Cross-Hospital Credential Transfer

Alice wants Hospital A to send her medical credential to Hospital B.

Without TSP (metadata leak):

Alice → Hospital A: "Send my credential to Hospital B"
  [Hospital A sees: Alice → Hospital B]
  
Hospital A → Hospital B: [credential]
  [Network sees: Hospital A → Hospital B]
  [Hospital B sees: came from Hospital A]

Metadata leaked: Alice’s choice, hospital relationship, timing.

With TSP (metadata private):

Alice → TSP Relay 1: [encrypted: "route to Hospital B"]
  [Relay 1 sees: message from Alice, next hop = Relay 2]
  [Relay 1 does NOT see: final destination or Hospital A involvement]
  
TSP Relay 1 → TSP Relay 2: [encrypted: "route to Hospital B"]
  [Relay 2 sees: message from Relay 1, next hop = Hospital B]
  [Relay 2 does NOT see: original sender or Hospital A involvement]
  
TSP Relay 2 → Hospital B: [encrypted credential]
  [Hospital B sees: credential arrived]
  [Hospital B does NOT see: came from Hospital A, or that Alice initiated]

Metadata protected:

• ✅ Relays see only: previous hop → next hop (like Tor)
• ✅ Hospital B sees: credential, but not sender
• ✅ Hospital A sees: credential sent, but not recipient (optionally)
• ✅ Network observers see: relay-to-relay traffic, cannot correlate Alice’s exchanges

---

TSP Architecture: Layered Privacy

Layer 1: DIDComm Transport (Encrypted)

DIDComm provides end-to-end encryption for messages:

• Sender encrypts message with recipient’s public key
• Only recipient can decrypt
• Network observers see encrypted blob

But: DIDComm routing reveals metadata—each relay sees sender DID → recipient DID.

Layer 2: TSP Routing (Metadata-Private)

TSP wraps DIDComm with onion routing:

1. Onion encryption: Message encrypted in layers (like Tor)

   • Outer layer: encrypted for Relay 1 (contains next hop = Relay 2)
   • Middle layer: encrypted for Relay 2 (contains next hop = Hospital B)
   • Inner layer: encrypted for Hospital B (contains credential)

2. Each relay peels one layer:

   • Relay 1 decrypts outer layer → sees “next hop = Relay 2” → forwards
   • Relay 2 decrypts middle layer → sees “next hop = Hospital B” → forwards
   • Hospital B decrypts inner layer → receives credential

3. No relay sees full route:

   • Relay 1 knows: message from Alice, next hop = Relay 2 (doesn’t know Hospital B is final destination)
   • Relay 2 knows: message from Relay 1, next hop = Hospital B (doesn’t know Alice sent it)
   • Hospital B knows: credential arrived (doesn’t know Alice or Hospital A initiated, unless credential reveals it)

Layer 3: Trust Registry Integration

Problem: How does Hospital B trust the credential’s routing path?

Solution: TSP integrates with Trust Registries (TRQP):

• Each relay is registered in Trust Registry with authorized routing capabilities
• Hospital B queries: “Is this credential’s routing path valid?” → Trust Registry confirms relays are authorized
• Metadata privacy maintained: Trust Registry query reveals credential arrived, but not routing details

---

TSP Message Structure: Onion Layers

Example: Alice → Hospital B (via 2 relays)

Layer 4 (innermost): Credential payload

{
  "type": "VerifiableCredential",
  "issuer": "did:webvh:hospital-a",
  "credentialSubject": {
    "id": "did:webvh:alice",
    "medicalRecord": "..."
  },
  "proof": { ... }
}

Encrypted for: Hospital B’s public key

Layer 3: Relay 2 instructions

{
  "nextHop": "did:webvh:hospital-b",
  "payload": [Layer 4 encrypted blob]
}

Encrypted for: Relay 2’s public key

Layer 2: Relay 1 instructions

{
  "nextHop": "did:webvh:relay-2",
  "payload": [Layer 3 encrypted blob]
}

Encrypted for: Relay 1’s public key

Layer 1 (outermost): Alice sends

{
  "from": "did:webvh:alice",
  "to": "did:webvh:relay-1",
  "payload": [Layer 2 encrypted blob]
}

At each hop:

1. Relay 1 receives message:

   • Decrypts Layer 2 with its private key
   • Sees: nextHop = "did:webvh:relay-2"
   • Does NOT see: Hospital B (encrypted in Layer 3), credential (encrypted in Layer 4)
   • Forwards Layer 3 blob to Relay 2

2. Relay 2 receives message:

   • Decrypts Layer 3 with its private key
   • Sees: nextHop = "did:webvh:hospital-b"
   • Does NOT see: Alice (no sender info in Layer 3), credential (encrypted in Layer 4)
   • Forwards Layer 4 blob to Hospital B

3. Hospital B receives message:

   • Decrypts Layer 4 with its private key
   • Sees: Credential from Hospital A (if credential includes issuer DID)
   • Does NOT see: Alice initiated (unless credential includes her as subject), relay path

Result: No single party sees full route. Relays see only their segment.

---

Metadata Privacy Properties

1. Unlinkability

Two credential exchanges from Alice cannot be correlated by relays:

• Round 1: Alice → Relay 1 → Relay 2 → Hospital B (credential A)
• Round 2: Alice → Relay 3 → Relay 1 → Hospital C (credential B)

Relay 1 cannot tell:

• Both came from Alice (different routes)
• Any relationship between exchanges (unlinkable)

How: Each exchange uses different route, different ephemeral keys, different timing.

2. Sender Privacy

Recipient (Hospital B) does not learn who initiated the credential exchange—unless the credential itself reveals it.

Example:

• Credential contains: "issuer": "did:webvh:hospital-a" → Hospital B learns issuer
• Credential contains: "credentialSubject.id": "did:webvh:alice" → Hospital B learns subject
• But: Credential does not contain routing metadata (who sent it via TSP, which relays)

Use case: Whistleblower credential—issuer confirms authenticity, but recipient doesn’t know who delivered it.

3. Recipient Privacy

Sender (Alice) does not learn who received the credential—unless TSP is configured to reveal it.

Example:

• Alice sends credential via TSP
• Relay 2 delivers to Hospital B
• Alice only knows: credential sent via Relay 1 → (rest of route hidden)

Use case: Employer credential verification—employee sends credential, doesn’t know which background check service verified it.

4. Relay Privacy

Each relay knows only previous hop + next hop—not full route, not sender, not recipient.

Example:

• Relay 1 knows: message from Alice → forward to Relay 2
• Relay 1 does not know: Relay 2 forwards to Hospital B, or credential content

Result: Compromising one relay reveals one segment, not full route.

---

Trust Registry Integration: Routing Authority

Problem: How does Hospital B trust the routing path?

Without Trust Registry:

• Relays are unauthenticated—anyone can run a relay
• Malicious relay could inject fake credentials, drop messages, surveil traffic

With Trust Registry (TRQP):

1. Relay registration: Each relay registers in Trust Registry:

   • Relay DID: did:webvh:relay-1
   • Authorized capabilities: ["tsp-routing", "healthcare-credentials"]
   • Operator: Organization name, jurisdiction

2. Routing validation: Hospital B receives credential, queries Trust Registry:

   • “Was this credential routed through authorized relays?”
   • Trust Registry responds: “Yes, relays 1 and 2 are authorized for healthcare TSP routing”

3. Revocation: If relay is compromised, Trust Registry marks it invalid:

   • Next credential routed through compromised relay → Hospital B rejects

Metadata privacy maintained:

• Trust Registry query reveals: “credential arrived via TSP”
• Trust Registry query does not reveal: specific relays used, sender, timing

---

TSP vs. Alternatives

TSP vs. Direct Credential Exchange

	TSP	Direct Exchange
Metadata privacy	✓ Relays hide route	✗ Recipient sees sender
Unlinkability	✓ Cannot correlate exchanges	✗ Sender DID links all
Surveillance resistance	✓ Network observers see relay traffic	✗ Network sees A → B
Complexity	⚠ Onion routing overhead	✓ Simple
Latency	⚠ Multi-hop (+100-200ms)	✓ Direct (low latency)

When to use TSP: Cross-org credential exchange where metadata privacy is critical (healthcare, whistleblowing, sensitive verifications).

When to use direct: Same-org, low-latency, metadata privacy not required.

---

TSP vs. Tor

	TSP	Tor
Use case	Credential routing	Web browsing anonymity
Transport	DIDComm (structured messages)	TCP streams (arbitrary data)
Trust model	Trust Registry (TRQP)	Tor directory (consensus)
Credential verification	✓ Native (Trust Registry)	✗ Not credential-aware
Relay incentives	Registered orgs (compliance)	Volunteers (altruism)
Production-ready	✓ Affinidi live	✓ Mature (20+ years)

TSP borrows from Tor: Onion routing, multi-hop forwarding, unlinkability.

TSP differs from Tor: Credential-native, trust registry integration, enterprise deployment model.

---

TSP vs. Blockchain-Based Routing

	TSP	Blockchain Routing
Metadata privacy	✓ Onion routing	✗ All transactions public
Latency	⚠ Multi-hop (200ms)	✗ Block confirmation (seconds to minutes)
Cost	✓ Free (relay operators)	✗ Gas fees per transaction
Scalability	✓ Relay throughput	✗ Blockchain throughput limit
Regulation-friendly	✓ GDPR compliant (off-chain)	⚠ Immutable public ledger

Blockchain is not suitable for metadata-private routing—all transactions are public, slow, and expensive.

---

Affinidi’s TSP Implementation: First in Production

Affinidi is the first to deploy TSP in production (2025):

Architecture

• Agent Gateway: Constructs TSP onion-routed messages
• Affinidi Messaging: DIDComm transport layer
• Trust Registry: Validates relay authority via TRQP
• Relay Network: Operated by Affinidi + partners (healthcare institutions, compliance orgs)

Use Cases

1. Cross-hospital credential transfer (healthcare)

   • Patient credentials routed between hospitals without revealing patient choice
   • Relays operated by regional health information exchanges (HIEs)

2. Reusable KYC (finance)

   • Bank A issues KYC credential → Bank B verifies
   • TSP hides: Alice chose Bank B (competitive intelligence)

3. Employment verification (HR)

   • Employee credential from Company A → Company B
   • TSP hides: Employee left Company A (reduces poaching)

Relay Operators

Who runs TSP relays:

• ✅ Affinidi (bootstrap network)
• ✅ Healthcare institutions (HIPAA-compliant relays for PHI routing)
• ✅ Financial institutions (regulatory-compliant relays for KYC/KYB)
• ✅ Government digital identity programs (national relay networks)

Incentives:

• Compliance: Regulated industries need metadata-private routing (GDPR, HIPAA)
• Competitive advantage: Early adopters attract privacy-conscious users
• Ecosystem participation: Relay operators join Trust Registry, gain authority

---

Limitations and Trade-offs

1. Latency Overhead

Multi-hop routing adds latency:

• Direct credential exchange: ~50ms (local network) to ~200ms (cross-region)
• TSP (3 hops): +100-200ms overhead → total 150-400ms

Mitigation:

• Use TSP only for privacy-critical exchanges
• Optimize relay placement (geographic proximity)
• Cache relay routes (reduce route discovery overhead)

2. Relay Trust Assumptions

TSP relies on honest relays:

• Compromised relay can drop messages, delay delivery, or log metadata (one hop only)
• Collusion: If multiple relays collude, they can deanonymize routes

Mitigation:

• Trust Registry vets relays (regulatory compliance, audits)
• Multi-relay paths (compromising one relay reveals one hop only)
• Relay rotation (each exchange uses different route)

3. Correlation via Timing

Traffic analysis: If adversary observes all network traffic, can correlate:

• Message enters Relay 1 at time T
• Message exits Relay 2 at time T+100ms → likely same message

Mitigation:

• Padding (add random delays at each relay)
• Dummy traffic (relays send cover traffic to obscure real messages)
• Batching (relays forward multiple messages together)

Trade-off: Padding/batching increases latency.

4. Not Anonymous End-to-End

TSP provides metadata privacy, not anonymity:

• Credential content may reveal sender (issuer DID) or recipient (credential includes destination)
• TSP hides routing metadata, not credential content

Use case for anonymity: Combine TSP with zero-knowledge proofs (BBS+ selective disclosure) to hide credential content.

---

TSP in Practice: Code Example

Simplified TSP message construction (conceptual):

// Step 1: Build credential payload
const credential = {
  type: "VerifiableCredential",
  issuer: "did:webvh:hospital-a",
  credentialSubject: { id: "did:webvh:alice", record: "..." },
  proof: { ... }
}

// Step 2: Define route (sender chooses relays)
const route = [
  { did: "did:webvh:relay-1", publicKey: relay1PubKey },
  { did: "did:webvh:relay-2", publicKey: relay2PubKey },
  { did: "did:webvh:hospital-b", publicKey: hospitalBPubKey }
]

// Step 3: Onion encrypt (innermost to outermost)
let payload = encrypt(credential, hospitalBPubKey) // Layer 4

payload = encrypt({ nextHop: route[2].did, payload }, relay2PubKey) // Layer 3
payload = encrypt({ nextHop: route[1].did, payload }, relay1PubKey) // Layer 2

// Step 4: Send to first relay
await didcomm.send({
  from: "did:webvh:alice",
  to: route[0].did,
  payload: payload
})

// Relay 1 receives, decrypts Layer 2, sees nextHop = relay-2, forwards
// Relay 2 receives, decrypts Layer 3, sees nextHop = hospital-b, forwards
// Hospital B receives, decrypts Layer 4, gets credential

Affinidi SDK abstracts this—developers call:

await affinidi.sendCredentialViaTSP({
  credential: myCredential,
  recipient: "did:webvh:hospital-b",
  privacyLevel: "high" // auto-selects 3-hop route
})

---

Future of TSP

Short-term (2026-2027)

• ✅ Production deployment (Affinidi live)
• ⏳ Healthcare adoption (regional HIE relay networks)
• ⏳ Financial services pilots (KYC/KYB routing)
• ⏳ W3C standardization (TSP specification finalized)

Medium-term (2027-2029)

• ⏳ Government relay networks (national digital identity programs)
• ⏳ Mobile-first relays (low-power devices as relay nodes)
• ⏳ TSP + ZKPs (combine metadata privacy + content privacy)
• ⏳ Relay incentive layer (tokenized relay operators)

Long-term (2029+)

• ⏳ Global TSP network (federated relays across jurisdictions)
• ⏳ Post-quantum TSP (quantum-safe onion encryption)
• ⏳ TSP for IoT (device-to-device credential routing)

---

Get Started with TSP

Affinidi’s TSP is live in production:

• Send credentials via TSP: affinidi.sendCredentialViaTSP()
• Operate a relay: Register in Trust Registry, join relay network
• Verify routing authority: Query Trust Registry via TRQP

Start building →

Documentation:

• W3C TSP Specification
• Affinidi Messaging (DIDComm + TSP)
• Trust Registry (TRQP)

---

Related Resources

Technical Deep Dives

• DIDComm Messaging - Transport layer for TSP
• Verifiable Credentials - What TSP routes
• Trust Registries & TRQP - How relays are validated

Related Solutions

• Cross-Org Agent Trust - Uses TSP for metadata-private agent communication
• Reusable KYC - TSP hides bank choice in KYC exchange
• Supply Chain Provenance - TSP for custody chain routing

---

Summary

Trust Spanning Protocol (TSP) enables metadata-private routing for verifiable credentials:

Core properties:

• ✅ Onion routing (like Tor) hides full route from relays
• ✅ Unlinkability prevents correlation across exchanges
• ✅ Trust Registry integration validates relay authority without revealing routes
• ✅ Production-ready (Affinidi first implementation, 2025)

Trade-offs:

• ⚠ Latency overhead (+100-200ms for multi-hop)
• ⚠ Relay trust assumptions (honest relays required)
• ⚠ Traffic analysis vulnerable to global adversaries (mitigated with padding/batching)

When to use TSP:

• Cross-org credential exchange where metadata privacy is critical
• Healthcare (HIPAA), finance (KYC), employment (competitive intelligence)
• Whistleblowing, sensitive verifications, surveillance resistance

Where Affinidi uses TSP:

• Affinidi Messaging (DIDComm transport with TSP routing)
• Agent Gateway (constructs onion-routed messages)
• Trust Registry (validates relay authority via TRQP)

Result: Verifiable credentials exchanged across organizational boundaries with metadata privacy—no party sees full route, relays cannot correlate exchanges, network observers cannot surveil.