Trust over IP (ToIP) Foundation

ToIP separates digital trust into two distinct, parallel layers: a Governance Stack and a Technology Stack. The Governance Stack defines the human rules, business policies, and legal frameworks that govern a trust ecosystem. The Technology Stack defines the cryptographic protocols, data models, and communication mechanisms that enforce those rules technically. This separation allows a single governance framework to be implemented across multiple underlying technologies, and conversely, a single technology platform to support multiple governance regimes. The two stacks are bound together at the Trust Spanning Protocol layer, which acts as the interface contract between human intent and machine execution.

Mirroring the governance hierarchy, the Technology Stack provides the concrete technical specifications at each corresponding level:

• Level 1: Utility Layer — The decentralized public key infrastructure (DPKI) and verifiable data registries, such as distributed ledgers or the KERI protocol, that anchor cryptographic trust without a central authority.
• Level 2: Credential Layer — The W3C Verifiable Credential data model and specific signature schemes like BBS+ or AnonCreds that enable tamper-proof, privacy-respecting digital credentials.
• Level 3: Agent Layer — The software components, such as Digital Identity Wallets and enterprise agents, that manage keys and credentials on behalf of a DID subject, communicating via the DIDComm v2 protocol.
• Level 4: Application Layer — The user-facing applications and services that consume verifiable credentials to make trust decisions, such as a border control kiosk or a bank's loan origination system.

ToIP mandates a shift from centralized, federated identity models to a decentralized by default architecture. This principle is embodied in the use of Decentralized Identifiers (DIDs) which have no dependency on a central registration authority. The architecture supports multiple DID methods, allowing an ecosystem to choose the underlying verifiable data registry that fits its governance model—whether a public blockchain, a permissioned ledger, or a ledger-independent system like KERI. This design eliminates single points of failure, prevents vendor lock-in, and ensures that the identity owner remains at the center of control, aligning directly with the principles of Self-Sovereign Identity (SSI).

A core design goal of the ToIP stack is to mathematically enforce data minimization. The architecture natively supports advanced cryptographic techniques that allow a holder to prove a claim without revealing the underlying raw data:

• Selective Disclosure: A holder can share only the specific attributes required for a transaction, such as proving they are over 18 without revealing their exact birthdate.
• Zero-Knowledge Proofs (ZKPs): Using signature schemes like BBS+, a holder can derive a proof that a verifier can cryptographically validate without the holder ever revealing the original signed data or a correlatable identifier.
• Peer-to-Peer Communication: The DIDComm protocol ensures that credential exchanges happen over encrypted, off-ledger channels directly between parties, preventing data brokers or intermediaries from observing the transaction.

The dual-layer architecture separating governance from technology across four levels:

• Layer 1: Public Utilities — Ledgers like Hyperledger Indy for DID anchoring
• Layer 2: Peer-to-Peer Protocols — DIDComm for secure agent communication
• Layer 3: Credential Exchange — W3C Verifiable Credential issuance and verification
• Layer 4: Application Ecosystems — Digital trust ecosystems like the Good Health Pass

The non-technical half of ToIP that defines rules, policies, and accountability:

• Governance Frameworks — Legal agreements governing a trust ecosystem
• Trust Assurance Frameworks — Criteria for assessing conformance
• Credential Schemas — Canonical data structures for specific credential types
• Trust Registries — Authoritative lists of accredited issuers and verifiers This layer answers: Who sets the rules, and how is compliance enforced?

The secure, asynchronous messaging protocol native to the ToIP stack. DIDComm enables:

• Encrypted peer-to-peer communication between DID controllers
• Authentication via decentralized keys, not centralized servers
• Routing through mediators for offline or mobile agents
• Protocol extensibility for issuing credentials, requesting proofs, and negotiating trust DIDComm is the transport layer that makes decentralized trust actionable.

A global consortium of over 400 organizations driving the specification work:

• Contributor Members: Accenture, IBM, Mastercard, esatus
• Government Adopters: British Columbia's OrgBook BC, Ontario's Digital Identity
• Technology Implementers: Evernym (acquired by Avast), Trinsic, Indicio
• Standards Bodies: Liaisons with W3C, ISO, Decentralized Identity Foundation The Foundation publishes Recommendations and Guides for implementers.

The three-party model at the heart of ToIP trust relationships:

• Issuer — Entity that asserts claims and issues verifiable credentials
• Holder — Subject who controls their credentials in a digital wallet
• Verifier — Relying party that requests and cryptographically verifies proofs Trust is established without direct contact between Issuer and Verifier. The Holder mediates the exchange, enforcing selective disclosure and consent.

A ToIP specification for streaming verifiable data beyond static credentials:

• Enables ongoing attestations (e.g., real-time sensor data, audit logs)
• Uses chained key event logs for cryptographic continuity
• Supports selective disclosure of individual data points within a stream
• Designed for IoT, supply chain telemetry, and continuous compliance monitoring ACDC extends the ToIP model from point-in-time credentials to continuous trust.