Trust Frameworks for the Emerging Verifiable Credentials Environment

Over the past few years, the verifiable credentials community has quietly won most of the arguments that used to consume it. We have converged, more or less, on credential formats. We have wallets that work. We have presentation protocols that interoperate across vendors. What we have not settled — and what now sits squarely on the critical path to adoption — is trust.

The hard question in any credential exchange is not whether a signature verifies. It is whether the verifier should believe that the entity behind that signature is actually authoritative for what it is asserting. Is this issuer really entitled to attest to a diploma, a professional license, a company role, an age? Establishing that, at scale, across borders and across sectors, is the unsolved layer of the stack. Everything else is increasingly plumbing. Trust is the architecture.

This is the problem my team at Triveria works on, and it is the lens I want to use to look at where the existing trust frameworks stand, what we are building inside the WE BUILD WP4 Trust Infrastructure group, and where I believe trust services have to go if verifiable credentials are ever going to achieve genuinely global reach.

Where we are: a survey of existing trust frameworks

ETSI X.509 Trusted Lists

The most mature answer we have inherited comes from the eIDAS world. ETSI’s Trusted List model — TS 119 612, now complemented by the format-agnostic data model in TS 119 602, and anchored at the top by the List of Trusted Lists (LoTL) — gives us a rigorous, legally grounded way to publish who is trusted for what. A signed Trusted List acts as a trust anchor; a verifier walks from the LoTL down to a Member State’s list, validates the certificate chain, and reaches a defensible decision. This machinery underpins qualified electronic signatures today, and under eIDAS 2.0 and the EUDI ARF it carries forward to PID Providers, Wallet Providers and the qualified end of the attestation spectrum.

It is mature, it is auditable, and it produces legal certainty that nothing else on this list can yet match. But it has two structural limitations that matter enormously as we move from a few hundred qualified trust service providers to a world of millions of credential issuers.

The first is scalability. The model is centralised and curated. Lists are maintained per Member State, published and signed by a designated authority, and updated through processes that assume a relatively small, slow-moving population of supervised entities. That is appropriate for qualified trust services. It does not stretch to an open, long-tailed ecosystem of issuers.

The second, and in my view the more fundamental, is the rigidity of the data and attestation model. An X.509 Trusted List is excellent at expressing “this entity is a qualified trust service provider of type X.” It is poor at expressing the rich, evolving, fine-grained statement “this entity is accredited to issue these specific attestation types under these conditions.” The schema was not designed to be extended in that direction, and bending it to do so is awkward at best.

My conclusion is not that X.509 Trusted Lists go away. They will remain — and they should — as the backbone for qualified entities, where legal weight and supervisory rigour are the whole point. But they are not the substrate on which a global, open credential ecosystem will be built.

EBSI

EBSI deserves credit for confronting the data-model problem head-on. Its onboarding credential introduces an accreditedFor field, which lets accreditation itself be expressed as data — defining which attestation types a given entity is entitled to issue, rather than encoding that authority implicitly in a certificate profile. That is exactly the right instinct: trust granularity belongs in an extensible, machine-readable structure, not baked into PKI metadata.

The cost is the foundation it chose. Being blockchain-based, EBSI inherits the performance and throughput characteristics of a distributed ledger. For a trust layer that may need to be consulted on every credential issuance and every presentation, at internet scale and with low latency, ledger performance becomes a real constraint rather than an academic one.

OpenID Federation

This is where I believe the viable path lies. OpenID Federation gives us hierarchical trust chains built from signed entity statements, with trust marks for fine-grained authorisation, and — crucially — flexible metadata that can carry exactly the kind of extensible accreditation semantics that EBSI gets right, but without a ledger underneath. It supports dynamic onboarding, it scales horizontally like the web does, and it expresses rich trust relationships natively. It takes the lesson of EBSI’s accreditedFor and delivers it on infrastructure that performs.

What we are building: WE BUILD WP4 Trust Infrastructure

Triveria is not observing this from the sidelines. We are an active contributor to the WP4 Trust Infrastructure groupwithin the WE BUILD consortium, whose mandate is to establish the framework for trust evaluation and management within wallet ecosystems, in alignment with — but not limited to — the eIDAS model under Regulation 910/2014 as amended by 2024/1183.

