OpenID Federation
OpenID Federation is an OpenID Foundation standard for establishing trust between large numbers of organisations. Every participant publishes signed metadata about itself, and a verifier follows a chain of signed statements from that participant up to a Trust Anchor it already trusts, instead of maintaining its own list of who to trust.
Every participant has an Entity Identifier, an https URL, and publishes a signed Entity Configuration about itself under the path .well-known/openid-federation. Each organisation above it in the hierarchy publishes a Subordinate Statement about the one below it. Collecting those statements upwards gives a Trust Chain, and validating that chain against a Trust Anchor is what establishes trust.
A Trust Anchor, or an intermediate acting on its behalf, can attach a metadata policy to its statements, constraining what the parties below it may claim. Operators such as value, one_of, subset_of and essential let a federation pin a required setting centrally instead of trusting every participant to configure it. Trust Marks sit alongside that: signed statements from an accreditation authority that a participant meets a set of requirements.
In practice, an organisation joins the federation once instead of negotiating a bilateral agreement with every counterparty. Intermediates can stay hidden from the verifier while still forming part of the chain, so a group structure does not have to be exposed to be verifiable. And because the policy travels with the chain, software can decide on its own whether a counterparty meets the rules.
OpenID Federation 1.0 became a Final OpenID Foundation specification in February 2026. In May 2026 it was split into OpenID Federation 1.1, the protocol-independent trust infrastructure, and OpenID Federation for OpenID Connect 1.1, the OpenID Connect and OAuth 2.0 bindings. A wallet profile, OpenID Federation for Wallet Architectures, is still a draft.
In Europe, it is not what the EUDI Wallet rules require. The ARF does not mention it: a Relying party proves who it is to a Wallet Unit with an X.509 access certificate, and there is deliberately no Trusted List of relying parties. OpenID Federation is instead the trust layer some ecosystems have adopted on their own, such as Italy's national eID scheme, and DIIP v5 offers it as an optional way to establish trust.
Is OpenID Federation required for the EUDI Wallet?
No. The Architecture and Reference Framework does not mention OpenID Federation anywhere, and it answers the same question a different way: a relying party proves who it is with an X.509 access certificate issued by an Access Certificate Authority, and there is deliberately no Trusted List of relying parties, because the number of them across the Union would make one unworkable.
That does not make OpenID Federation marginal. It is a Final OpenID Foundation specification, Italy's national eID scheme runs on it, and DIIP v5 offers it as an optional way to establish trust. Read it as a trust layer you may need for a specific ecosystem, not as something the EUDI Wallet rules oblige you to build.
What is the difference between OpenID Federation and a Trusted List?
Both answer the question of who a verifier should trust, but they distribute the answer differently. A Trusted List is a document published by one authority that enumerates the parties it vouches for, so a verifier downloads the list and checks whether the issuer appears on it. OpenID Federation pushes that outwards: every participant publishes its own signed metadata, and trust is worked out per request by walking the chain of statements up to a trust anchor.
The consequence is a difference in scale and delegation. A Trusted List is maintained centrally and grows with every participant it covers, while a federation can delegate to intermediates and carry policy down the chain. That is why the EU keeps Trusted Lists for the relatively small set of qualified trust service providers and uses certificates rather than a list for the far larger set of relying parties.