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 Updated: 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, published on May 5, 2026 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.

How It Works

An entity publishes signed federation metadata about itself. 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.

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, and OAuth Client ID Metadata Documents. 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.

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.

Governance Pattern

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. 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, and incident response.

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