The parts bin

Client ID Metadata Document WG draft

draft-ietf-oauth-client-id-metadata-document

The client's ID is an HTTPS URL that serves its own metadata. No registration call, no shared secret, and one identifier that means the same thing at every authorization server. The key that makes registration-free agents work. Used in scenario 02.

JWT Profile for Client Authentication and Authorization Grants RFC 7523

Two things at once: private_key_jwt client authentication, and the JWT bearer grant that identity chaining is built on. Used in 00 and 05.

Mutual TLS Client Authentication and Certificate-Bound Tokens RFC 8705

Client authentication and sender-constrained tokens at the transport layer. The right answer where your infrastructure already does mTLS; DPoP is the answer where it doesn't.

Attestation-Based Client Authentication WG draft

draft-ietf-oauth-attestation-based-client-auth

The environment vouches for the client instance, so the instance needs no long-lived credential on disk. This is where posture assessment — the signals the platform evaluated before it would issue anything — reaches the token endpoint. It answers "prove this agent is what its publisher shipped" for an authorization server that trusts the attester; doing that for a stranger is still open.

SPIFFE Client Authentication WG draft

draft-ietf-oauth-spiffe-client-auth

Lets a workload authenticate to an authorization server using the SPIFFE identity its platform already issued. If your agents run in a mesh that does workload identity, this is the bridge from that identity to an OAuth token.

Dynamic Client Registration RFC 7591

The original answer to unregistered clients, and what the first wave of MCP servers used. Still useful; increasingly the fallback rather than the plan, because the identifiers it mints are local and meaningless elsewhere.

DPoP RFC 9449

Application-layer proof of possession. The token is bound to a key the client holds and every request carries a fresh signature over the method, URL and token. Copy the token out of a log and it does nothing. The highest-value single change on this list.

Resource Indicators RFC 8707

The client names which API a token is for, and the authorization server audience-binds it. This is the structural defense against the confused deputy — an agent holding six tokens can't be tricked into a useful mistake.

PKCE RFC 7636

Binds an authorization code to the client that requested it. Mandatory in OAuth 2.1 and non-negotiable for anything an agent does.

Pushed Authorization Requests RFC 9126

The client sends request parameters directly to the authorization server and gets back a reference. Nothing sensitive passes through a browser, requests can be large, and the consent screen renders from what the server actually received. Essential once you're sending authorization details.

Authorization Server Issuer Identification RFC 9207

Puts the issuer in the authorization response so a client talking to several servers can't be fed a response from the wrong one. One parameter, one whole attack class.

JWT Profile for Access Tokens RFC 9068

A standard shape for a JWT access token, so resource servers can validate locally and agree on what the claims mean. Matters more as the number of parties in a chain grows.

Protected Resource Metadata RFC 9728

An API declares which authorization server protects it, which scopes exist, and what token types it needs — discoverable from a 401. The step that makes meeting a stranger possible.

Authorization Server Metadata RFC 8414

The authorization server publishes its endpoints, supported grants, authentication methods and algorithms. Everything an agent needs to construct a correct request without documentation.

Device Authorization Grant RFC 8628

Show a code, let the user approve on another device, poll for the result. Notable for establishing authorization_pending as a legitimate state rather than a failure — the pattern everything asynchronous still uses.

CIBA OpenID

The client names the user; the authorization server pushes an approval prompt to them directly. No redirect at all. The natural transport for approvals when the agent is running unattended.

Cross-Device Flows: Best Current Practice RFC 10027

Approving on device B what device A requested is also the shape of a good phishing attack. Read this before shipping a device-grant or CIBA flow.

OAuth 2.0 for First-Party Applications WG draft

draft-ietf-oauth-first-party-apps

A native authorization API for apps the provider controls, so first-party clients don't need a browser redirect. Relevant when the agent genuinely is the user's own software rather than a third party.

Rich Authorization Requests RFC 9396

Structured authorization_details in place of a scope string. Consent describes the operation; the token carries it; the resource enforces it exactly. Used in scenario 03.

