Internet Identity Workshop—Mountain View: The Trust Registry Task Force (TRTF) at Trust Over IP (ToIP) today announced Public Review Draft 01 of its Trust Registry Query Protocol Specification V2.0. We invite feedback from architects and developers of trust registry client software, backend services, and bridges to different systems of record. Instructions for commenting are at the end of this post.

What problem do trust registries solve?

The power of open standard digital wallets, such as those now being implemented in the EU, Canada, Bhutan, and other countries, is that they can accept open standard digital credentials—widely referred to as “verifiable credentials” because they are digitally signed by the issuer so they can be cryptographically verified by the party accepting the credential (called the relying party or verifier).

However, it is not enough for the relying party to simply verify the public key of the issuer. The relying party also needs to know the issuer is authorized to issue this type of credential. For example, to verify a State of California mobile driving license (mDL), the relying party needs to first verify that the issuer is the real California Department of Motor Vehicles.

Now multiply that by 50 U.S. states that could issue mDLs—times hundreds more mDL issuers in other countries around the world—times thousands of other types of digital credentials that can be issued for all kinds of digital trust use cases. Suddenly it becomes clear that we need a simple, fast, secure way to verify trusted issuers.

The need for efficient trust verification does not stop with issuers. For data protection reasons, the EU eIDAS 2.0 legislation also requires “verifying the verifier” (i.e., checking to make sure the verifier is authorized to request specific types of personal data from an EUDIW wallet holder).

Both cases can be addressed by a network service called a trust registry (also called—especially in the EU—a trust list). A trust registry is a system of record that contains the authoritative information that relying parties need to make trust decisions. Many such systems of record already exist. For example, almost any legal jurisdiction has a method of registering and licensing all types of businesses and professionals (CPAs, lawyers, doctors, professional engineers, etc.) And there are hundreds of registries of accredited institutions—universities, hospitals, insurance companies, nursing homes, etc.

Why do we need a Trust Registry Query Protocol?

As a distributed global network of trust registries starts emerging, we need a standard protocol to query them just as much as we needed standard protocols to create the Internet or the Web. That’s the purpose of the Trust Registry Query Protocol (TRQP), a simple, read-only protocol—often described as “DNS for trust”—that allows anyone to query authoritative sources of trust data, regardless of the underlying system of record.

TRQP enables a trust registry to efficiently answer queries like:

• Is hospital X authorized to issue health credential Y in ecosystem Z?
• Is company X authorized to verify employment credential Y in ecosystem Z?
• Is auditor X authorized to conduct security audit Y in ecosystem Z?
• Is certification body X accredited to certify Y in ecosystem Z?

For a complete overview of TRQP architecture, see this description on the ToIP wiki.

What is new is TRQP v2.0?

TRQP v2.0 has made the following refinements to improve clarity, extensibility, and real-world applicability:

1. Enhanced introductory material
   1. New definitions section.
   2. New high-level architecture diagrams.
   3. Deeper explanation of key concepts, including TRQP consumers, TRQP endpoints, and how TRQP bridges can adapt to different systems of record (e.g., OpenID Federation, X.509, blockchains) without changes to that existing infrastructure.
   4. Separation of the roles of ecosystem governing authority and trust registry operator.
2. Separation of the core specification from bindings that specify how to implement TRQP over specific transport protocols, starting with REST/HTTPS.
3. Consolidated requirements for identifiers and identifier verification, including ecosystem IDs, entity IDs, authority IDs, and entity IDs.
4. More tightly defined data model and query vocabulary for four categories of authority statements:
   1. Authorization (e.g., issuing VCs, verifying VCs, auditing, etc.)
   2. Recognition of one ecosystem by another
   3. Delegation of authority from one authority to another
   4. Description (i.e., metadata describing any entity {public keys, verification metadata, verifiable credentials, etc.})
5. A new section on TRQP error handling.
6. Refactored Swagger/OpenAPI-based REST Binding
   1. Makes TRQP integration straightforward for developers.
   2. Includes definitions of endpoints, expected responses, and error handling.

You can explore the full API definition here: TRQP Swagger/OpenAPI Documentation

Your Feedback Matters

We invite trust registry operators, ecosystem architects, wallet developers, credential issuers, verifiers, and other stakeholders to review and provide feedback on TRQP before v2.0 goes final. Please help us ensure TRQP is:

• Practical and usable for real-world ecosystems.
• Flexible enough to accommodate different underlying systems of record and ecosystem governance models.
• Comprehensive without being overly complex.

To provide feedback:

1. Read the TRQP v2.0 Draft Specification: TRQP v2.0 HTML Spec
2. Explore the REST API (Swagger): GitHub - TRQP Specification and API
3. Join the conversation and share feedback: GitHub Discussions and Issues