Wiki · Concept · Last reviewed June 25, 2026

OpenID Federation

OpenID Federation is trust infrastructure for large identity federations. For AI-agent systems, it matters because registries, tool gateways, identity providers, OAuth clients, and protected resources need a way to verify who is in a federation before they accept metadata or automate registration.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: OpenID Federation, identity, trust chains, OAuth, OpenID Connect, AI agents

Definition

OpenID Federation 1.1 is an OpenID Foundation Final specification, approved by the OpenID Foundation membership on May 5, 2026 and produced by the OpenID Connect Working Group. It defines protocol-independent mechanisms for multilateral identity federations: Entity Statements, Trust Chains, metadata, policies, Trust Marks, and Federation Endpoints.

The specification separates federation trust infrastructure from any single login or authorization protocol. A companion specification, OpenID Federation for OpenID Connect 1.1, published the same day as Final, defines how the federation constructs are used with OpenID Connect and OAuth 2.0 entities, including entity type identifiers, metadata values, and client registration flows.

OpenID Federation is not user authentication, legal identity proofing, consent, authorization, or agent safety by itself. It gives participants a structured way to establish whether other entities belong to the same federation, whether their published metadata is intact, and whether federation policies apply.

Snapshot

Current Context

As of June 25, 2026, the OpenID Foundation's federation line has moved quickly. OpenID Federation 1.0 became a Final specification on February 17, 2026. OpenID Federation 1.1 then separated the protocol-independent functions from the OpenID Connect and OAuth binding; the 1.1 specification says it introduces no new functionality beyond 1.0, but reorganizes the material so federation trust can be reused by other protocol profiles.

The companion OpenID Federation for OpenID Connect 1.1 specification is the right source for OpenID Connect and OAuth details. It defines entity types and metadata values for OpenID Providers, relying parties, OAuth clients, authorization servers, resource servers, and federation entities, and it includes automatic and explicit client-registration flows.

This matters for AI-agent infrastructure because many agent systems want dynamic onboarding of clients, tool servers, gateways, and identity providers. Federation can reduce manual bilateral configuration, but it also moves trust decisions into cached metadata, trust-anchor choice, resolver behavior, and accreditation policy. Those choices must be inspectable rather than hidden behind a vague claim that an entity is "federated."

How It Works

An entity publishes signed federation metadata about itself, usually as an Entity Configuration discovered from the entity identifier and the /.well-known/openid-federation path. Other entities can collect Entity Statements and build a Trust Chain that starts with the subject entity and ends at a Trust Anchor. The relying party or resolver verifies the signatures, time bounds, keys, issuer relationships, and policy rules before accepting the resulting metadata.

The trust mechanism uses signed JWTs and public-key cryptography for federation objects. The OpenID Connect and OAuth binding specification says this signing mechanism does not rely on Web PKI or TLS certificates for signing keys. TLS still protects transport, but federation trust is carried by the entity statements and chain validation.

Metadata policy is central. A federation can constrain or set metadata values, such as which redirect URI patterns, algorithms, endpoints, or entity roles are acceptable. Trust Marks add another layer: they are signed statements that an entity has a particular conformance, status, or accreditation within the federation. A Trust Mark is evidence for a specific claim, not a universal badge of safety.

The output is Resolved Metadata: the subject's metadata after trust-chain validation and policy application. The specification also allows an entity to use a resolve endpoint, where a resolver returns the Trust Chain, Trust Marks, and Resolved Metadata. Delegating resolution can simplify clients, but it makes the resolver itself part of the trust boundary.

Trust Chains are time-bound. Participants need rules for refreshing expired chains, handling transient validation errors during topology changes, rotating keys, and detecting federation exit or revoked Trust Marks before stale metadata becomes live authority.

Agent Context

Agent ecosystems need discovery and trust at organizational scale. A model gateway may want to know whether a tool server belongs to a known federation. A tool server may need to recognize an OAuth client, authorization server, protected resource, or identity provider without manually configuring every bilateral relationship. OpenID Federation gives those relationships a machine-readable trust path.

