- Why do we need a Trust Spanning Protocol?
- Where can I get a high-level overview of TSP?
- What does the Implementers Draft cover?
- How does TSP differ from other trust protocols?
- What implementation projects have been announced?
- What kind of feedback are we seeking on this draft?
- How can you provide feedback?
Why do we need a Trust Spanning Protocol?
No one would question that the Internet has completely transformed the global information economy. It has become indispensable for connectivity and reliable content delivery. But as it has grown, so have the threats against it and the vexing challenges in deciding what to trust.
Now, AI is pushing those concerns into overdrive. A 2023 study by CyberArk found that 93% of security professionals expect AI-enabled threats to affect their organization in 2023—with AI-powered malware cited as the #1 concern. No less an industry luminary than Marc Andreessen recently said that the war against detecting AI fakes was unwinnable—our only solution was to find a way to “invert the problem” by being able to prove content authenticity.
Why, after 30 years of steadily compounding security issues, does industry not yet have a fix? Why, with technologies like DNSSEC and TLS, and industry bodies like IETF and the CA/Browser Forum, do we still have daily headlines about data breaches, ransomware attacks, identity theft, and malware infestations? Why, with the explosive interest in generative AI, are many experts more worried about it being used to attack us than to protect us?
The answer is the reason the Trust Over IP (ToIP) Foundation was founded four years ago. In short, authenticity, confidentiality, and metadata privacy features were never built into the core fabric of the Internet. To solve the root of this problem and not the symptoms, we need a next-generation trust layer on top of the existing Internet.
The heart of this layer is a protocol that is to digital trust what the Internet Protocol (IP) is to digital data. That is the ToIP Trust Spanning Protocol (TSP).
Where can I get a high-level overview of TSP?
First, start with this blog post we published in January 2023 when we launched the ToIP Trust Spanning Protocol Task Force (TSPTF). It explains the overall purpose of the TSP and where it fits in the ToIP stack.
Second, read the Mid-Year Progress Report on the ToIP Trust Spanning Protocol, published last August 2023 to summarize the seven pillars of the TSP design. With the exception of some terminology evolution, these seven pillars have not changed as we worked through multiple stages of Working Drafts over the past seven months.
Today we are pleased to announce the release of the first Implementers Draft.
What does the Implementers Draft cover?
This table summarizes the 10 major sections of the specification:
| Verifiable Identifiers (VIDs) | VIDs are the first of the seven pillars — cryptographically-verifiable identifiers that provide technical trust in the TSP. Covers: why they are necessary, how they provide access to public keys and ToIP endpoint addresses, how they are verified, and how keys can be rotated. |
| Messages | TSP is a message-based asynchronous communication protocol. Covers: message envelopes, payloads (confidential, non-confidential, headers), signatures, relationship setup and out-of-band introductions. |
| Nested Messages | TSP messages can be nested one or two layers to achieve metadata privacy. Covers: payload nesting, nested relationship VIDs. |
| Messages Routed through Intermediaries | TSP messages can be routed through intermediaries for several reasons, e.g., asynchronous delivery, reliability, and performance. However the primary focus is metadata privacy protection. Covers: message routing, direct neighbor relationships, endpoint-to-endpoint (“tunneled”) messages, private VIDs, single intermediaries, two-or-more intermediaries. |
| Multi-Recipient Communications | TSP messages may be sent to multiple recipients. Covers: multi-recipient lists and anycast intermediaries. |
| Control Payload Fields | TSP messages can be multi-purpose, so rather than dedicated control messages, the specification defines control payloads. Covers: relationship formation (parallel, nested, third-party introductions), relationship events (key updates, routing info, and relationship cancellation). |
| Cryptographic Algorithms | The authenticity and confidentiality properties of TSP relies on public/private key cryptography. Covers: public key signatures, public key authenticated encryption, encryption and decryption primitives, Hybrid Public Key Encryption (HPKE), Libsodium Sealed Box. |
| Serialization and Encoding | TSP uses Composable Event Streaming Representation (CESR) for message serialization and encoding. CESR supports popular data encoding formats including JSON, CBOR, MsgPak, and others. Covers: envelope encoding, payload encoding (non-confidential, confidential, nested), signature encoding. |
| Transports | TSP’s authenticity, confidentiality and metadata privacy properties are designed to be independent of the choice of transport protocol. Covers: transport service interface, transport mechanism examples. |
| Appendix A: Test Vectors | (Still being completed) Test vectors for common use cases. Covers: direct mode messages, direct mode nested messages, routed model messages. |
How does TSP differ from other trust protocols?
Proposing a fundamental new Internet-scale protocol for digital trust is an ambitious undertaking. Why did the ToIP Foundation take this path? Let’s start by looking at related efforts in this area.
Related protocols
This table summaries other well-known protocols that address various facets of digital trust:
| OpenID Connect (OIDC) | An authentication layer on top of the OAuth 2.0 authorization framework specified by the OpenID Foundation as a RESTful HTTP API using JSON as a data format. Supports basic user profile information access; optionalYeahHighlight features include encryption of identity data, discovery of OpenID providers, and session management. |
| OpenID for Verifiable Credentials (OID4VC) | A family of protocols from the OpenID Connect Working Group built on top of OIDC for issuance (OID4VCI) and presentation (OID4VP) of verifiable digital credentials, plus a wallet-based user authentication protocol (SIOP). |
| DIDComm | Specified by the DIDComm Working Group of the Decentralized Identity Foundation (DIF), DIDComm is a peer-to-peer secure messaging protocol in which the endpoints are specified by DIDs (decentralized identifiers). |
| TLS (Transport Layer Security) | A cryptographic protocol from the IETF best known for enabling secure HTTPS browser connections; also widely used in applications such as email, instant messaging, and voice over IP. Provides security, confidentiality, integrity, and authenticity through the use of X.509 digital certificates. |
| MLS (Message Layer Security) | Specified by the MLS Working Group of the IETF, MLS is a security layer for end-to-end encrypted messages in arbitrarily sized groups. Its security properties include message confidentiality, message integrity and authentication, membership authentication, asynchronicity, forward secrecy, post-compromise security, and scalability. |
| RCS (Rich Communications Services) | A text-based mobile messaging protocol specified by GSMA to replace SMS messages with a richer feature set including in-call multimedia. RCS does not natively support end-to-end encryption; Google added it using the Signal Protocol in their own implementation. Apple has said it will support RCS once GSMA standardizes end-to-end encryption. |
| Signal Protocol | A non-federated cryptographic protocol specified by the Signal Foundation that provides end-to-end encryption for voice and instant messaging conversations. The protocol combines the Double Ratchet Algorithm, prekeys, and a triple Elliptic-curve Diffie–Hellman (3-DH) handshake. |
| Matrix Protocol | An application layer communication protocol for federated real-time communication specified by the Matrix Foundation, it provides HTTP APIs for securely distributing and persisting messages in JSON format over an open federation of servers. It can integrate with standard web services via WebRTC to facilitate browser-to-browser applications. |
| DNSSEC | A suite of extension specifications from the IETF for securing data exchanged in the Domain Name System (DNS). The protocol provides cryptographic authentication of data, authenticated denial of existence, and data integrity, but not availability or confidentiality. |
| ISO/IEC 14443-4:2018 | A half-duplex block transmission protocol designed for a contactless environment, it defines the activation and deactivation sequence of the protocol. It is intended for use with other parts of ISO/IEC 14443 and is applicable to proximity cards or objects of Type A and Type B. |
Related cryptographic data structures
Protocols are not the only ingredient required for Internet-scale digital trust. This table summarizes some of the standard cryptographic data structures that have been developed:
| X.509 digital certificates | An ITU standard defining the format of the public key certificates used in many Internet protocols, including TLS, as well as digital signatures. An X.509 certificate binds an identity (a hostname, or an organization, or an individual) to a public key using a digital signature. A certificate is signed either by a certificate authority (CA) or self-signed. X.509 also defines certificate revocation lists and a certification path validation algorithm. |
| Encrypted/signed PDF files | Portable Document Format, originally developed by Adobe, became an ISO standard in 2008. A PDF file may be encrypted; PDF 2.0 defines 256-bit AES encryption as the standard but also defines how third parties can define their own encryption systems for PDF. ISO 32000-2 defines how PDF files may be digitally signed for secure authentication. |
| Verifiable digital credentials | With the emergence of digital wallets, multiple formats for cryptographically verifiable digital credentials have been developed, including the W3C Verifiable Credentials Data Model; ISO mDL/mDOC; IETF SD-JWTs; Hyperledger AnonCreds; and ToIP Authentic Chained Data Container (ACDC). |
| C2PA content credentials | The C2PA standards define a model for binding cryptographically verifiable provenance information to digital media content together with a model for evaluating the trustworthiness of that information. |
How and why is TSP different?
As the sections above show, many thousands of person-hours have been invested in protocols and cryptographic data structures designed to address the Internet’s multitude of security, confidentiality, and privacy issues. So why have the members of the ToIP Foundation spent four years developing TSP?
The fundamental reasons are summarized in this table:
| Minimalist design as a spanning layer for higher-layer protocols | The single most important design goal for the TSP—and the biggest differentiator from the protocols listed above (with the possible exception of DIDComm)—is the critical role of a spanning layer in a protocol stack. The reasons it must be “as simple as possible but no simpler” is explained at length in Principle #3 of the Design Principles for the ToIP Stack. The TSP does not include many of the features of the protocols above precisely because it is designed so those features can be provided in higher-level protocols. The benefit is that all of those higher-level protocols can be much simpler and more future-proof because they automatically inherit all the technical trust features achieved at the TSP layer. |
| Decentralized peer-to-peer architecture | By building on HTTP and RESTful APIs, the OpenID family of protocols are inherently Web-centric (client/server). The TSP does not make that architectural assumption. Like the IP protocol, it can work between any two peers across any kind of network or software architecture. |
| VIDs & DIDs | Like DIDComm, all TSP endpoints use cryptographically verifiable identifiers (VIDs) such as those defined by the W3C Decentralized Identifiers (DIDs) specification. VIDs not only support full decentralization, but they provide portability and cryptographic agility for lifetime relationship management. |
| Public Key Authenticated Encryption and Signature | TSP combines modern Public Key Authenticated Encryption and Public Key Signature to provide the strongest protection against both key compromise impersonation and sender impersonation. This is achieved by using either IETF RFC9180 HPKE (Hypbrid Public Key Encryption) defined Auth Mode primitives, or HPKE Base Mode or Libsodium Sealed Box primitives enhanced with an ESSR (Encrypt Sender Sign Receiver) pattern. |
| Payload agility | TSP uses the CESR text-binary dual encoding format that supports composability of both text and binary primitives—including JSON, CBOR, and MsgPak—in the same message. |
| Cryptographic agility | Another key feature of CESR is code tables for all types of cryptographic primitives. For example, it can transmit any of the cryptographic data structures listed above. This enables TSP ecosystems to standardize on precise signature and encryption algorithms yet still evolve them over time. |
| Transport independence | Although the name “Trust Over IP” suggests a dependence on the TCP/IP stack for transport, in fact a core design goal of TSP is to provide end-to-end authenticity, confidentiality, and metadata privacy entirely independent of the underlying transport protocol. |
What implementation projects have been announced?
In parallel with the first Implementers Draft, at next week’s Internet Identity Workshop #38 we will be announcing the first two TSP implementation projects—each one led by one of the primary authors of the TSP specification:
- A Rust open source implementation led by co-author Wenjing Chu is being proposed as a new project at the OpenWallet Foundation (OWF) sponsored by OWF Premier members Futurewei, Gen, and Accenture.
- A Python open source implementation is being developed by co-author Sam Smith and his colleagues at the Web of Trust GitHub community project.
If you are interested in contributing to either of these projects or starting your own, we welcome your collaboration. Just contact us via the ToIP contact page or GitHub.
What kind of feedback are we seeking on this draft?
As always, we would like feedback on the usual questions about any new protocol specification:
- Is the spec clear and understandable?
- Are there any missing sections?
- Are there places where more examples or illustrations would be helpful?
- Are there specific test vectors you would like to see added?
In addition, we are specifically looking for your feedback in the following areas:
- How would you imagine using the TSP? How can it enhance what you already have? What types of trust task protocols are you most interested in layering over the TSP?
- Does the TSP provide the baseline capabilities you need to support your planned trust task protocol(s)?
- Does the TSP enable your solution to be more decentralized?
- What types of VIDs do you plan to implement support for?
- What types of transport protocols do you intend to bind to?
- What cryptographic algorithms do you want or need to use?
- What problems are you trying to solve in your tech stack that are not addressed by existing solutions and can or should be addressed by TSP?
- Are there other protocols in development that we are not aware of that may conflict or complement TSP?
How can you provide feedback?
To review the specification:
- Github Pages version: https://trustoverip.github.io/tswg-tsp-specification
- Markdown version: https://github.com/trustoverip/tswg-tsp-specification
To make a comment, report a bug, or file an issue, please follow the ToIP Public Review Process on GitHub: