Two Trust Registry Models: Delegated Accreditation and Direct Issuer Lists
Introduction
A trust registry can record which issuers an operator accepts. It can also help establish how authority was delegated through several organizations before reaching an issuer. Which design fits depends on who is responsible for assessing those issuers.
Our previous article separated verification of a credential's signature from verification of its issuer's authority. This article examines two ways to organize that authority: hierarchical delegation and a direct issuer list.
Key points
- Delegated accreditation represents who may accredit others and who may issue particular credentials.
- A direct list records permissions that a verifier can look up.
- These approaches can coexist: a list can contain results derived from validated accreditation chains.
- Scope, expiry, withdrawal, and update responsibilities matter in both designs.
Sources were checked on October 1, 2026. This is a review of public documentation and source material, not a runtime comparison or an assessment of production deployments.
What distinguishes the two models?
The practical distinction is where accreditation decisions are made. If one operator assesses every issuer, it can register those decisions directly. If it delegates that work, it also needs to represent the authority granted to each accrediting organization.
Consider a fictional safety-training ecosystem. A national council, regional bodies, training providers, learners, and employers participate. This is an explanatory scenario, not an account of a real qualification scheme.
In a direct-registration model, the national council assesses Training Provider A and records its permission to issue safety-course completion credentials. In a delegated model, the council authorizes a regional body to accredit providers, and that body accredits Provider A. In both cases, Provider A issues the learner's credential.
These are useful design categories, not an exhaustive classification defined by an international standard. Delegation describes the authority structure; a list describes a way to record and query decisions. They are not mutually exclusive.
What does a delegated accreditation chain establish?
A chain provides a path from an issuer to a trust anchor accepted by the verifier. Validation must establish that each grant stayed within the authority of the organization making it.
Public examples include EBSI Trust Chains and cheqd's Decentralized Trust Chains, or DTCs. EBSI is a European blockchain infrastructure. cheqd develops digital identity infrastructure and tools; its DTC documentation builds on the EBSI approach.
Accreditation credentials and end-user credentials
In cheqd's model, a Verifiable Accreditation, or VA, is a credential about an organization's authority. Its purpose differs from a credential saying that a learner completed a course.
Applied to our fictional example, the sequence is:
- The national council publishes a Root Authorization describing the governance framework.
- It issues an accreditation allowing a regional body to accredit training providers.
- The regional body accredits Provider A to issue safety-course completion credentials.
- Provider A issues an ordinary completion credential to a learner.
The documentation calls these organizations a root Trusted Accreditation Organisation, or rTAO; a Trusted Accreditation Organisation, or TAO; and a Trusted Issuer, or TI. The useful distinction is between authorizing accreditation, authorizing issuance, and attesting to the learner's achievement. cheqd setup guide
A grant has a scope
Permission to issue safety-course credentials does not authorize medical licenses. Permission to issue credentials does not automatically authorize a provider to accredit other providers, either.
cheqd's TAO-to-issuer documentation describes credential types, schemas, and jurisdictional constraints. Its SubTAO documentation also describes references to parent accreditation and the root authorization.
The verifier needs to check relevant signatures, validity periods, status, and scope, and establish a path to a root it accepts. A correctly signed self-declaration cannot make its signer a trust anchor for another organization.
cheqd publishes accreditation as resources linked to DIDs. That implementation uses its ledger; hierarchical delegation as a design principle does not inherently require a blockchain. Authority structure, cryptographic format, and storage technology are separate choices.
What belongs in a direct issuer list?
A direct list records accepted issuers and their permissions. If the national council assesses Provider A itself, it can register the result without introducing an intermediate accreditor.
A list of identifiers alone does not say what an issuer may issue. An illustrative internal record could look like this:
{
"authority": "did:example:training-council",
"issuer": "did:example:training-company-a",
"permission": "issue",
"credentialType": "https://example.org/credentials/SafetyCourse",
"validFrom": "2026-04-01T00:00:00Z",
"validUntil": "2027-04-01T00:00:00Z",
"status": "active"
}This is an invented internal format, not a TRQP payload or a product-specific schema. The identifiers and dates are explanatory values.
The employer matches the credential's issuer and type to a record from an authority it accepts, then checks the permission's validity and status. Being listed must not silently grant permission to issue every kind of credential.
A credential's type is also distinct from its optional credentialSchema. Participants must agree on which identifiers determine issuance scope and how schema versions are handled. W3C VC Data Model 2.0
A public implementation to inspect: Affinidi
Affinidi's Rust trust registry includes a CSV-backed quickstart and sample records. The sample inspected for this article includes entity_id, authority_id, action, and resource: enough to express who grants which permission over which subject matter, rather than merely listing names.
This makes it a useful example of querying recorded permissions through a common interface. It does not mean that the entire product is limited to a flat allowlist; it also supports Recognition queries about authorities.
The Affinidi Radix product documentation describes an Early Access Programme and presents CSV as a development/testing option. Public source code and product availability do not establish production adoption or measured performance.
Does TRQP standardize the internal model?
TRQP standardizes queries about authority. It does not prescribe a universal accreditation process or a single internal data structure. The reference here is the ToIP-approved TRQP v2.0 specification.
A chain evaluator and a direct-record lookup could therefore sit behind a common query interface. Implementing that connection is a separate task. This article does not claim that cheqd DTC exposes that interface out of the box.
Accredit through a hierarchy, answer from a list
One possible design validates regional accreditations and derives a searchable list of authorized training providers. This is an architectural example proposed here, not a configuration tested against a named product.
Such a list needs more than a final boolean. It needs provenance: which accreditation justified a record, when the result was evaluated, and which records must be re-evaluated when an upstream accreditation changes. A simpler lookup creates maintenance responsibilities elsewhere.
Recognition is not another word for delegation
TRQP Recognition asks whether an authority recognizes another entity as an authority for a particular scope. Recognition across ecosystems need not make the recognized organization subordinate to the recognizing one.
Nor should an implementation assume that A recognizing B and B recognizing C automatically means A recognizes C. The accepted path and any transitivity rules must come from the applicable governance framework. This is a design requirement, not an implication of matching API fields.
What happens when accreditation is withdrawn?
Withdrawal of an issuer's authority and revocation of individual credentials are separate decisions. Both models must account for that distinction.
Suppose Provider A stops trading next month. The ecosystem may prohibit new issuance while continuing to accept credentials earned by learners last year. If fraudulent issuance is discovered instead, the response might target particular credentials. The reason for stopping an issuer matters to how existing credentials are treated.
| Decision | Delegated accreditation | Direct registration |
|---|---|---|
| Withdrawal | Re-evaluate dependent authority when an upstream grant is withdrawn | Stop or update the relevant permission records |
| Evaluation time | Decide whether authority at issuance, presentation, or both is required | Preserve history if past authority must be checked |
| Unavailable data | Define behavior when part of the chain cannot be retrieved | Define behavior when the list or query service is unavailable |
| Credential status | Check each credential's validity and status separately | Do the same; list membership is insufficient |
TRQP can express an evaluation time, but a historical answer still requires supporting records. A service cannot reconstruct last year's authority merely because its query accepts a timestamp.
“Unable to verify” should also remain distinct from “not authorized” in the surrounding business process. The relying party must decide when to reject, defer, or request another form of evidence.
How should a project choose?
My starting point is direct registration when the operator can assess all issuers itself and does not need to delegate accreditation. This is a design preference under those conditions, not a standards body's universal recommendation.
If the business already delegates assessment to regional or specialist organizations, the system needs to represent that authority from the start. Participant count alone is a poor criterion: a large ecosystem can still have one accreditation authority, while a small ecosystem may already need delegation.
Before selecting software, identify who assesses issuers, what authority can be delegated, who processes withdrawals, and when those changes become visible to verifiers. When another ecosystem is involved, agree on what its accreditation actually establishes.
Standardizing credentials and queries does not eliminate those agreements. Technical fragmentation can make interoperability expensive; mismatched accreditation criteria can still prevent acceptance after the software connects. In my view, implementing only the common API leaves a substantial part of the business problem unresolved.
FAQ
Does a hierarchy remove central authority?
It can distribute accreditation work while retaining accepted roots and common participation rules. Distributed storage and distributed decision-making are different properties.
Does a direct list require a blockchain?
No. Choose storage based on update permissions, audit needs, and availability requirements. A blockchain is one possible implementation choice, not a prerequisite for matching permission records.
Does a positive TRQP response finish credential verification?
No. The verifier still needs applicable signature, validity, status, and holder checks, as well as a basis for trusting the responding authority.
Summary
Delegated accreditation preserves a path of authority. A direct list records permissions for lookup. A system that validates accreditation chains and derives a searchable list uses both ideas.
The first architecture diagram should include the people responsible for assessment, withdrawal, and updates—not just issuers and APIs. These operational responsibilities belong alongside the implementation choices discussed in ZenChAIne's development and technical advisory work.