Loading vLEI.wiki
Fetching knowledge base...
Fetching knowledge base...
This comprehensive explanation has been generated from 90 GitHub source documents. All source documents are searchable here.
Last updated: October 7, 2025
This content is meant to be consumed by AI agents via MCP. Click here to get the MCP configuration.
Note: In rare cases it may contain LLM hallucinations.
For authoritative documentation, please consult the official GLEIF vLEI trainings and the ToIP Glossary.
A protocol architecture that uses verifiable identifiers (VIDs) to cryptographically sign and verify every message transmitted across the internet, creating a universal spanning layer for trust that operates independently of specific platforms or trust domains.
The Trust Spanning Protocol (TSP) represents a fundamental architectural approach to solving the internet's missing security layer by creating a universal protocol that spans across all trust domains and applications. TSP leverages verifiable identifiers (VIDs) to provide cryptographic signing and verification for every message transmitted, establishing what is termed a "spanning layer" analogous to how IP serves as the spanning layer for network protocols.
The core principle of TSP is that it operates as a minimal interoperability layer that enables endpoints to establish and maintain cryptographic trust relationships over untrusted networks. Unlike platform-specific trust systems (Facebook, Google, blockchain networks), TSP provides a horizontal layer that works across all platforms, creating what the specifications call a "trust spanning layer" that unifies the fragmented internet trust landscape.
TSP's scope is deliberately constrained to three essential security properties: authenticity (cryptographic verification of message integrity and sender/receiver identity), confidentiality (end-to-end encryption ensuring only intended recipients can read messages), and metadata privacy (protection of communication patterns and participant identities). This minimalist approach follows the principle of "minimally sufficient means" - providing exactly what is necessary for trust relationships without unnecessary complexity.
The need for TSP emerges from a fundamental flaw in the original Internet Protocol design: the absence of a built-in security layer. As documented in the KERI specifications, the IP packet header includes a source address field that can be undetectably forged by any intermediary, meaning recipients cannot ascertain whether packets were sent by imposters. This architectural deficiency has required security to be "bolted on" through identity system overlays like DNS/Certificate Authority (CA) systems.
Traditional approaches to internet security have relied on where trusted third parties (Certificate Authorities) maintain mappings between identifiers and cryptographic keys. This creates several problems:
Implementations must properly manage verifiable identifiers (VIDs) with distinction between:
Verification semantics are VID-type-dependent. For KERI AIDs, this means resolving the KEL and verifying the current key state. For DID:WEB, this means fetching and validating the DID document.
TSP requires specific cryptographic algorithms:
Implementations should separate cryptographic operations (seal/open) from transport mechanisms. The high-level AsyncSecureStore API handles both, while the low-level SecureStore API provides seal/open methods for custom transport integration.
Intermediary servers should implement message buffering for offline recipients, though no guaranteed retention period is required. Buffer management strategies should consider:
Implementing nested and routed modes requires:
Key performance considerations:
The concept of a "spanning layer" comes from the internet's successful hourglass model architecture, where IP serves as the narrow waist that enables diverse lower-layer network technologies to support diverse upper-layer applications. TSP applies this proven architectural pattern to the trust domain.
TSP is deeply integrated with KERI (Key Event Receipt Infrastructure) as its foundational identity and key management system. KERI provides the cryptographic primitives and verifiable data structures that enable TSP's trust spanning capabilities.
TSP uses KERI's autonomic identifiers (AIDs) as its verifiable identifiers. These are self-certifying identifiers that are cryptographically derived from public keys, eliminating the need for trusted third-party bindings. The self-certifying property means the identifier itself proves control authority through cryptographic verification.
KERI's key event logs (KELs) provide the verifiable data structure that maintains trust across key rotations. Each KEL is an append-only, cryptographically chained log of key management events that proves the current authoritative key state. TSP leverages this to maintain trust relationships even as keys are rotated for security.
KERI's pre-rotation mechanism provides TSP with post-quantum security guarantees. By committing to next rotation keys via cryptographic digests before current keys are exposed, the system maintains security even if current cryptographic algorithms are broken by quantum computers.
TSP benefits from KERI's duplicity detection mechanisms, which make any attempt to create conflicting versions of key event logs evident. This provides ambient verifiability - the ability for any party to detect malicious behavior anywhere in the system.
TSP implements a three-layer architecture that separates concerns:
This separation enables TSP to work with any transport mechanism below while supporting any trust-requiring application above, fulfilling its role as a true spanning protocol.
TSP implements two distinct message security approaches:
Non-Confidential Messages: Signed using Ed25519 digital signatures, providing authentication and integrity without encryption. This supports public broadcast scenarios where authenticity matters but confidentiality doesn't.
Confidential Messages: Encrypted using HPKE-Auth (Hybrid Public Key Encryption with Authentication) as defined in RFC 9180, with specific configuration:
This achieves what cryptographers call "strong receiver-unforgeability under chosen ciphertext" (RUF-CTXT), providing both confidentiality and non-repudiation.
TSP supports three operational modes with progressively stronger privacy guarantees:
Direct Mode: Messages are exchanged directly between parties using publicly known VIDs. This provides confidentiality and authenticity but limited privacy since the communication relationship is observable.
Nested Mode: Messages are exchanged as the payload of another TSP message using non-publicly known VIDs. This creates a two-layer identifier structure where inner identifiers are encapsulated within outer identifier envelopes, obscuring the actual communicating parties.
Routed Mode: Messages are routed through intermediaries to hide the fact that two parties are communicating. This establishes nested communication lines between all involved parties and sends messages that span across these nested channels, providing the strongest privacy guarantees.
TSP uses CESR (Composable Event Streaming Representation) for encoding cryptographic primitives. CESR provides dual text/binary encoding with the critical composability property - the ability to convert concatenated primitives between text and binary domains without loss. This enables efficient streaming while maintaining human-readable debugging capabilities.
TSP enables the creation of a universal trust infrastructure that spans all internet applications. Instead of each platform maintaining its own isolated trust system, applications can leverage TSP as a common trust layer. This is analogous to how all internet applications leverage IP as a common network layer.
TSP implements true zero-trust principles where "it's much easier to protect one's private keys than to protect everyone else's internet infrastructure." By making trust verification end-to-end and cryptographically verifiable, TSP eliminates reliance on intermediary infrastructure security.
TSP solves the platform lock-in problem by providing a protocol that works across different trust domains. A credential issued in one system can be verified in another system as long as both support TSP, enabling true interoperability.
Through its nested and routed modes, TSP enables privacy-preserving communication patterns that protect metadata and communication relationships. This addresses surveillance concerns while maintaining strong authenticity guarantees.
TSP's intermediary server architecture enables scalable message routing for endpoints that cannot maintain public addresses due to firewall restrictions. Intermediaries route messages using VIDs while maintaining end-to-end encryption and authentication.
Performance: TSP's cryptographic operations (signing, encryption, verification) introduce computational overhead. Benchmarks show approximately 2,844 seal-open pairs per second on commodity hardware, which is suitable for most applications but may be limiting for extremely high-throughput scenarios.
Complexity: Implementing TSP correctly requires understanding of cryptographic primitives, key management, and the KERI protocol stack. The learning curve is steeper than traditional authentication systems.
Infrastructure Requirements: While TSP eliminates reliance on trusted third parties for security, it still requires infrastructure for message routing (intermediaries) and identifier resolution (DID servers). However, this infrastructure doesn't need to be trusted for security - only for availability.
Privacy vs. Authenticity Trade-off: The PAC Theorem (Privacy, Authenticity, Confidentiality) states that a system can achieve any two of these properties to the same degree, but not all three. TSP prioritizes authenticity and confidentiality, with privacy as a third property that requires additional mechanisms (nested/routed modes) and involves trade-offs.
Verifiable Credentials: TSP provides the secure communication layer for ACDC (Authentic Chained Data Container) credential exchange, enabling privacy-preserving presentation of credentials with cryptographic proof of authenticity.
Supply Chain Tracking: TSP enables secure, verifiable communication between supply chain participants, with each message cryptographically signed and verifiable back to the originating entity.
IoT Device Communication: TSP's support for resource-constrained environments (through CESR's compact encoding) makes it suitable for IoT scenarios where devices need to communicate securely.
AI Agent Communication: The TMCP (TSP x MCP) integration demonstrates TSP's applicability to securing communications between AI agents and servers, providing verifiable attribution of AI-generated content.
Cross-Border Business Verification: TSP enables organizations to verify each other's credentials and identities across jurisdictional boundaries without relying on centralized authorities, supporting the vLEI (verifiable Legal Entity Identifier) ecosystem.
TSP represents a fundamental shift in how internet trust infrastructure is architected, moving from platform-specific, centrally-managed trust systems to a universal, cryptographically-verifiable spanning layer that enables true interoperability while maintaining strong security and privacy properties.
TSP implementations should integrate with: