TrustedListOfTrustedLists.org a trust registry of trust registries Draft for discussion

The missing layer of the verifiable credential stack

Global assurance for the issuers of verifiable credentials

The trusted pointer to the trusted lists.

Verification is solved. Validation is not. Government registries first: sovereign authorities are referenced as published, never admitted. Voluntary frameworks are recognised against published criteria. Sovereign first. Compete on assurance, not on a scheme.

A signature proves a credential is intact and was signed by a particular party. It says nothing about whether that party is entitled to make the claim. Every ecosystem answers that its own way — so a verifier in one ecosystem has no standard way to establish confidence in an issuer accredited in another. That is a governance problem before it is a technical one.

Read the whitepaper Founding partners Recognised frameworks The signed list

3 Sovereign / regulatory

Referenced as published, never admitted.

2 Voluntary frameworks

Recognised against published criteria.

5 Reliable today

Status granted or undersupervision.

2 Location pending

Published as a pointer, never an invented URL.

The proposal

One question, answered once

A federated meta-list, on the model of the EU’s List of Trusted Lists under eIDAS. Each participating trust framework continues to accredit its own issuers under its own rules. The shared layer answers one narrower question, with global reach: which trusted lists can a verifier rely on, and for what?

Everything is a signed, cacheable, machine-readable answer. One resolution pattern, three consumption surfaces: REST and signed JWTs on the Meta-List Profile, the Trust over IP Trust Registry Query Protocol, and — as that work matures — verifiable credentials. The profile is designed for compatibility with ETSI TS 119 612 so eIDAS national lists and the EUDI Wallet trusted lists can be referenced rather than duplicated — the serialisation and the adapters that read those formats are a later milestone, not yet built.

The proposal reuses infrastructure that already runs in production and adds only the thin layer that is genuinely missing.

What it does not do

The meta-list does not accredit issuers. Accreditation stays entirely with the member frameworks, under their own rules, liability regimes and supervision. Recognition is not an endorsement of any individual issuer and transfers no liability.

There is no single root of trust: the meta-list is one authority among peers, and every verifier decides which authorities it relies on.

Stewardship — proposed, subject to agreement

Proposed stewards (subject to agreement)

Four non-profit bodies, each neutral at a different level: recognition, organisational identity, data rights, ecosystem orchestration. None is a software vendor or a commercial issuer, and none competes with the parties it governs — which is exactly the neutrality this layer requires. The stewardship is designed to widen: a starting configuration, not a closed club.

iSHARE Foundation logo iSHARE Foundation

Data rights and transaction-level assurance

Trust framework governor and credential authority for data spaces: defines rules and schemas, accredits the iSHARE Qualified Issuers, publishes the iSHARE Trusted List — and never issues a credential itself. Contributes the API profile and the legal architecture on which the meta-framework is built.

GLEIF logo GLEIF

Organisational identity

Global cross-border organisational identifier and mapping service where sovereign identifiers do not reach across borders; one accepted identifier scheme among others, competing on assurance and coverage.

Ayra Association logo Ayra Association

Cross-ecosystem recognition

Governs the Ayra Trust Network; the meta-list is a recognition source within it, not a layer above it.

DIDAS logo DIDAS

National-ecosystem orchestration and adoption

Designated swiyu Orchestrator; connects Switzerland’s national e-ID ecosystem — outside the eIDAS regime — to the meta-list.

Two of the four — iSHARE and GLEIF — are themselves trust frameworks that will appear on the meta-list, and the national list of the ecosystem DIDAS orchestrates may be referenced on it. So neutrality is protected procedurally as well as structurally: a steward takes no part in decisions on its own framework’s status, its framework is assessed against the same published criteria by the others or an independent assessor, and every decision is recorded and appealable.

The open question

Where are the government registries?

This is the urgent one, and it is not yet answered. Sovereign registers of companies, of licensed professionals, of vehicles, of qualifications — these are the registries that carry the most authority and the least cross-border reach. A layer that recognises trust frameworks but cannot reach a national register answers the easy half of the question.

