ToIP Trust Registry Query Protocol (TRQP) Specification Overview
- Drummond Reed
- Darrell O'Donnell
- Samuel Rinnetmäki
Important Links
Introduction
The ToIP Trust Registry Query Protocol (TRQP) is a simple read-only protocol developed by the ToIP Trust Registry Task Force that is often called “DNS for trust”. In other words, it is a lightweight protocol for making fast, efficient queries for authoritative information available in trust registries—authoritative sources of information about trust relationships. The purpose of this overview is to provide an understanding of the overall problem space and an explanation of the key concepts covered in the specification.
Digital trust ecosystems
“Browsers defined Web 1.0. Apps defined Web 2.0. Wallets will shape Web 3.0.”
— Sir Tim Berners-Lee, Inventor of the World Wide Web
The power of open standard digital wallets, now being implemented by governments, commercial vendors, and open source projects around the world, is that they can accept open standard digital credentials. These are widely referred to as “verifiable credentials” because they are digitally-signed containers of data that can be cryptographically-verified as authentic by the party accepting the credential—called the relying party or verifier.
The combination of issuers, holders, and verifiers of digital credentials—together with the governing body (aka governing authority) that specifies the content of the credentials and the policies for issuing, holding, and verifying them—is called a digital trust ecosystem as illustrated in figure 1:
Figure 1: The core roles in a credential-based digital trust ecosystem.
As figure 1 shows, a defining feature of a ToIP-compatible ecosystem is that it publishes a publicly-accessible governance framework so its policies are transparent to all participants—both within that ecosystem and across other ecosystems where those credentials may be of value. These policies also typically govern the operation of one or more trust registries for the ecosystem.
The role of trust registries
Once an ecosystem scales beyond a handful of issuers or verifiers, governing authorities need an efficient way to answer the question: “Who is authorized to do what within this ecosystem?” Examples of these types of queries:
Is hospital X authorised to issue health credential Y in ecosystem Z?
Is company X authorised to verify employment credential Y in ecosystem Z?
Is auditor X authorised to conduct security audit Y in ecosystem Z?
Is certification body X accredited to certify Y in ecosystem Z?
In addition to answering these questions, there is also the question of cross-ecosystem trust relationships, e.g., “Is ecosystem X recognized as a trust registry by ecosystem Z?”
In all these cases, the authoritative information required to respond to these queries is called an authority statement. A governing body has three options for publishing its authority statements:
Publish a single master file of all authority statements. If the governing authority digitally signs it and makes it available to everyone who needs it, any interested party can verify it is authentic.
Issue verifiable credentials to each governed party, where each VC asserts the authority statements governing that party. Each VC is signed by the governing authority as the issuer.
Operate a trust registry (aka trust list) from a verifiable endpoint where authority statements can be queried by any party who needs to verify them. This role of a trust registry and the typical interactions it is involved in are illustrated in figure 2:
Figure 2: The role of a trust registry in a digital trust ecosystem.
It is important to note that these three options are non-exclusive, i.e., all three can all deliver the same authority statements with the same cryptographic verifiability. However there are several advantages to using a trust registry:
Ease of access by all parties. Making authority statements available via a standard set of discoverable network endpoints makes it very easy for interested parties to query for precisely the verification information they need to know when they need to know it.
Support for dynamic, real-time updates. Unlike a single file that must be redistributed with each update, or individual verifiable credentials that must be revoked and reissued, authority statements in a trust registry can be updated in seconds. This means they can always reflect the current state of the ecosystem.
Discoverability within a network of trust registries. As ecosystems begin to multiply—just as Internet servers did or web servers did—network participants need an efficient way to locate and query the authoritative trust registry for the authority statement they need to verify.
What is in a trust registry?
The ultimate source of the authority statements in a trust registry is called the system of record. Many different types of systems of record already exist, each with their own ways of storing and organizing authority statement data: databases, directories, web servers, blockchains, etc.
In the end, the information contained in a system of record can be translated into this basic semantic format:
[authority] [assertion] [entity]
The authority and the entity are simply identifiers:
Authority is the Identifier of the authority making the authority statement.
In Web architecture, this is a URI.
In X.509 architecture, this is any of the CA identifiers supported by X.509 certificates.
In ToIP architecture, this is required to be a DID of the authoritative governance framework so it can be cryptographically verified as authentic.
Entity is the identifier of the entity that is the object of the authority statement.
In Web architecture, this is a URI.
In X.509 architecture, this is any of the certificate holder identifiers supported by X.509 certificates.
In ToIP architecture, this is required to be a DID of the entity so it can be cryptographically verified as authentic.
The assertion is the statement the authority is making about the entity. TRQP assertions are of three types:
Descriptions are metadata describing the entity.
Authorizations are actions the entity is authorized to take within a specified scope.
Recognitions are the scope of authority that one authority recognizes in another.
Depending on the type of the system of record, the authority and the assertion can be implicit. This is the case with a trust list such as the EU Trusted Lists. In this specific case, the trust registry data only needs to consist of a list of entities, because the authority is the EU Commission, and the authorization is implicit in the type of the trust list, e.g., credential issuer list, credential verifier list, auditor list, etc.
Trust lists have existed since the birth of the Internet. One is even stored on all computers that list a software browser’s trusted root certification authorities. Type “certmgr “ on Windows-based computers to access and the listing appears as shown in figure 3:
Figure 3: The trusted root registry on a Windows personal computer
Each certification authority listed in figure 3 has been approved by Microsoft as the OS vendor. When accessing any website on that computer, the browser checks the trust registry to determine whether the TLS certificate issued to that site chains up to a listed root certification authority. When it does not, a warning appears on the browser.
Trust registry networks
There are many parallels between the role of DNS for name servers and the role of TRQP for trust registries. Both protocols are designed to navigate across a network of servers to locate the authoritative endpoint for a particular query, and then perform a query and response with that endpoint.
In the case of DNS, the query is to translate a DNS name into a specified type of resource record (typically an IP address). In the case of TRQP, the query to discover or verify an authority statement.
Besides the type of records being queried, the other main difference between DNS and TRQP is the network topology. DNS networks are hierarchical, meaning they begin with a top-level domain (TLD) and navigate down a tree to a second-level domain, third-level domain, and so on. Hierarchical resolution of a typical DNS name query (for http://www.example.org ) is illustrated in figure 4:
Figure 4: How DNS scales by enabling domain name servers to delegate along a hierarchical name path.
TRQP networks also have hierarchical relationships, where one trust registry delegates to another trust registry just like the DNS name server delegation shown in figure 4. However in a TRQP network, other trust relationships are heterarchical. This means the authorities are peers—neither authority controls the other, but they can choose to recognize each other. Recognition can be unidirectional, i.e., ecosystem A recognizes ecosystem B, but ecosystem B does not recognize ecosystem A; or it can be bidirectional (mutual).
So, while DNS name paths traverse hierarchically down a domain name tree, TRQP trust chains may traverse laterally across ecosystems—with each being a peer of the others—before they reach an authoritative trust registry. Figure 5 illustrates how a TRQP trust registry network can support both heterarchical recognition relationships (blue arrows) and hierarchical delegation relationships (red arrows).
Figure 5: Trust registry networks can support both heterarchical and hierarchical relationships.
TRQP network components
The name “Trust Registry Query Protocol” comes from the fact that TRQP is a read-only protocol—the trust registry equivalent of the DNS protocol for name server queries and responses. As with DNS, the three other classic CRUD operations (create, update, delete) are handled by other protocols or APIs that depend on the system of record.
A TRQP network consists of the four main components illustrated in figure 6:
Figure 6: The four main components in a TRQP network
TRQP consumers
TRQP consumers are the devices—either local devices at the edge of the network or servers within the network—which make TRQP queries as part of a verifiable credential workflow. They are the TRQP equivalent of DNS resolvers.
TRQP endpoints
A TRQP endpoint is a network service endpoint that responds to TRQP queries. TRQP endpoints have a standard DID service endpoint type as defined in the TRQP specification.
TRQP bridges
A TRQP bridge is needed when the underlying system of record (see below) is not a native TRQP trust registry, but another type of trust list, directory, federation, blockchain or PKI. In this case, the job of the TRQP bridge is to translate the TRQP query into a query to which the native system of record can respond. The bridge then translates that native response back into a TRQP response to return to the TRQP consumer.
Systems of record
A system of record is the authoritative source for the ecosystem’s authority statements. TRQP is completely agnostic to the underlying system of record. As long as a TRQP bridge can be built to translate a TRQP query into a language the system of record can understand, TRQP can interoperate with any system of record.
The TRQP Specification
The TRQP Specification consists of three major parts:
The core protocol defines the data model for TRQP queries and responses. The data transmitted by a consumer making a TRQP query and by a TRQP endpoint responding to that query should be consistent regardless of any specific transport protocol binding.
The core query vocabulary is a set of standard verbs used for description, authorization, and recognition queries to maximize interoperability of TRQP across ecosystems.
The RESTful binding specifies how TRQP queries and responses work over HTTPS, including the security and privacy considerations associated with that binding.
Implementation considerations
The TRQP Specification concludes with a section offering advice to implementers. Per the analogy to DNS, many of these considerations are similar to setting up a DNS name server or DNS zone.
TRQP endpoint setup
At a minimum, for TRQP consumers to begin using a new TRQP endpoint using the RESTful binding, the governing authority will need to publish the TRQP service endpoint(s).
If the trust registry is serving a specific ecosystem or a cluster of ecosystems, it may also require an ecosystem-specific query vocabulary. This vocabulary can be published in the ecosystem or cluster governance framework so developers and integrators can ensure their software supports the requirements of that specific ecosystem or cluster.
TRQP network setup
When multiple ecosystems or ecosystem clusters want to be able to interoperate in a TRQP network, they will typically need to agree on:
The set of verifiable identifier types that need to be supported by the TRQP consumers and endpoints on the network in order to support discovery and verification of TRQP authorities and entities.
The set of trust registries (or metaregistries) that can serve as starting points for TRQP recognition queries within the network.
The set of network-specific query vocabulary (if any) that enables full interoperability of TRQP queries within that network.
These requirements can be published in a TRQP network profile. This profile—typically in conjunction with a conformance test suite (CTS)—can be used by developers and integrators of TRQP consumers and endpoints to ensure their TRQP software implementations are interoperable with the network.