In concrete terms, the group has built a working trust model grounded in the trusted-third-party approach: a published List of Trusted Lists that serves as the trust anchor in the ETSI TS 119 612 sense, referencing the Trusted Lists for PID Providers, Wallet Providers and other entity types so that Wallet Units and Relying Parties can validate certificates and trust anchors. During the MVP pilot phase, the group itself acts as Ecosystem Authority and Trusted List Provider, with a clear handover path to the European Commission and Member State Trusted List Providers in production. The implementation is real: participant Trusted List Providers contribute their list entries by pull request, CI fetches each referenced list, validates its signature against the supplied trust anchor and checks it against the ETSI schema, and on merge the signed LoTL is regenerated and republished. Around that sit the X.509 PKI with ETSI alignments, and a full set of trust-evaluation use cases covering wallet-to-issuer, issuer-to-wallet and wallet-to-relying-party flows.

This work is the proving ground. It is where the abstract debate about trust frameworks meets running code, ETSI conformance and real onboarding flows — and it is what informs the view I want to set out next.

How I see trust services evolving

If the MVP establishes that the qualified, X.509-anchored model works, the harder and more interesting question is what comes after it. Here is where I think trust services have to go.

EAAs are the unit of global adoption. The qualified tier — PID, qualified attestations — is essential, but it is the narrow end of the funnel. The overwhelming majority of useful credentials in the world are Electronic Attestations of Attributes issued by ordinary organisations: universities, employers, professional bodies, retailers, associations. Global adoption of verifiable credentials will be driven by the long tail of EAAs, not by the qualified core. A trust layer that only serves qualified entities elegantly, and treats everyone else as an afterthought, has optimised for the wrong end of the market.

Trust lists must be democratised. The logical consequence is that anyone should be able to stand up a trust list and allow the relevant participants to join it. Trust in a global ecosystem will not be a single registry that everyone defers to; it will be a fabric of many lists, each authoritative within its own community of context — a sector, a jurisdiction, a supply chain, a consortium. For that to work, the underlying technology has to scale in two dimensions at once: in performance, so that a list can serve a large and active membership without becoming a bottleneck, and in data flexibility, so that each list can express the specific attestation types and conditions its community needs. This is precisely where X.509 Trusted Lists fall short and where an OpenID Federation–based approach fits. We are already forming the working group to deliver this OpenID Federation trust layer as the MVP+ deliverable for WE BUILD.

These environments have to be bridged. A world of many trust lists only delivers global reach if those lists can interoperate. The goal is not one ecosystem to rule them all — that ambition has failed every time it has been tried — but the ability for a verifier anchored in one trust environment to evaluate a credential issued under another. Bridging individual trust domains, so that trust can be carried across ecosystem boundaries without collapsing them into a single authority, is a first-class design problem, not an afterthought. It is, in my view, the difference between a federation of regional pilots and a genuinely global credential ecosystem.

And it has to be post-quantum ready. Any trust layer we design now will still be load-bearing when cryptographically relevant quantum computers arrive. Crypto-agility cannot be retrofitted cheaply onto a rigid, certificate-bound model; it has to be a property of the architecture. OpenID Federation’s flexibility around signing and metadata gives us a realistic path to migrate to post-quantum algorithms without re-architecting the trust fabric — another reason it is the right foundation for what comes after the MVP.

Closing

It is tempting to think of trust as a detail to be settled once the interesting work on formats and wallets is done. The opposite is true. Trust is the infrastructure, and it is the layer on which adoption will succeed or stall. The frameworks we have each contribute something — ETSI’s rigour for qualified entities, EBSI’s insight that accreditation belongs in data, OpenID Federation’s scalable and flexible foundation — but none of them, alone, is the whole answer.

The organisations that move verifiable credentials from promising pilots to global infrastructure will not be the ones with the cleverest credential format. They will be the ones who make trust scalable, extensible, bridgeable and quantum-safe. That is the layer Triveria is building, and the work in WE BUILD WP4 is where we are proving it can be done.