Trust Spanning Protocol (TSP)

The Trust Spanning Protocol is a messaging protocol specified by the Trust Over IP Foundation (TSP Specification Rev 2, November 2025 Experimental Implementer’s Draft). It’s a leaner alternative to DIDComm — and as of late June 2026, it is the ecosystem’s preferred transport: official guidance across the VTI flipped to TSP > DIDComm > REST.

Key Characteristics

• HPKE-Auth encryption — Hybrid Public Key Encryption (RFC 9180) with authentication
• CESR binary encoding — Composable Event Streaming Representation, a compact binary format
• Simpler than DIDComm — fewer layers, less complexity, designed for high-performance scenarios
• Direct, Routed, and Nested message modes — including relay through mediators and cross-mediator federation

How the Ecosystem Adopted It

TSP’s promotion happened in a coordinated burst across three repos in June–July 2026:

• Affinidi TDK did the heavy lifting (~60 commits): the affinidi-tsp crate graduated from experimental to supported, was declared fully interoperable with the ToIP reference tsp_sdk (verified by a round-trip interop harness), and the mediator became dual-protocol — it sniffs DIDComm vs TSP frames on the same endpoint and websocket, bridges between the two, and federates TSP across mediators. Clients select TSP automatically when a peer supports it, with DIDComm fallback.
• VTI initially deferred TSP (2026-06-22 decision record) because the mediator couldn’t route it — then reversed that decision three days later when the TDK work landed, and shipped TSP as a first-class managed service on the VTA (enable/disable/rollback via pnm services, DID templates advertising a TSPTransport service, a TSP health probe).
• did-hosting-service added TSP as a third transport binding alongside HTTPS and DIDComm — possible in one PR because every wire operation there is a transport-agnostic Trust Task document (“everything is a trust task”).

Design decisions worth knowing: DIDs double as TSP VIDs reusing existing Ed25519/X25519 keys (no new key material); capability discovery is DID-document-driven — peers advertise a service of type TSPTransport, and senders prefer it over DIDCommMessaging when present; TSP rides the same per-DID mediator websocket as DIDComm, so no second socket.

Relationship to DIDComm

TSP and DIDComm serve similar purposes (secure, DID-based messaging) but make different trade-offs. DIDComm is more established with broader tooling; TSP is leaner and tracks the ToIP standards direction. The current posture is TSP-preferred, DIDComm as the interop layer: TSP support is feature-gated and opt-in today, with stated intent to make it default-on after field exercise, and proactive outbound flows in some services still use DIDComm.

See also: didcomm, affinidi-tdk, verifiable-trust-infrastructure