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

Verification is solved. Validation is not.

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

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 stays compatible with ETSI TS 119 612 so eIDAS national lists and the EUDI Wallet trusted lists can be referenced rather than duplicated.

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.

Proposed joint stewards

Four mandates that do not overlap

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

Rights, agreements & compliance

What a party may access under which machine-readable licence terms — and what it has signed, conforms to, and belongs to. Its issuers issue both Data Rights and Party credentials: agreements, conformance, roles, memberships. Scheme owner; issues nothing itself.

GLEIF

Organisational identity

Who is this legal entity, globally. Anchors the vLEI ecosystem and qualifies its issuers under a G20/FSB-backed mandate; LEIs and vLEIs are issued by accredited third parties, never by GLEIF.

Ayra Association

Recognition

Which ecosystems recognise one another, and under what governance. Operates a registry for registry-of-registry purposes and governs the network around it — and is deliberately not a trust framework: it accredits no issuers and issues no credentials itself.

DIDAS

Ecosystem orchestration

How a national e-ID ecosystem connects to and consumes the meta-list. Swiss non-profit, designated swiyu Orchestrator by the Federal Government; the ecosystem’s orchestrator, not its operator or an issuer — swiyu’s infrastructure is run by the federal administration.

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. The framework and the issuers on its list are identifiable, with the assurance level of that identification stated. Sovereign and national organisation identifiers come first; the LEI is one accepted option among others, never a precondition. Schemes compete on assurance level, not by being the single named specification.
  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. GLEIF qualifies its Qualified vLEI Issuers and grants or withdraws entries on its own QVI list; the issuers, not GLEIF, issue LEIs and vLEIs. That list is mirrored here, with GLEIF remaining the source of truth; eIDAS lists are referenced as authoritative. TRQP CLIENTS · WALLETS · VERIFIERS recognition & authorization queries TRQP META-LIST — recognised trust frameworks iSHARE Trusted List GLEIF QVI list — automated mirror eIDAS LOTL / EUDI lists — referenced recognises frameworks and their lists TRUSTED LIST OF ISSUERS — per framework iSHARE Qualified Issuers GLEIF QVIs — they issue the (v)LEIs, not GLEIF issuers anchored on recognised roots TRUSTED LIST OF CAs / IdPs — the roots eIDAS-qualified CAs · PKIoverheid GLEIF vLEI chain of trust GLEIF qualifies QVIs; grants and withdraws entries on its own QVI list One machinery, three levels /trusted_list /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 mirrored automatically — GLEIF remains the source of truth; its provenance and signatures preserved, never a fork
Member frameworks are consumed in one of two modes. Referenced at their authoritative location — the default, and the only mode for regulatory lists such as the eIDAS LOTL. Or mirrored automatically, with the framework’s own signatures and provenance preserved, so the framework remains the single source of truth and the mirror can never diverge into a fork.
Two anchoring styles, one resolution pattern List-anchored frameworks such as iSHARE publish a signed list that a verifier consults. Chain-anchored frameworks such as GLEIF's vLEI ecosystem embed the accreditation proof in the credential chain, verifiable without a lookup. Both arrive at the same answer. 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 VC 2.0 · DID Core
The credentials being validated, and resolvable authority identifiers.
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:localhost:8082.
  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 1

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.

The register as published at list version 1.
FrameworkGovernance authority ConsumptionStatus
iSHARE Trust Framework ishare iSHARE Foundation proxied — served through this list, the framework’s own signature preservedanchoring: list granted
GLEIF vLEI Ecosystem gleif-vlei Global Legal Entity Identifier Foundation mirrored — the framework remains the source of truth (pointer only — adapter not yet built)anchoring: chain granted
EU List of Trusted Lists (eIDAS) eu-lotl European Commission referenced as authoritative regulatory list (pointer only — adapter not yet built)anchoring: list granted

Machine-readable: /trusted_list · unsigned view · /capabilities · DID document · /ready

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.8