TSP (Trust Spanning Protocol) 1.0 has been formally approved by the Trust Over IP Technology Stack Working Group. TSP is a compact protocol that lets any two parties, people, organizations, devices or AI agents, exchange messages with authenticity, confidentiality and metadata privacy, with post-quantum security built in, whatever kind of verifiable identifier each one uses.
The TSP 1.0 specification, co-authored by Samuel M. Smith and me, is stable and ready to build on. This post covers why it matters now, what is already running on it, and how we got here.
The internet was built to move data, not to establish trust. For decades we patched that gap with passwords, certificates tied to domains, and platform accounts. In 2026 those patches are failing on four fronts at once.
AI agents now operate on web infrastructure that has no identity and trust layer. They browse, sign in, send email, call APIs, move money and change code through the same accounts and channels people use. When an agent shows up, there is no reliable way to know what it is, who stands behind it, or whether it should be trusted. It may be posing as a person, acting openly for one, acting for no one at all, or quietly hijacked by an attacker, and from the other side these all look the same. That uncertainty now runs through everything an agent touches. TSP addresses this at the root. It gives every party a strongly authenticated identity and makes their relationship authentic, establishing who said what to whom. Each party can verify this before acting, and each can be held accountable afterwards.
Generative AI has made impersonation cheap. Voices, faces and writing styles can be faked at scale, and detection will not keep up. The real defense is verifiable relationships: knowing who you are dealing with, through a durable identifier that party controls, and being assured that you are communicating with the real party.
Trust ecosystems are naturally diverse. Identifier methods, credential formats and wallet ecosystems differ for good reasons, serving different jurisdictions and industries. That diversity is healthy, but without a common layer, every pair of ecosystems needs its own bridge. TSP is designed to fill that role: a compact interworking layer that spans identifier types and trust boundaries, the way IP spans networks.
Trust also has to hold up over time. Data captured today could be decrypted once quantum computers become capable, which may not be far off. Accountability records, such as signed logs and audit trails, may need to remain verifiable for years. And trust relationships themselves are meant to last. In some areas, protecting all three calls for post-quantum cryptography now rather than later.
The common question behind all four is the one TSP was designed to answer: who said what to whom.
TSP is the spanning layer of the Trust Over IP stack: a minimal protocol that every higher-level trust application can share.
TSP 1.0 arrives with multiple independent implementations and three use cases behind it.
Implementations written separately against the same spec are the clearest sign a spec is precise enough to build on. The reference implementation generated the test vectors published in the spec, and the independent implementations pass the same vectors, producing identical bytes on the wire.
TSP's compact binary CESR framing keeps messages small and fast to process. In benchmarks on a consumer MacBook, sealing and opening a TSP message with a 1 MB payload took 7.56 ms and 6.30 ms. That was roughly three times faster vs the 31.23 ms and 14.76 ms of JSON-based JOSE envelopes (JWS/JWE), the approach used by many existing messaging protocols. The gap widens with routing: because TSP nests messages without re-encoding each layer, a 2,048-byte message relayed through two intermediaries grew to 2,646 bytes with TSP, versus 10,052 bytes with JOSE envelopes, about four times smaller. Because each JOSE layer re-encodes everything inside it, envelope size multiplies with every additional hop, while TSP adds only a small overhead per hop. That keeps metadata-private routing affordable.
Post-quantum security in TSP 1.0 is part of the protocol, not a future extension. TSP uses the NIST-standardized ML-KEM-768 in a hybrid with X25519 for encryption and ML-DSA-65 for signatures. It is not a separate mode: the algorithms follow each identifier's key type, so framing and processing stay the same and a relationship can move to post quantum when it needs to by changing keys, not protocols. The spec includes post-quantum test vectors, and post-quantum support already implemented in the TSP SDK (Rust, Python and JavaScript).
TSP is already at work in several prominent use cases: proof of personhood, trust among developers, and trust between AI agents.
1. Proof of personhood: the First Person Project and the Decentralized Trust Graph. The First Person Project is building open infrastructure that helps people prove they are real humans, with real first-person trust relationships, in an age of AI impersonation. Its open standards come from the ToIP / DIF Decentralized Trust Graph Working Group (DTGWG), which defines the trust graph's credentials and the trust tasks that exchange them.
"TSP sits at the very heart of the decentralized trust graph stack—it is the spanning protocol over which all DTG trust tasks run. With TSP establishing the secure private channel between any two verifiable trust agents, it becomes much easier to implement interoperable trust tasks such as issuing and verifying DTG verifiable relationship credentials.” — Drummond Reed, co-founder of the First Person Project and DTGWG co-chair
2. Developer trust: the Linux kernel developer community. The kernel's GPG web of trust, where new maintainers need their keys signed by two others, has become too slow and too hard to scale against threats like the XZ backdoor and floods of AI-generated pull requests, a problem Linux Foundation CEO Jim Zemlin challenged the community to solve. At the Linux Plumbers Conference in Prague in October 2026, the team demonstrated the first verifiable trust community for open source, built with OpenVTC, an LF Decentralized Trust lab, built on TSP for its authenticity, privacy and efficiency at scale. With OpenVTC, maintainers can exchange relationship credentials with one QR scan, and AI agents can prove they act for a verified contributor.
"The importance of each community defining their own messaging requirements, which can include different messaging protocols, multiple hops/relays and stricter privacy and security requirements, made it clear that TSP was a step forward in efficiency and security, especially with PQC support. In a complex network TSP is an order of magnitude smaller than DIDComm for example. TSP 1.0, combined with Trust Tasks, fully delivers an interoperable protocol layer between independent systems, ensuring that authenticity and integrity can be guaranteed." — Glenn Gore, CEO, Affinidi, and OpenVTC lead maintainer
3. Agent trust: TEA (Trust Enabled AI Agents). AI agents are starting to act on our behalf across trust boundaries, yet today's agent protocols still rely on security designed for people logging in to websites. TEA makes every agent a TSP endpoint with a durable identity, and lets agents negotiate and agree on the terms of their work. When a person or another agent entrusts an agent with a task, the agreement carries not just authority but responsibility: the constraints it must work within, the duties it takes on, and the care expected of it, all traceable back to an accountable person or organization. Every message is signed, verifiable evidence, and those bounds are enforced outside the AI model, so even a manipulated model stays within them. TEA integrates TSP with agent protocols such as MCP and A2A, both hosted by the Linux Foundation's Agentic AI Foundation, giving them a layer of authenticated identity, authority and responsibility. It is being developed in the AI and Human Trust Working Group (read the draft).
"An agent that can't be held accountable shouldn't be trusted with anything that matters. As we hand real work to AI agents, each one needs a verifiable identity, clear bounds on what it may do, the duties it takes on, and a person or organization who answers for it. TSP solves the hard, infrastructure-level foundation for trusting agents, and TEA builds on it." — Wenjing Chu, author of the ongoing TEA draft, chair of the ToIP AI and Human Trust Working Group, co-author of the TSP 1.0 specification
TSP is designed to be built on. Protocols layered over it inherit authenticated identity, confidentiality and metadata privacy instead of reinventing them, and can focus on their own job. That is already happening: the Decentralized Trust Graph Working Group's trust tasks, used by OpenVTC to exchange relationship, membership and delegation credentials, run over TSP; and TEA builds on it to let AI agents negotiate, delegate and exercise authority, and answer for it, across agent protocols.
TSP accepts any verifiable identifier. The current reference implementation uses did:webvh and did:peer, and plans to support others. KERI autonomic identifiers (AIDs) and KERI-based identifiers such as did:webs can also serve as TSP identifiers. did:scid is another example. We welcome contributors who want to take them on.
TSP 1.0 is complete and stable. It reflects several years of implementation experience across independent code bases and real use cases, and it is ready to build products on. With this release, the Working Group commits to supporting compliance and interoperability across implementations, and to maintaining backward compatibility as TSP evolves.
When I began drafting the ToIP Technology Architecture Specification, one question kept returning: what single layer could every trust application share, the way every internet application shares IP? TSP is the answer to that question.
Milestones along the way:
One debate that shaped TSP: should it simply adopt W3C Decentralized Identifiers (DIDs)? I argued for a different path, the Verifiable Identifier (VID), and the group came to agree. Any DID that is verifiable can serve as a VID, and so can identifiers that are not DIDs, such as KERI autonomic identifiers or identifiers in URN format. To me, what matters is not whether an identifier is decentralized, federated or centralized, but whether the other party can verify it and appraise it against its own criteria for that relationship, criteria that will differ from party to party. That decision is what lets TSP span the natural diversity of identifiers, and the trust boundaries between the communities that use them.
A 1.0 is a community achievement. Personally, I want to thank everyone who wrote spec text, filed issues, built implementations, tested against the spec's vectors and argued patiently over the details.
Above all, thank you to my co-author, Samuel M. Smith. Sam’s pioneering work on KERI and CESR laid foundations that TSP builds on.
Special thanks to Drummond Reed for co-chairing the TSP Task Force with Sam and me; to the Task Force members who brought brilliant ideas and undiminished enthusiasm to countless Zoom calls; to everyone who reviewed and contributed to the draft spec on GitHub; and to the TSP SDK maintainers. Thank you also to the KERI Suite Working Group, whose CESR and AID work TSP builds on; to Affinidi and Glenn Gore for building an independent implementation and OpenVTC; and to the First Person Project and the TEA team. The full list of contributors is on the TSP specification wiki page.
With 1.0 done, I see the work shifting from writing the spec to growing what is built on it. These are my own thoughts, not a formal roadmap.
I would like to see broader interoperability testing across implementations, building on the shared test vectors we already have. I hope more communities will bring their own identifiers to TSP, including KERI-based identifiers such as did:webs, and that we will see more bindings and transports, especially for AI agents, where work like TEA is just beginning. Over time, profiles tailored to particular ecosystems will make TSP easier to adopt in each of them.
If you build things, read the spec and try the TSP SDK. If you would like to help shape what comes next, join us at Trust Over IP, especially in the two working groups building most directly on TSP: the Decentralized Trust Graph Working Group and the AI and Human Trust Working Group.
Developers are just as welcome in the TSP SDK repository, where issues, bindings and contributions keep the reference implementation moving forward.