OpenID Federation

OpenID Federation is a specification for establishing trust between many parties at once, without any two of them having exchanged configuration beforehand. OpenID Connect discovery tells a relying party where an identity provider's endpoints are but says nothing about whether that provider should be trusted, and SAML 2.0 federations answer the trust question with metadata that is either registered pairwise or aggregated and signed by an operator. OpenID Federation instead makes membership provable at request time: every participant publishes a signed statement about itself, its superior authority publishes a signed statement about it, and a verifier follows that chain of statements up to a trust anchor whose key it already holds. Trust becomes something computed from cryptographic evidence rather than something configured in advance, which is what allows a federation to reach thousands of participants without pairwise onboarding. It reached final specification status in 2026, split into OpenID Federation 1.1 for the protocol-independent trust infrastructure and OpenID Federation for OpenID Connect 1.1 for the OIDC and OAuth 2.1 bindings.

The Trust Chain

Every participant — an identity provider, a relying party, or an authority — is an entity with a URL as its identifier, and publishes an Entity Configuration at /.well-known/openid-federation: a self-signed JWT carrying its federation keys and its protocol metadata. Self-signed, it proves nothing on its own.

What makes it evidence is a Subordinate Statement, signed by the authority the entity is registered with, asserting which keys that entity legitimately holds. Authorities can be layered, so a national scheme can delegate to sector authorities and an interfederation can delegate to its national members, each issuing statements about the tier below. Resolution walks upward from the leaf through those statements until it reaches a trust anchor, and the chain verifies only if each statement is signed by a key the next statement up vouches for.

The trust anchor's own key is the one thing the chain cannot establish, and the specification deliberately leaves its distribution out of band. That makes trust anchor key management the security foundation of a deployment rather than an implementation detail: everything else is derived from it.

Policy Instead of Onboarding Agreements

Authorities do not only vouch for keys — they constrain what their subordinates may declare. A subordinate statement can carry a metadata policy whose operators pin, restrict, or default individual metadata parameters, and policies accumulate down the chain and cannot be relaxed further down. A federation that requires particular signing algorithms, permits only certain grant types, or mandates specific claims expresses that once at the authority, and it is applied to every participant during verification rather than checked during an onboarding review. This is the Policy as Code argument applied to federation configuration: the rule is enforced by the mechanism that reads it, so drift between the written agreement and the deployed configuration has nowhere to hide.

Trust marks cover the part of trust that keys cannot express. A trust mark is a signed statement from an accreditation authority that an entity conforms to a defined set of requirements — an assurance level reached, an audit passed, a sector-specific profile implemented. Because accreditation is separate from the authority that registers the entity, a relying party can demand a trust mark as an access condition instead of maintaining its own list of acceptable counterparties, and can check the issuing authority's trust mark status endpoint to see whether it still stands.

What Changes in Practice

For a relying party, the visible change is that registration can disappear. In automatic registration the relying party uses its entity identifier as the client_id and sends a signed request; the provider resolves the trust chain, derives the client's metadata from it, and applies the federation's policy. There is no registration step and no client secret to distribute or rotate. Explicit registration remains available for parties that cannot sign requests, and a resolve endpoint lets an entity delegate chain resolution rather than implement it locally.

Two operational properties deserve attention before committing. Statements carry issuance and expiry times, and a resolved chain is valid until its earliest expiry, so the effective revocation delay for a compromised or expelled participant is the statement lifetime — there is no real-time status protocol for trust chains, only a historical keys endpoint for validating signatures made in the past. Statement lifetime is therefore a security parameter traded directly against resolution load. And the administrative work does not vanish, it relocates: someone still decides who is admitted, issues their subordinate statement, and operates the anchor. What is eliminated is the pairwise exchange between every provider and every relying party, which is the part that grows quadratically.

Where It Fits

The case for OpenID Federation is multilateral ecosystems with no single operator able to configure everyone. National eID schemes run on it in production at a scale — on the order of a dozen identity providers and tens of thousands of relying parties — where pairwise registration would be untenable. The European research and education interfederation is piloting it as the successor to SAML metadata aggregation. Because the 1.1 split made the trust layer protocol-independent, the same machinery is being taken up for digital wallet ecosystems, where a verifier must establish that a credential issuer or a wallet provider is accredited before evaluating anything it presents — the trust registry problem that Verifiable Credentials and Self-Sovereign Identity deployments otherwise solve with bespoke lists. The requirement runs in both directions: under the W3C Digital Credentials API a wallet has to decide whether the verifier requesting a presentation is accredited and asking within a declared purpose, which is the same problem of provable membership seen from the other side.

It is the wrong tool inside a single organization. Enterprise SSO with one identity provider, or Third-Party Identity with a few external providers, is served better by ordinary discovery and registration; introducing trust chains there adds a resolution path and a key hierarchy to operate in exchange for scale nobody needs. Where the burden really is the number of internal integrations, an Identity Orchestration layer addresses it with a broker that each side configures against once — available precisely because the organization controls both sides, which is the assumption OpenID Federation drops. Two conditions select for it: enough participants that onboarding is the bottleneck, and an authority that all of them will genuinely accept as a trust anchor. The second is a governance question and is usually the harder one.

Cross-Organizational Trust for Agents

The question an AI agent registry cannot answer on its own is what happens at an organizational boundary: whether an agent arriving from elsewhere is registered anywhere accountable, and whether its operator belongs to something worth trusting. That is the problem OpenID Federation already solves, with signed statements establishing that an entity is a member in good standing and trust marks conveying that it meets a defined bar. The Agent-to-Agent Protocol illustrates the gap: a signed Agent Card proves origin but not standing, because nothing anchors the signing key in an accountable hierarchy. No agent identity effort has settled on federation as that anchor, and this is a reason to watch it rather than a shipped answer — but the shape of the problem is not new, and the trust infrastructure for it is final and deployed.

Summary

OpenID Federation replaces bilateral configuration with verifiable membership, and its value is proportional to how many parties have to trust each other. The parts worth evaluating are the ones an operator owns rather than the protocol: how trust anchor keys are distributed and rotated, what metadata policy the federation enforces so that participants cannot weaken it, what trust marks mean and who is entitled to issue them, and what statement lifetimes make revocation delay acceptable. Organizations joining a national, sector, or research federation will encounter it as a membership requirement. Organizations building an ecosystem — of credential issuers, of wallet verifiers, and eventually of agents crossing organizational boundaries — should assess it now, because the alternative they would otherwise build is a signed list that solves the same problem less well.