Why Trust a Credential Issuer? Trust Registries, TRQP, and Public Implementations

Introduction

Someone presents a digital credential that says they are a doctor. Its signature checks out, but the issuer is an organization you have never heard of. Would that be enough to book a consultation?

A valid signature does not establish the issuer's authority to certify medical qualifications. The same problem arises with university degrees, training certificates, and professional credentials: a verifier needs a reason to accept what the issuer says.

This article develops an earlier Zenn article on trust registries and adds public implementation examples. The specifications and project documentation were checked on September 29, 2026. The implementation descriptions below are based on those documents, rather than tests we ran against the software.

What does a valid signature establish?

Checking a signature and deciding to accept an issuer are separate steps. For a university degree, a verifier checks the signature, establishes which university the signing key represents, and determines whether that institution is authorized to award the relevant qualification.

A verifiable credential, or VC, records claims and issuer information in a form that supports checks such as detecting tampering. A decentralized identifier, or DID, can identify an issuer or another party and, depending on the DID method, allow verification information such as public keys to be resolved. Possessing a DID does not make an organization an accredited institution.

The trust model in W3C's VC Data Model 2.0 leaves the decision to trust an issuer to the verifier. W3C develops Web standards; it does not accredit every university or professional body whose credentials use those standards.

A trust registry can help with the authorization question. A positive response does not independently prove that every claim is true, that the presenter is the intended person, or that the individual credential remains valid.

What is recorded in a trust registry?

A trust registry makes information about authority and authorization available to parties making trust decisions. For credentials, a useful example is an accrediting body stating that a particular university is authorized to issue a particular kind of degree credential. The information can also concern verifiers and other participants.

TRQP calls the party making such statements an authority. This can be a government, industry association, company, university, or another body accepted by participants within a defined scope. The documents describing membership, review procedures, and withdrawal of authorization form a governance framework.

In the university example, the accrediting body reviews the institution, a registry operator records the result, and an employer's system queries that record. The authority and registry operator may be the same organization or separate organizations. The TRQP specification distinguishes these roles.

The record can describe the university's authorization without holding every graduate's name and grades. Separating issuer information from the credential presented by a student can avoid sending personal academic records just to check the issuer. Query logs can still reveal information about usage, so query contents and retention practices deserve attention.

Is an accrediting authority compatible with self-sovereign identity?

An individual controlling a credential and an institution deciding who may award a qualification are different responsibilities. Self-sovereign identity, or SSI, emphasizes the individual's role in managing identity information. A graduate can hold a degree credential in a wallet while the university remains responsible for awarding that degree.

Control over storage does not allow a person to award themselves a medical qualification. Likewise, using a trust registry does not necessarily remove a central governing body. A registry can serve one authority, an industry, or a network of connected governance frameworks.

The useful distinction is between concentrating everyone's personal data in one service and accepting an authority for a specific qualification. Those choices do not have to be made together.

What does TRQP standardize?

If every ecosystem exposes authority information through a different interface, verifiers need separate integrations. The Trust Registry Query Protocol, or TRQP, supplies a common query interface while allowing the underlying records and governance arrangements to differ.

TRQP is developed by Trust Over IP, or ToIP, a project under Linux Foundation Decentralized Trust that works on technical and governance specifications for digital trust. Its deliverables page lists the v2.0 release on April 15, 2026. This article uses the approved v2.0 specification.

The first two entries come from ToIP's 2024 announcement. This is a short history of TRQP, rather than a claim that all trust registries descend from this effort.

Authorization and recognition answer different questions

An authorization query asks whether an authority has authorized an entity to perform an action on a resource. A recognition query asks whether one authority recognizes another as authoritative for the specified action and resource.

For education, authorization can answer whether an accrediting body authorizes a university to issue a particular qualification. Recognition addresses whether another ecosystem accepts that accrediting body's authority for the relevant scope. Recognition is a relationship between peers, can be unilateral, and does not imply that one authority controls the other.

Here is an illustrative request using fictional identifiers:

POST /authorization
Content-Type: application/json
 
{
  "authority_id": "https://example.org/authorities/education",
  "entity_id": "did:example:university",
  "action": "issue",
  "resource": "https://example.org/credentials/DegreeCredential"
}

The request asks about the university's authorization under the specified authority. Participants must agree on what issue and the credential identifier mean. Matching JSON fields does not prevent one party from confusing a degree with a certificate of attendance. The query schemas define the message structure.

How far does the “DNS for Trust” analogy go?

DNS provides a common way to look up information such as IP addresses associated with domain names. The TRQP analogy concerns a common query layer for authority information. It does not establish a universal accrediting body or automatically supply a way to discover every registry.

TRQP is read-only. Record creation and updates, admission reviews, and the choice of storage system remain outside its scope. A TRQP bridge translates between the common query interface and an existing system of record, such as a database or trust list; the implementation of a particular bridge is also outside the core protocol. The ToIP overview explains that separation.

Which implementations can you examine?

Public TRQP implementations and product documentation are available. They provide evidence that developers can build with the protocol, but they should not all be described as production deployments.

Affinidi Radix: an early-access registry product