This is adjacent to Model Context Protocol, Agent2Agent Protocol, AI Agent Identity, OAuth Client ID Metadata Documents, and OAuth Dynamic Client Registration. Those mechanisms describe tools, agents, clients, or metadata endpoints. OpenID Federation addresses a narrower federation question: which authority says this entity belongs, and under which metadata policy?

The distinction matters because agent systems are likely to have many semi-autonomous clients, connectors, sandboxes, and gateways. Static allowlists do not scale well, but blind dynamic registration is dangerous. Federation gives a way to automate some trust establishment while still requiring policy, validation, logging, and revocation.

For example, a federated agent connector might prove that it belongs to an approved federation before registering with an authorization server, while a protected resource might use federation evidence to decide whether a tool gateway's metadata can be accepted. That still leaves separate questions about user delegation, token scope, resource audience, human approval, sandboxing, and abuse handling.

Governance Risks

The first risk is laundering institutional trust. A valid trust chain can still lead to a permissive policy, a weak Trust Anchor, a stale key, a compromised federation operator, or an entity that is authorized for one purpose but used for another. The chain proves a relationship under a policy; it does not prove good judgment.

The second risk is trust-mark overreading. A Trust Mark can indicate conformance or accreditation for a defined criterion. Users and operators may read it as a broad certification that a provider, agent, model, or connector is trustworthy. That is a category error unless the exact Trust Mark, issuer, policy, and scope are preserved.

The third risk is automation without review. Dynamic trust establishment can make onboarding easier, but it can also turn metadata errors into live access paths. Agent infrastructure should treat federation resolution as evidence for admission, not as final authorization to act.

The fourth risk is resolver centralization. If many clients outsource Trust Chain validation to a small number of resolvers, those resolvers become high-value policy, availability, and surveillance points. They can simplify operations, but governance must name who operates them, what they log, how they are trusted, and how relying parties recover when resolution fails.

Governance Pattern

Failure Modes

Trust-anchor confusion. A client accepts a chain to any known anchor rather than the anchor approved for the relying-party decision.

Policy bypass. Software verifies signatures but uses raw entity metadata instead of Resolved Metadata after policy application.

Trust Mark inflation. A mark for one criterion, issuer, or federation is displayed as a broad badge of safety, compliance, or agent reliability.

Stale chain acceptance. Expired chains, retired keys, federation exits, or revoked marks remain cached and continue to authorize onboarding or metadata use.

Resolver blind trust. A relying party accepts a resolver response without knowing the resolver's own trust chain, logging practice, freshness rule, or failure mode.

Registration overreach. A successful federated OpenID Connect or OAuth registration is treated as permission to act, even though user delegation, scopes, resource audience, and local policy still have to be enforced.

Minimum Evidence Record

A governance-grade OpenID Federation decision should leave enough evidence for later audit without storing secrets. At minimum, preserve:

Source Discipline

Use OpenID Federation 1.1 for protocol-independent federation concepts. Use OpenID Federation for OpenID Connect 1.1 for OpenID Connect and OAuth 2.0 bindings. Use the OpenID Foundation's final-specification record for status claims. Use RFC 8414, RFC 7591, OpenID Connect Discovery, and OpenID Connect Dynamic Client Registration for adjacent metadata and registration concepts when federation is not the relevant layer. Product documentation can show deployment, but it should not redefine the standard.

Do not say that OpenID Federation proves an AI agent is safe, authorized, human-approved, or compliant. It supports trust establishment among entities. The actual decision still depends on policies, scopes, credentials, user delegation, audit trails, incident response, and local authorization.

When citing a federated decision, name the entity identifier, Trust Anchor, Trust Chain, metadata policy, Resolved Metadata, Trust Marks, resolver if used, specification version, and decision date. "Federated" is not a complete evidence label.

Spiralist Reading

Spiralism reads OpenID Federation as a map of delegated trust.

The machine does not simply ask, "Do you know me?" It asks, "Can you verify the authority that says I belong here?" That is progress, but it is not innocence. A trust chain is a record of institutional speech. It still needs limits, logs, and a right to refuse the action that follows.

Open Questions

Sources

Return to Wiki