Sovereigns are primary. A country will not accept an external identifier scheme as better than, or even equivalent to, its own organisation identifiers. Any design that assumes otherwise will not be adopted by the parties that matter most.

Beyond Europe

Recognition has to work where the credentials actually travel. Registries and directories that already operate outside the EU are first-class candidates, not an afterthought:

ICAO’s Public Key Directory · the VICAL operators for ISO mdoc credentials (AAMVA, Austroads) · MOSIP-based national ID ecosystems · Credential Engine for education and skills · the ICC Digital Standards Initiative for cross-border trade · alongside the EU’s LOTL and the EUDI trusted lists.

Admission

Light to start, designed to grow

Recognition is criteria-based, not invitational — but a heavy gate at the start would exclude exactly the registries this layer most needs. The criteria begin deliberately light and are meant to tighten as the layer proves itself. A framework seeking a place demonstrates, among other things:

  1. Published governance and accreditation criteria. The rules by which it accredits issuers are public and reviewable.
  2. Identified legal accountability of the governing authority. A legal entity identified under a recognised scheme with declared assurance. No scheme is mandated: sovereign first, and schemes compete on assurance and coverage.
  3. Conformance testing of issuers. Against the relevant credential specifications — not self-declaration.
  4. Supervision and revocation procedures. Accreditation is continuous, and can be withdrawn.
  5. Machine-readable publication of its own trusted list. So the answer can be resolved, not requested.
Separation of powers in a recognised trust framework A supervisory body appoints and can dismiss the executive body, which directs an operational branch. The parties bound by the framework advise it and appoint its supervision. Expert advice on changes is separated from the body that decides, and admission and status decisions are appealable to a body that did not make them. GOVERNING AUTHORITY — SETS THE RULES Council of participants the parties bound by the rules appoints Supervisory body appoints and dismisses Executive body accountable upward Operational branch runs the machinery ADMINISTERING AUTHORITY operating confers no say Change advisory experts, not deciders Appeal to a body that did not decide Every admission and status decision is appealable.
The separation of powers a recognised framework is expected to demonstrate, generalised from the iSHARE model. The Governance Metamodel’s distinction between a governing authority and an administering authority is applied throughout: operating the machinery confers no say over it.

Separation of powers

A framework that accredits others has to show the same discipline it demands. The body that runs it is accountable to a body that can dismiss it; the parties bound by the rules advise it and appoint that supervision; expert advice on change is separated from the decision; and every admission or status decision is appealable to a body that did not make it.

The full base requirements — generalised from the framework the iSHARE Foundation operates in production.

Governance and technology stay separate

They are different artifacts with different lifecycles, and neither substitutes for the other. The governance framework is authored and amended by the governing authorities; the profile, the schemas and the conformance suite live in open community process.

The enforceable process behind the criteria is rebuilt on the legal architecture the iSHARE Foundation already operates in production: accession agreements binding every listed framework to the published criteria · continuous supervision carrying eIDAS-style status, so trouble is visible before it is terminal · defined procedures for suspension, removal and incident handling · and an appeal path for admission and status decisions, so the stewards’ own judgment is accountable.

Regulatory lists are not assessed

An authoritative regulatory list — the eIDAS LOTL, the EUDI Wallet trusted lists, a national register — is referenced as authoritative. This framework has no authority over it and applies no admission criteria to it.

Recognition transfers no liability in either direction. Each framework remains fully accountable for its own accreditations, under its own legal regime, exactly as today.

Architecture

One machinery, applied three times

The same list machinery already operates at two levels. The meta-list is that pattern applied one level up — which is why it generalises without modification.

