On 14 November 2022, the ToIP Foundation announced the release of the first public review draft of the ToIP Technology Architecture Specification V1.0. This specification represents over a year’s work by the ToIP Technology Architecture Task Force to define the technical requirements for each of the four layers of the ToIP stack—the centerpiece of the ToIP Foundation’s work to develop an interoperable architecture for decentralized digital trust.
In this post, we will dive deeper into one particular layer — Layer 2 — to explain the special role of the ToIP Trust Spanning Protocol and why it is the keystone to achieving large-scale interoperability.
But First — Some Context
It may first be helpful to understand the overall context of this work. The ToIP Foundation recently published a new document for this very purpose, Evolution of the ToIP Stack, that contains the following diagram:
Here is a summary of the purpose of each of the four development stages:
- Design Principles. Before we could dive into the design of the ToIP stack itself, we needed to agree on the principles governing the design. A six month effort produced Design Principles for the ToIP Stack V1.0—a document we highly recommend for a much deeper understanding of the problem space.
- Technical Architecture. Based on the Design Principles, we next needed to come to consensus on the architectural requirements of the overall system and the requirements for each of the four layers in the stack of the endpoints. This year-long effort resulted in the ToIP Technology Architecture V1.0 Specification, just released for public review.
- Component Specifications. The ToIP Technology Architecture Specification cannot be implemented directly by itself—it only specifies requirements that must be met by a set of component specifications. Each component specification is a building block that can then be assembled into a complete implementation of the ToIP technology stack.
- Interoperability Testing. Once a sufficient set of component specifications are ready, stakeholders in digital trust ecosystems can develop ToIP interoperability profiles against which test suites can be written to provide objective measurements of functional interoperability.
As Figure 1 indicates, we are already 2.5 years into the process and just reaching the end of the first iteration of stage 2. Note that we expect iteration at each stage, i.e., as we gain experience at higher stages, we expect to make minor adjustments to the foundational documents.
Given that we expect the ToIP Technology Architecture Specification V1.0 to be finalized in the first quarter of 2023, we are now ready to move forward into the component specification stage. As the Evolution of the ToIP Stack explains, most of these will not be developed by the ToIP Foundation — they are specifications that either already exist or are in progress at other standards development organizations such as DIF, W3C, IETF, ISO, and so on.
One exception is the ToIP Trust Spanning Protocol—the one and only protocol required at ToIP Layer 2. Since the requirements for this protocol have only just been published, no other standards development organization currently has it as a focus. The purpose of this article is to explain the unique role this protocol plays in the ToIP stack and how we propose to proceed with its development.
The Hourglass Model
Section 6.2 of the ToIP Technology Architecture Specification explains that the design of the ToIP stack is based on the same core design principles as the Internet’s TCP/IP stack, and in particular the principle known as the Hourglass Model. Here is the one sentence summary of this principle from section #3 of the Design Principles for the ToIP Stack V1.0:
In a layered protocol architecture, the most successful design takes an hourglass shape where a single “spanning layer” in the middle connects a family of higher-level application-facing protocols with a family of lower-level transport protocols.
Figure 2, from an August 2001 presentation by Steve Deering of Cisco, illustrates how the TCP/IP stack implements the Hourglass Model.
The spanning layer in the TCP/IP stack is the Internet Protocol (IP), which defines the addressing system required to identify and connect any two Internet-connected devices. The spanning layer in the ToIP stack has the same goal except the purpose is to establish a trust relationship, i.e., a communications relationship whose authenticity can be cryptographically verified by both sides. Figure 3 illustrates how the hourglass design applies to the four layers of the ToIP stack.
Appendix B of the ToIP Technology Architecture V1.0 Specification includes a functional view of the ToIP stack (Figure 4) that goes into greater detail about the kinds of functions required above and below the Trust Spanning layer. Layer 1 (Trust Support) needs the services for storing and processing the cryptographic key material and encrypted data that is required for secure communications over Layer 2. Layer 3 (Trust Tasks) is a growing family of protocols that can be developed to automate common functions required in digital trust relationships.
Requirements for the ToIP Trust Spanning Protocol
Given the starring role of the ToIP Trust Spanning Protocol, it should be no surprise that it is the target of 60% of the requirements in the ToIP Technology Architecture V1.0 Specification. Of the 30 requirements in the specification (all aggregated in Appendix A), 18 are for Layer 2. They are included in Table 1 below for quick reference.
| Req # | Requirement |
| L2.1 | A ToIP Endpoint System MUST communicate with another ToIP Endpoint System using the ToIP Trust Spanning Protocol. |
| L2.2 | A ToIP identifier MUST be unique within the context in which it is used for identification. |
| L2.3 | A ToIP identifier MUST be a verifiable identifier, i.e., verifiably bound to at least one set of cryptographic keys discoverable via an associated discovery protocol. |
| L2.4 | A ToIP identifier SHOULD be a decentralized identifier, i.e., a verifiable identifier that does not require registration with a centralized authority. |
| L2.5 | A ToIP identifier SHOULD be an autonomous identifier, i.e., a decentralized identifier that is self-certifying and fully portable. |
| L2.6 | A ToIP identifier SHOULD support rotation of the associated cryptographic keys for the lifetime of the identifier. |
| L2.7 | A ToIP identifier MAY also support rotation to an entirely different ToIP identifier that can be cryptographically verified to be a synonym of the original ToIP identifier. |
| L2.8 | A ToIP identifier SHOULD support the ability to: a) associate the identifier with the network address of one or more ToIP Systems that can deliver to one or more Endpoint Systems under the locus of control of the ToIP identifier controller, and, b) if desired by the controller, enable that association to be discoverable. |
| L2.9 | The ToIP Trust Spanning Protocol specification MUST define how to construct and format messages that are cryptographically verifiable to have the following four properties: (1) Authenticity: the message was sent from a sender who has control over the ToIP identifier. (2) Integrity: the contents of the message transmitted by the sender are received by the recipient without modification. (3) Confidentiality: the contents of the message are only accessible by authorized parties. (4) Privacy: the contents of the message are bound to conditions of usage agreed to by the parties. |
| L2.10 | In a ToIP Endpoint System, an implementation of the ToIP Trust Spanning Protocol MUST support authenticity and integrity. |
| L2.11 | In a ToIP Endpoint System, an implementation of the ToIP Trust Spanning Protocol MAY support confidentiality and privacy. |
| L2.12 | The ToIP Trust Spanning Protocol MUST enable the composition of higher-level Trust Task Protocols (such features as co-protocols). |
| L2.13 | The ToIP Trust Spanning Protocol MUST support extensible message schema. |
| L2.14 | The ToIP Trust Spanning Protocol MUST support resolution of ToIP identifiers to: a) the network addresses of receiving Endpoint Systems, and b) any required cryptographic keys. |
| L2.15 | The ToIP Trust Spanning Protocol MUST support transport of messages via ToIP Layer 1 interfaces. |
| L2.16 | The ToIP Trust Spanning Protocol MUST support delivery of messages to the Layer 2 interface of the Endpoint System of the ultimate receiver of the message. |
| L2.17 | The ToIP Trust Spanning Protocol MUST support delivery of messages via Intermediary Systems. |
| L2.18 | The ToIP Trust Spanning Protocol MUST support confidentiality with regard to the metadata required for message routing. |
ToIP Identifiers
The astute reader will notice that 7 of these 18 requirements apply to ToIP identifiers, the term the spec uses for the cryptographically verifiable identifiers needed to establish the ToIP trust spanning layer. The complete taxonomy of ToIP identifiers is shown in Figure 5:
From broadest to narrowest, the three subclasses of ToIP identifiers are:
- Verifiable identifiers (VIDs) include any identifier bound to at least one cryptographic key pair so that control over the identifier can be cryptographically verified. HTTPS URLs backed by X.509 digital certificates are one example of a VID (typically one that uses a domain name based on a centralized DNS registry).
- Decentralized identifiers (DIDs) are VIDs that: a) do not require a centralized registry, b) provide a standard mechanism for resolution, and c) permit dynamic discovery of associated network service endpoints (such as an endpoint that supports the ToIP Trust Spanning Protocol). See the W3C DID Spec Registries for an extensive list of DID methods that implement the W3C Decentralized Identifiers (DIDs) 1.0 specification.
- Autonomous identifiers (AIDs) are DIDs generated algorithmically from a crypto- graphic key pair in such a way that they are self-certifying, i.e. the binding with the public key can be verified without the need to consult any external blockchain or third party. KERI is an example of a decentralized identity technology based entirely on AIDs.
ToIP identifiers are essential to the ToIP Trust Spanning Protocol for the same reason that IP addresses are essential to the IP protocol: they provide the new form of address required to achieve a universal spanning layer. In the case of the IP protocol, the spanning layer enables data to flow between any two endpoints regardless of their local network domain. In the case of the ToIP Trust Spanning Protocol, the spanning layer enables cryptographically verifiable data to flow between any two endpoints regardless of their local trust domain.
Forerunners for the ToIP Trust Spanning Protocol
As DIDs and AIDs emerged, they quickly catalyzed interest in new protocols that used the unique new properties of these identifiers to establish secure communications channels. Table 2 lists the three best-known of these protocols:
| Protocol | Host | Primary Specification |
| DIDComm V2 | DIF | https://identity.foundation/didcomm-messaging/spec/ |
| KERI / CESR | ToIP / DIF / IETF | https://github.com/WebOfTrust/ietf-keri |
| DWN (Decentralized Web Node) | DIF | https://identity.foundation/decentralized-web-node/spec/ |
Table 2: Protocols designed explicitly to work with verifiable identifiers
- DIDComm takes its name directly from the concept of general-purpose “DID-to-DID communications. DIDComm V1 originated at Hyperledger Aries, then as interest grew, a DIDComm working group was established at the Decentralized Identity Foundation. DIDComm V2 was released in July 2022.
- KERI (Key Event Receipt Infrastructure), which uses CESR (Composable Event Streaming Representation), is currently being developed by a GitHub community that is preparing Internet Drafts for submission to IETF. KERI focuses on providing the robust key management necessary to secure authentic connections between any two AIDs.
- DWN (Decentralized Web Node) is, to quote the spec, “a data storage and message relay mechanism entities can use to locate public or private permissioned data related to a given DID.” DWN is a work item of the DIF Secure Data Storage Working Group. Although DWN is more data-oriented than either DIDComm or KERI, it too specifies a message-based protocol for communicating with a DID-identified endpoint.
In addition to these three general-purpose secure messaging protocols that are clearly relevant to ToIP Layer 2, it is worth pointing out another set of protocols that have been developed specifically for issuing and presenting digitally verifiable credentials. Although from a ToIP layering standpoint, these protocols are all primarily Layer 3 (Trust Task) protocols, some of them include some Layer 2 functions for the simple reason there has not been any clearly defined Layer 2 protocol yet. Table 3 lists several of the most popular:
| Protocol | Host | Primary Specification |
| OIDC4VC | OpenID Foundation | https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html https://openid.net/specs/openid-4-verifiable-presentations-1_0.html |
| Hyperledger Aries Aries Interop Profiles | Hyperledger | https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0302-aries-interop-profile#aries-interop-profile-version-20 |
| VCAPI | W3C CCG | https://github.com/w3c-ccg/vc-api/ |
| CHAPI | W3C CCG | https://w3c-ccg.github.io/credential-handler-api/ |
| ISO mDL (currently local exchange only) | ISO | https://www.iso.org/obp/ui/#iso:std:iso-iec:18013:-5:ed-1:v1:en |
Table 3: Protocols designed for issuance or presentation of digital credentials
We mention all of these protocols (and undoubtedly there are others) for two reasons:
- All of these protocols may have something to contribute to the design of the ToIP Trust Spanning Protocol. All of them enable the exchange of secure and privacy-respecting content between endpoints.
- None of these protocols, as currently specified, meet all the requirements of the ToIP Trust Spanning Protocol. While some may be very close, none were explicitly designed to function as a spanning layer protocol—a protocol that by definition must be, to paraphrase Einstein, “as simple as possible but no simpler”.
The ToIP Trust Spanning Protocol Task Force
The fact that such strong candidate protocols already exist has three key implications for development of the ToIP Trust Spanning Protocol:
- This work does not need to “start from scratch”—or anywhere near it. Rather it can focus immediately on what can be learned/inherited from these existing protocols—and especially on what can be removed from them (and put into a Layer 3 trust task protocol).
- This work can benefit enormously from the participation of the architects of these other protocols. These experts have already poured several years of their lives into designing protocols that implement a superset of the functionality needed by the ToIP Trust Spanning Protocol. Our hope is that with their help, we can achieve consensus relatively quickly about the subset of features that are absolutely essential.
- The simpler the protocol, the faster we can have multiple implementations. By definition, a spanning protocol needs to be adopted very widely. The faster we can show multiple interoperable implementations, the faster we can kick start adoption.
For all these reasons, the ToIP Technology Stack Working Group launched the Trust Spanning Protocol Task Force (TSPTF) on Wednesday, January 18. You can listen to a Zoom recording of the first meeting.
The TSPTF will now begin holding pairs of meetings on Wednesdays —one for NA/EU time zones at 08:00-09:00 PT / 16:00-17:00 UTC and one for APAC time zones at 18:00-19:00 PT / 02:00-03:00 UTC. For exact dates and meeting logistics of all ToIP meetings, see the ToIP Calendar.
A Collaborative, Multi-Organizational Effort
The most important principle of this work is that it should be as open and inclusive as possible. The whole point of a trust spanning protocol is to enable a new trust ecosystem consisting of interoperable trust applications, where those trust applications remain independent of the underlying trust infrastructure that the trust spanning protocol connects. So for this work in particular we want to involve all the other non-profit orgs and SDOs in our space: DIF, Hyperledger, W3C, IETF, ISO, IEEE, and any other stakeholders in decentralized digital trust infrastructure.
To this end, Daniel Hardman, co-chair of the DIF DIDComm Users Group (DUG) and now co-lead of the TSPTF, held a special meeting of the DUG on 09 January to discuss the topic of multi-stakeholder collaboration. Over 40 members of the decentralized identity and trust ecosystem attended. We recommend listening to the Zoom recording of the DUG special meeting and/or reviewing Daniel’s slides to understand his specific recommendations for how we can all collaborate more successfully in 2023.