Affinidi Radix documents TRQP v2.0 authorization and recognition queries. At the time of review, its product page identified it as part of an Early Access Programme. The underlying Rust trust registry implementation is public and can be evaluated for self-hosting.

The documentation describes storage options including CSV and DynamoDB. This makes the distinction between the query protocol and storage design tangible. Performance claims in product documentation should not be presented as measured results from a named customer's deployment.

Affinidi's education demo: checking across jurisdictions

Affinidi's education trust network reference implementation demonstrates universities issuing credentials, students holding them, and employers verifying them across jurisdictions. Its scenario uses Hong Kong, Macau, and Singapore. The repository explicitly labels the project a prototype for demonstration and education, not a production-ready product or evidence of government adoption.

The verifier first uses recognition queries to check the relationship with another jurisdiction's governing authority, then authorization queries to check the university's permission to issue the credential. This makes the distinction between reading a foreign credential and establishing grounds to accept its issuer concrete.

For an article or technical workshop, the demo is useful because the complete workflow is visible. It should remain labeled as a reference implementation even when its examples use names of real places or institutions.

OpenWallet Foundation Labs TRS: a common resolution interface

TRS, the Trust Resolving System, is a TypeScript project under OpenWallet Foundation Labs. It uses TRQP in an architecture intended to simplify queries across different trust mechanisms. Its repository lists maintainers from Hopae.

The README discusses OpenID Federation, X.509 certificates, and EBSI Trust Chains among the mechanisms it aims to address. It describes deployment of distributed server infrastructure as a plan. The repository establishes an open-source implementation effort; it does not, by itself, demonstrate production interoperability with every mechanism mentioned.

Ayra: conditions for connecting implementations

The Ayra TRQP Profile specifies how participants in the Ayra Trust Network use TRQP. A profile narrows a general specification into agreed requirements for a particular network. The version reviewed was v0.6.0-draft.

Ayra requires both core query endpoints and defines requirements for identifiers and errors. Unlike Radix, this is a specification for participants rather than a registry product. It is useful evidence of the work needed to align implementations, but publication of the profile does not establish that the entire network is operating in production.

What remains after the APIs connect?

Successful communication does not establish agreement about qualifications. If one ecosystem treats a certificate as proof of attendance while another treats it as evidence of passing an examination, a technically correct response can still lead to an incorrect business decision.

Choosing the authority to query

The verifier needs an accepted starting authority. If a presenter supplies a registry URL and that registry simply confirms the presenter is legitimate, the verifier has not established an independent basis for trust. The endpoint should be connected to an authority accepted under the verifier's policy, using its governance documents or identifier as appropriate.

The verifier also authenticates the endpoint and checks that the response corresponds to the entity, action, resource, and authority requested. A successful HTTP response is not an acceptance decision. An unavailable service should be distinguished from a negative authorization result, with a defined process for deferral or another check.

Checking the right point in time

A university's authority to issue today is different from its authority when a degree was issued years ago. TRQP supports time-based query conditions, but operators also need records and procedures that can answer those historical questions. Whether an older degree remains acceptable after accreditation is withdrawn is a governance and acceptance-policy decision.

The status of the individual credential remains a separate check. A positive authorization result cannot substitute for checking revocation or suspension when the credential scheme requires it.

Portability requires agreement beyond the data format

In the earlier DID/VC series, I argued that the gap between portable identity as an idea and fragmented implementation choices may be one reason adoption remains difficult. Trust registry integration adds another part of that problem: even after a credential can be exchanged and parsed, the recipient still needs grounds to accept the issuer.

TRQP may reduce the need to create a different query integration for each ecosystem. It leaves participants responsible for accreditation criteria, the meaning of permissions, and procedures when authorization changes. A useful pilot therefore checks unauthorized issuers, out-of-scope qualifications, and unavailable registries alongside successful cases, with the business owner involved in deciding the expected outcome.

FAQ

Is a blockchain required?

No. TRQP does not prescribe the underlying record system. Implementations can use conventional databases or other storage systems.

Is TRQP required to use W3C verifiable credentials?

No. A verifier can use other ways to decide which issuers to accept, including a configured list. A common query protocol becomes relevant when the integration needs involve multiple registries or governance frameworks.

Can TRQP be described as widely deployed?

Public implementations and product documentation establish that it can be implemented. The sources reviewed here did not establish enough named deployments with ongoing operational evidence to assess the scale of production adoption.

Summary

Trust registries let recipients look up authority information relevant to a credential issuer. TRQP supplies one way to standardize those queries, and developers now have products and reference implementations to examine.

For a deployment, begin by recording who accepts which qualifications and who maintains that decision. The next step beyond the portable credentials discussed in the ZenChAIne DID/VC series is to connect issuer authorization information to the recipient's actual acceptance policy.

References

• W3C: Verifiable Credentials Data Model v2.0
• ToIP: Approved TRQP v2.0 specification
• ToIP: Deliverables
• ToIP: 2024 Implementers Draft announcement
• ToIP: TRQP overview
• Affinidi Radix documentation
• Affinidi Rust trust registry
• Affinidi education trust network
• OpenWallet Foundation Labs: TRS
• Ayra TRQP Profile