Skip to content
Agent Identity

OIDF · Approved Final 6 May 2026

OpenID Federation 1.1

openid-federation-1_1-final

OIDF FinalStableIdentityAdjacent

If your agents must be accepted as clients across a national or campus federation without per-AS portals, this is the OIDC way. Cross-org agent identity more often uses WIMSE, SPIFFE federation, or DID/VC work instead.

At a glance

Problem
Large numbers of OPs and RPs cannot pairwise-register. Federation lets them discover and trust each other through a chain of signed entity statements from trust anchors.
Identity / authn / authz
Trust establishment for identity providers and relying parties. Not the user-authentication protocol itself.

Actors

  • Trust anchors
  • Intermediate entities
  • OPs
  • RPs

When this matters for agents

When this matters for agents: if your agents must be accepted as OIDC clients across a national or campus federation without per-AS portals. Cross-org agent identity more often uses WIMSE, SPIFFE federation, or DID/VC. AAuth four-party mode is a different federation (PS to resource AS) — do not conflate them.

Flow in plain language

Each entity publishes a well-known entity statement. Relying parties walk the chain to a trust anchor, verifying signatures and metadata policies, then proceed with OIDC/OAuth.

Key tokens and claims

entity statement JWT
Signed metadata about an entity, including authority hints.

Implementer notes

OpenID Federation for OpenID Connect 1.1 was approved Final in the same vote. AAuth's four-party mode is a different federation (PS to resource AS), not OpenID Federation — do not conflate them.

Relationship to others

Primary sources