The recursive architecture: one machinery, three levels TRQP clients query the meta-list, which recognises trust frameworks. Each framework publishes its own list of accredited issuers, and those issuers are anchored on a list of recognised certificate authorities and identity providers. Sovereign and regulatory registers are referenced as published and come first; voluntary frameworks are forwarded or mirrored. No identifier scheme or framework is a precondition, and none occupies a privileged place in this structure. TRQP CLIENTS · WALLETS · VERIFIERS recognition & authorization queries TRQP META-LIST — recognised trust frameworks sovereign registers — referenced as published EU LOTL / EUDI lists — referenced voluntary frameworks — forwarded or mirrored recognises frameworks and their lists TRUSTED LIST OF ISSUERS — per framework each framework accredits its own issuers, under its own rules the meta-list holds no issuer data of its own issuers anchored on recognised roots TRUSTED LIST OF CAs / IdPs — the roots eIDAS-qualified CAs · national CAs and IdPs other accredited roots — no scheme is privileged One machinery, three levels /TrustedLists /parties /capabilities signed JWTs · cacheable, verifiable offline each level serialisable as an ETSI TS 119 612 list — the LOTL pattern verifier walk: credential → issuer → framework list → meta-list → roots
The meta-list holds no issuer data of its own — it is the trusted pointer to the trusted lists. Each pointer is consumed in one of three modes. Forwarded: the framework runs its own TRQP endpoint; authorization queries are forwarded to it unchanged (iSHARE → tr.ishare.eu). Mirrored: the framework publishes a list but no TRQP endpoint; the meta-list mirrors the public list to answer, and the framework remains the source of truth (GLEIF). Referenced: pointer only, consumed as published — the mode for regulatory lists such as the EU List of Trusted Lists.
Forwarded, mirrored and referenced Forwarded: the framework runs its own TRQP endpoint and the query is passed to it unchanged. Mirrored: the framework publishes a list but no endpoint, so its public list is mirrored to answer while the framework remains the source of truth. Referenced: the pointer is published and the verifier resolves the authoritative list itself. FORWARDED the framework runs its own TRQP endpoint verifier meta-list framework endpoint the query is passed on unchanged MIRRORED a list, but no endpoint to query verifier meta-list the published list ingested to answer; the framework stays the source REFERENCED consumed exactly as published verifier pointer the authoritative list nothing is copied — the verifier resolves the source
The same pointer list, three ways of resolving it. Nothing about the answer changes — only where it is fetched from, and who remains the source of truth.
Two anchoring styles, one resolution pattern List-anchored frameworks such as iSHARE publish a signed list that a verifier consults; chain-anchored frameworks embed the accreditation proof in the credential chain, verifiable without a lookup. Both arrive at the same answer with the same confidence, and the meta-list treats them as equals. LIST-ANCHORED the verifier consults the framework’s signed list Framework accredits, publishes Trusted list signed, resolvable Issuer on the list Credential held by a party The proof of accreditation lives on the list — one lookup, and the status can change without re-issuing anything. CHAIN-ANCHORED the proof travels inside the credential itself Framework qualifies issuers Issuer holds the chain Credential — carrying the chain of trust verifiable without consulting any list The proof of accreditation is cryptographic and offline — no lookup required, and revocation rides its own status mechanism.
Frameworks prove accreditation in one of two ways, and both are first-class. A framework’s entry declares its anchoring style alongside its scope, status and assurance level, and the resolution walk accommodates either — arriving at the same answer with the same confidence.
ETSI TS 119 612 / 602
Trusted list serialisation; the LOTL pattern of pointers to other lists.
ToIP TRQP v2.0
Recognition and authorization queries, and the Ayra profile built on them.
W3C Verifiable Credentials Data Model 2.0
W3C Recommendation. The credentials being validated — and the specification that puts issuer validation explicitly out of its own scope, which is the gap this layer closes.
W3C DID Core
Resolvable authority identifiers; did:web today, did:webvh as the upgrade path.
ToIP Governance Metamodel
The structure of the governance framework itself.
RFC 7807 · RFC 2119
Problem details on every error; normative requirements language.

Resolution

How a verifier resolves trust

