OpenID Federation explained
Two organisations can agree to trust each other with a contract and a phone call. A European wallet ecosystem has tens of thousands of organisations in it, and nobody is going to sign a contract with every one of them. OpenID Federation is the mechanism that lets them all check each other against a shared authority instead. It became a finished specification in February 2026.
The problem it solves
When a verifier receives a credential it has to answer one question before it even looks at the data: do I accept this issuer? The straightforward answer is a list, maintained by hand, of every issuer that has been vetted. That works until the list has to cover a sector, then a country, then a continent.
Agreements made one pair at a time do not scale, and neither does a single flat list somebody has to keep correct for everybody. OpenID Federation replaces both with a structure: one authority at the top that every participant already trusts, and a verifiable path from any participant up to it.
How a trust chain works
Every participant publishes one signed document about itself, at a fixed address on its own domain. It says who the organisation is, which roles it plays, and which keys it signs with. On its own that document proves nothing, because anyone can publish a claim about themselves.
Trust anchor
The authority every participant already accepts: a regulator, a ministry or the owner of the scheme. Its public key is configured once in every participant, and every chain has to end here.
Example: The Ministry of Education, as the authority behind a federation for education credentials.
Intermediate
A body that admits participants on the anchor’s behalf, such as a national register or a sector association. For each organisation it has admitted it publishes a signed statement saying so.
Example: The national register of accredited higher education institutions, which admits every recognised university and college.
Leaf entity
The issuer, verifier or wallet provider doing the actual work. It publishes one signed document about itself on its own domain and has nothing registered below it.
Example: A university that issues diplomas to its graduates as verifiable credentials.
What makes it trustworthy is the statement above it. The body that admitted the participant publishes a signed statement about it, and if that body was itself admitted somewhere, the step repeats. The sequence of statements running up to the trust anchor is the trust chain. A verifier that trusts the anchor can check the whole thing without ever having heard of the participant before.
Take the example in the diagram. An employer in another country receives a diploma credential from a graduate. It has never heard of the university, but its software is configured with the ministry’s key. It fetches the university’s own document, the register’s statement about the university and the ministry’s statement about the register, checks each signature against the key one level up, and ends at the key it already trusts. The diploma is accepted without the employer ever contacting the university.
What the federation can enforce
A federation is more than a membership list. Each statement in the chain can carry policy: rules that narrow what the participant below is allowed to declare about itself. A body can pin a setting to one value, restrict a choice to an approved set, insist that a setting is present at all, or fill in a default where the participant left one out.
That turns a scheme’s written rules into something applied by machine, at the moment of the exchange. A participant cannot quietly widen its own permissions, because what counts is the result after the policy of every body above it has been applied, not whatever it published about itself.
Trust marks
Membership answers whether an organisation belongs. It does not answer whether it has been audited, certified or accredited for a particular purpose. A trust mark is a separate signed statement from an accreditation body saying exactly that, carried alongside the organisation’s own document and checkable on its own.
One organisation can hold several of them, for different schemes or different levels. A verifier accepts the marks its own rules demand and ignores the rest, which is how one federation can serve sectors with very different requirements.
How finished is this?
The core specification is done. The OpenID Foundation approved OpenID Federation 1.0 as a Final Specification on 17 February 2026, after nine and a half years of drafts, and followed it with OpenID Federation 1.1 on 6 May 2026. Final means the format and the processing rules are settled and implementations can be built on them.
The wallet profile is not there yet. OpenID Federation for Wallet Architectures, which defines the wallet provider, credential issuer and credential verifier roles on top of the core, was still a draft in February 2026. Expect the trust chain itself to stay as it is, and the wallet role definitions to keep moving.
Where it fits in the EUDI Wallet
The European framework does not run on one mechanism. Trusted lists, registers and certificates carry the regulated part: trusted lists name the qualified trust service providers, relying parties prove who they are with an access certificate rather than by appearing on a list, and wallet units carry an attestation from their provider. OpenID Federation sits next to that, not in place of it.
Where it earns its place is everything the regulation does not enumerate: sector schemes, cross-border pilots, and the long tail of issuers and verifiers no central list is going to maintain by hand. Italy’s national eID scheme, for example, already combines the two, with the federation handling membership and policy and the certificates carrying the legally recognised identities.
What this means for you
Issuer
You register once with the body that admits you and publish one document on your own domain. From that day on every verifier in the federation can check you, with no onboarding conversation per counterparty.
Verifier
You configure one trust anchor and accept anyone who can prove a path to it, with the scheme’s own rules applied for you. The list of issuers you accept stops being something you maintain.
Wallet provider
Your wallets can work out at runtime whether the party in front of them belongs to the federation and what it is accredited for, instead of shipping a list that is out of date the week after release.
Related terms
Frequently asked questions
Is this the same thing as a PKI?
No, and the two solve different halves of the problem. A certificate chain proves that a key belongs to a named organisation. A trust chain proves that an organisation is a current member of a scheme, under rules the scheme can change without anyone reissuing anything. In practice federations are deployed next to an X.509 PKI rather than instead of one.
Who runs the trust anchor?
Whoever the participants already accept as the authority for that domain: a regulator, a ministry, a scheme owner, a sector association. The specification does not decide it. It only requires that every participant is configured with the anchor’s key, which is the one piece of trust that cannot be derived from anything else.
What happens when a member is thrown out?
The body above it stops publishing a statement about it and the chain no longer resolves. Verifiers notice on their next check rather than waiting for a revocation list, because the statements are short lived and refetched. There is also a dedicated endpoint for asking whether a particular trust mark is still valid.
Do we have to adopt this for the EUDI Wallet?
Not as a blanket requirement. The registers and trusted lists named in the regulation are what you have to deal with first. OpenID Federation becomes relevant once your scheme has more participants than a central list can realistically track, or when you need the scheme’s rules applied at the moment of the exchange. Some ecosystems already run on it, Italy’s national eID scheme among them.
Sources
This page is informational and does not constitute legal advice. For authoritative guidance consult the OpenID Foundation specifications directly.