RAR Metadata and Error Remediation WG draft

draft-ietf-oauth-rar-metadata-remediation

Lets an authorization server advertise which authorization details types it supports and return structured errors a client can act on. The piece that lets RAR be negotiated with a stranger instead of agreed bilaterally.

Step Up Authentication Challenge RFC 9470

A resource server rejects a request and says what it needs — fresher authentication, stronger authentication — and the client goes and gets it. The precedent for letting the resource, not the client, set the bar.

Transaction Authorization Challenge Individual

draft-rosomakho-oauth-txn-challenge · June 2026

A resource issues a signed challenge describing a specific operation; a human approves it at the authorization server; the resulting token proves the approval. Makes human-in-the-loop verifiable by the party that has to enforce it. Used in scenario 04.

Token Exchange RFC 8693

Trade one token for another, with act naming the actor operating on the subject's behalf and may_act constraining who is allowed to. The foundation under both of the next two entries.

Identity and Authorization Chaining Across Domains RFC queue

draft-ietf-oauth-identity-chaining · approved, awaiting an RFC number

Token exchange plus JWT bearer grants, composed so a client in one trust domain can obtain a token in another without either side accepting foreign tokens. Used in scenario 05.

Identity Assertion JWT Authorization Grant WG draft

draft-ietf-oauth-identity-assertion-authz-grant · "ID-JAG" / Cross-App Access

The enterprise profile of identity chaining: an IdP exchanges a user's identity for a short-lived, audience-bound grant so one SaaS app can reach another's API under admin policy.

Transaction Tokens WG draft

draft-ietf-oauth-transaction-tokens

A short-lived, internally-scoped token carrying immutable call context through a fan-out, so the eleventh service knows who asked and what was authorized. Used in scenario 06.

Token Revocation RFC 7009

An endpoint for killing a token or the grant behind it. Simple, ubiquitous, and only covers one authorization server.

Token Introspection RFC 7662

Ask the authorization server whether a token is still good and what it means. RFC 9701 adds a signed JWT response so the answer is verifiable.

Refresh Token and Authorization Expiration WG draft

draft-ietf-oauth-refresh-token-expiration

Lets the server tell the client when the underlying authorization expires, not just the current token. An unattended agent can renew at a sensible moment instead of failing in the middle of a task.

Shared Signals Framework, CAEP & RISC OpenID

Near-real-time notification between parties that a session ended, a credential changed, risk was elevated or a grant was revoked — CAEP for continuous access evaluation, RISC for risk and incident signals. Any participant can subscribe, and the receiving side is expected to act: discard cached tokens, re-acquire with tighter constraints, or re-run policy before allowing the next call. Cached authorization is not supposed to outlive the signal that killed it. Specified, profiled for interoperability, and increasingly treated as a requirement rather than an extra — the lag is deployment, not the spec.

OAuth 2.1 WG draft

draft-ietf-oauth-v2-1

Consolidates OAuth 2.0 and its extensions with the bad options removed: PKCE required, implicit and password grants gone, exact redirect URI matching. The baseline MCP now builds on, and the right starting point for anything new.

OAuth 2.0 Security Best Current Practice RFC 9700

Fifteen years of attacks and the mitigations for them, in one document. An update is in progress in the working group.

OAuth 2.0 for Browser-Based Applications RFC 10017

How to handle tokens when part of your agent's surface is a web app. Mostly: don't keep them in the browser.

AI Agent Authentication and Authorization Individual

draft-klrc-aiagent-auth

An informational draft making the same argument this site makes, from the other end: how the existing identity and authorization standards compose into a framework for agents, what each layer is responsible for, and which requirements are genuinely new. Read it for the parts this site treats lightly — identifying an individual running instance, monitoring and audit, and the policy the whole thing is configured by.

MCP Authorization Protocol spec

Not an IETF document, but the place these building blocks are being assembled in public: OAuth 2.1 resource servers, protected resource metadata, resource indicators, issuer validation, and client ID metadata documents as the preferred registration path.