One standard walk. Every hop is a signed answer, and every trust decision stays explainable: framework X accredited issuer Y; the meta-list recognised framework X.

  1. Credential → issuer. The credential names the party that signed it.
  2. Issuer → framework. Is this issuer accredited, and does its status hold? List-anchored frameworks are consulted; chain-anchored ones are verified in the credential chain itself.
  3. Framework → meta-list. Is this framework recognised, for these credential types, with what status?
  4. Meta-list → its own authority. The signed token verifies against did:web:trustedlistoftrustedlists.org.
  5. One choice, every recognised list. A verifier that relies on the meta-list gains a standard basis for confidence in every issuer on every framework it recognises — no bilateral integration per ecosystem. Issuer trust becomes as resolvable as a domain name.

Level 2 · list version 2

Referenced authorities and recognised frameworks

Status vocabulary is eIDAS-style. Only granted and undersupervision may be relied upon; withdrawn entries stay published for as long as credentials issued under them remain valid.

granted
Recognised, or referenced as published. May be relied upon.
undersupervision
Recognised, under enhanced supervision. May be relied upon.
suspended
Temporarily not to be relied upon.
withdrawn
Terminated. Kept visible for auditability.
supervision ceased
Historical. Never to be relied upon.

Sovereign and regulatory — referenced as published

This layer has no authority over these registers and applies no admission criteria to them.
Authority / frameworkGovernance authority ConsumptionAnchoringRegulatory Recognition status
EU List of Trusted Lists (eIDAS) eu-lotl European Commission referenced — consumed as published · adapter not yet built, pointer onlyec.europa.eu list yes reference in force not assessed by this layer
Swiss e-ID trust infrastructure (swiyu) ch-swiyu Swiss Confederation — federal administration referenced — consumed as published · upstream not yet reachablelocation pending confirmation list yes reference pending not assessed by this layer
Bhutan National Digital Identity bt-ndi Royal Government of Bhutan referenced — consumed as published · upstream not yet reachablelocation pending confirmation list yes reference pending not assessed by this layer

Voluntary frameworks — recognised against published criteria

The register as published at list version 2.
Authority / frameworkGovernance authority ConsumptionAnchoringRegulatory Recognition status
iSHARE Trust Framework ishare iSHARE Foundation forwarded — queries go to the framework’s own TRQP endpoint · upstream not yet reachabletr.ishare.eu list no granted
GLEIF vLEI Ecosystem gleif-vlei Global Legal Entity Identifier Foundation mirrored — the framework remains the source of truth · adapter not yet built, pointer onlywww.gleif.org chain no granted
GET /TrustedLists
The signed register. Unsigned view.
GET /parties?framework=
Level-1 entries of one framework, with provenance.
GET /capabilities
Profile capabilities and governance metadata.
GET /.well-known/did.json
Authority identity and service endpoints.
POST /recognition
POST /authorization
Not yet available (B-M2). The TRQP surface is planned against the approved TRQP v2.0 specification.

Governance

Openness with legal teeth

The meta-framework is authored as an Ecosystem Governance Framework conformant with the ToIP Governance Metamodel. The metamodel’s distinction between a governing authority — the stewards, who set the rules — and an administering authority — whoever operates the machinery under mandate — is applied explicitly: operating the meta-list confers no say over it.

Admission is criteria-based and appealable, with no incumbent veto and no exclusivity demanded of members. Openness without enforceable agreements would make this a directory; enforceability without openness would make it a cartel. The design requires both.

Relationship to the Ayra Trust Network

Ayra operates its own registry for registry-of-registry purposes, so this is a relationship between peers, not a hierarchy. The proposal positions the meta-list as a recognition source the Ayra network can resolve against — a trust cluster within Ayra, not a layer above it. Ayra’s governance over recognition remains fully sovereign.

Practically that means conforming to the Ayra TRQP Profile: both core endpoints, TRQP field names with DID URI identifiers, RFC 7807 errors. Those endpoints are not built yet, so this service is not yet Ayra-conformant.

Where this stands

An early implementation of the whitepaper’s proposal. The configuration ships with draft decision records that are not yet governance acts, and the TRQP binding is not built yet.

Governance documents · Whitepaper v0.9