Identity Deep Dive

The identity spec map

OAuth, OpenID, workload identity and credential specifications by layer: where each one stands, what it builds on, and who documents support for it.

Adoption lists only support stated in official documentation (the vendor's or project's own, or a standards body's page naming it), and a weekly check confirms the cited phrase is still on that page. Experimental, alpha and beta support is counted separately as preview.

Statuses and sources checked: 11 November at 16:48 UTC

Moving now

Ranked by what the last 90 days brought: new revisions, explanations on this site, and mailing-list threads that name the draft.

  1. WIMSE HTTP Message Signatures10 signals in 90 daysWeekly WIMSE GitHub digest: new issues on HTTP-Sig test vectors, nonce examples and shared trust anchors, plus a spelling-fix PR
  2. AI Identity Management System (AIMS)9 signals in 90 daysThe evidence-binding authors will narrow a claim about suspended prior actors so it no longer conflicts with RFC 8693 Section 4.1.
  3. Selective Disclosure for JWTs (SD-JWT)6 signals in 90 daysIn oauth-delegate-sd-jwt, cnf, exp, nbf and the other security claims move out of delegate_payload into the base KB-SD-JWT payload, with defined semantics.
  4. Transaction Tokens5 signals in 90 daysThe evidence-binding authors will narrow a claim about suspended prior actors so it no longer conflicts with RFC 8693 Section 4.1.
  5. Identity and Authorization Chaining4 signals in 90 daysAn IETF 127 hackathon plan for WIMSE agent call chains drew proposed negative test scenarios centred on revocation and fail-closed checks.
  6. SD-JWT-based Verifiable Credentials (SD-JWT VC)4 signals in 90 daysThe Secdir reviewer rates draft-ietf-oauth-sd-jwt-vc-26 as Ready, with all earlier concerns resolved.

Grants and flows

Security practice

Delegation and chaining

Token formats

Sender-constrained tokens

Discovery and registration

Workload identity

Verifiable credentials

Identity and profiles

Authorization APIs

Security events

Every spec

Grants and flows

OAuth 2.0

Published RFCRFC 6749

The base authorization framework: a client gets an access token from an authorization server and presents it to a resource server.

Relations diagram
flowchart LR
  s_oauth2["OAuth 2.0"]
  s_oauth21["OAuth 2.1"]
  s_pkce["PKCE"]
  s_par["Pushed Authorization Requests"]
  s_rar["Rich Authorization Requests"]
  s_device_grant["Device Authorization Grant"]
  s_first_party_apps["OAuth for First-Party Apps"]
  s_token_exchange["Token Exchange"]
  s_jwt_bearer["JWT Bearer Grant and Client Authentication"]
  s_introspection["Token Introspection"]
  s_dpop["DPoP"]
  s_mtls["Mutual-TLS Client Authentication and Certificate-Bound Tokens"]
  s_attestation_client_auth["Attestation-Based Client Authentication"]
  s_as_metadata["Authorization Server Metadata"]
  s_dcr["Dynamic Client Registration"]
  s_openid4vci["OpenID for Verifiable Credential Issuance"]
  s_openid4vp["OpenID for Verifiable Presentations"]
  s_oidc_core["OpenID Connect Core"]
  s_oauth_security_bcp["OAuth 2.0 Security Best Current Practice"]
  s_browser_based_apps["OAuth 2.0 for Browser-Based Applications"]
  s_native_apps["OAuth 2.0 for Native Apps"]
  s_iss_authz_response["Authorization Server Issuer Identification"]
  s_jar["JWT-Secured Authorization Request"]
  s_refresh_token_expiration["Refresh Token and Authorization Expiration"]
  s_revocation["Token Revocation"]
  s_aims["AI Identity Management System"]
  style s_oauth2 stroke-width:3px
  s_oauth21 -->|Would replace| s_oauth2
  s_pkce -->|Extends| s_oauth2
  s_par -->|Extends| s_oauth2
  s_rar -->|Extends| s_oauth2
  s_device_grant -->|Extends| s_oauth2
  s_first_party_apps -->|Extends| s_oauth2
  s_token_exchange -->|Extends| s_oauth2
  s_jwt_bearer -->|Extends| s_oauth2
  s_introspection -->|Extends| s_oauth2
  s_dpop -->|Extends| s_oauth2
  s_mtls -->|Extends| s_oauth2
  s_attestation_client_auth -->|Extends| s_oauth2
  s_as_metadata -->|Extends| s_oauth2
  s_dcr -->|Extends| s_oauth2
  s_openid4vci -->|Builds on| s_oauth2
  s_openid4vp -->|Builds on| s_oauth2
  s_oidc_core -->|Builds on| s_oauth2
  s_oauth_security_bcp -->|Works with| s_oauth2
  s_browser_based_apps -->|Extends| s_oauth2
  s_native_apps -->|Extends| s_oauth2
  s_iss_authz_response -->|Extends| s_oauth2
  s_jar -->|Extends| s_oauth2
  s_refresh_token_expiration -->|Extends| s_oauth2
  s_revocation -->|Extends| s_oauth2
  s_aims -->|Builds on| s_oauth2

Explainer

Documented support

No sourced support entries collected yet. This says nothing about how widely it is used.

OAuth 2.1

Working-group draftdraft-ietf-oauth-v2-1-172026-10-31

Consolidates OAuth 2.0 with its security best practice: PKCE for all code flows, no implicit or password grants, exact redirect URI matching.

Relations diagram
flowchart LR
  s_oauth21["OAuth 2.1"]
  s_oauth2["OAuth 2.0"]
  s_pkce["PKCE"]
  s_deferred_token_response["Deferred Token Response"]
  style s_oauth21 stroke-width:3px
  s_oauth21 -->|Would replace| s_oauth2
  s_oauth21 -->|Builds on| s_pkce
  s_deferred_token_response -->|Extends| s_oauth21

Explainer

Documented support

No sourced support entries collected yet. This says nothing about how widely it is used.

PKCE

Published RFCRFC 7636

Binds an authorization code to the client that requested it with a one-time secret, so an intercepted code cannot be redeemed.

Relations diagram
flowchart LR
  s_pkce["PKCE"]
  s_oauth2["OAuth 2.0"]
  s_oauth21["OAuth 2.1"]
  s_fapi2["FAPI 2.0 Security Profile"]
  s_native_apps["OAuth 2.0 for Native Apps"]
  style s_pkce stroke-width:3px
  s_pkce -->|Extends| s_oauth2
  s_oauth21 -->|Builds on| s_pkce
  s_fapi2 -->|Builds on| s_pkce
  s_native_apps -->|Builds on| s_pkce

Explainer

Documented support

No sourced support entries collected yet. This says nothing about how widely it is used.

Pushed Authorization Requests (PAR)

Published RFCRFC 9126

The client sends the authorization request to the server over a back channel first and passes only a reference through the browser.

Relations diagram
flowchart LR
  s_par["Pushed Authorization Requests"]
  s_oauth2["OAuth 2.0"]
  s_fapi2["FAPI 2.0 Security Profile"]
  s_jar["JWT-Secured Authorization Request"]
  style s_par stroke-width:3px
  s_par -->|Extends| s_oauth2
  s_fapi2 -->|Builds on| s_par
  s_jar -->|Works with| s_par

Explainer

Documented support

  • PingFederate (Identity provider): Pushed authorization request endpoint source (verified 2026-11-11)
  • Keycloak (Identity provider): PAR is listed as a supported server feature source (verified 2026-11-11)
  • Spring Authorization Server (Library): Pushed authorization request endpoint source (verified 2026-11-11)
  • Duende IdentityServer (Library): RFC 9126 is listed in its supported specifications source (verified 2026-11-11)

Rich Authorization Requests (RAR)

Published RFCRFC 9396

Replaces coarse scope strings with structured authorization_details, such as a specific payment with an amount and a recipient.

Relations diagram
flowchart LR
  s_rar["Rich Authorization Requests"]
  s_oauth2["OAuth 2.0"]
  s_rar_metadata_remediation["RAR Metadata and Error Remediation"]
  style s_rar stroke-width:3px
  s_rar -->|Extends| s_oauth2
  s_rar_metadata_remediation -->|Extends| s_rar

Explainer

Documented support

  • Auth0 (Identity provider): authorization_details in the authorization code flow with PAR, and in CIBA source (verified 2026-11-11)
  • PingFederate (Identity provider): Supports OAuth rich authorization requests source (verified 2026-11-11)
  • node-oidc-provider (Library): RFC 9396 is in its list of implemented specs source (verified 2026-11-11)

Device Authorization Grant

Published RFCRFC 8628

Lets devices without a browser or keyboard, such as TVs and CLIs, get tokens while the user approves on another device.

Relations diagram
flowchart LR
  s_device_grant["Device Authorization Grant"]
  s_oauth2["OAuth 2.0"]
  s_cross_device_bcp["Security of Cross-Device Flows"]
  style s_device_grant stroke-width:3px
  s_device_grant -->|Extends| s_oauth2
  s_cross_device_bcp -->|Works with| s_device_grant

Explainer

Documented support

  • Microsoft Entra ID (Identity provider): Supports the device authorization grant source (verified 2026-11-11)
  • Okta (Identity provider): Device Authorization grant on org and custom authorization servers source (verified 2026-11-11)
  • Keycloak (Identity provider): Device flow is listed as a supported server feature source (verified 2026-11-11)
  • Authlib (Library): Ships a generic implementation of RFC 8628 source (verified 2026-11-11)

OAuth for First-Party Apps

WG last call or write-updraft-ietf-oauth-first-party-apps-042026-08-26

A native authorization challenge flow for apps run by the same party as the authorization server, without a browser redirect.

Relations diagram
flowchart LR
  s_first_party_apps["OAuth for First-Party Apps"]
  s_oauth2["OAuth 2.0"]
  style s_first_party_apps stroke-width:3px
  s_first_party_apps -->|Extends| s_oauth2

Explainer

Documented support

No sourced support entries collected yet. This says nothing about how widely it is used.

Authorization Server Issuer Identification

Status unknown

Adds an iss parameter to the authorization response so the client can tell which authorization server answered, a countermeasure to mix-up attacks.

Relations diagram
flowchart LR
  s_iss_authz_response["Authorization Server Issuer Identification"]
  s_oauth2["OAuth 2.0"]
  style s_iss_authz_response stroke-width:3px
  s_iss_authz_response -->|Extends| s_oauth2

Open

Documented support

No sourced support entries collected yet. This says nothing about how widely it is used.

JWT-Secured Authorization Request (JAR)

Status unknown

Carries the authorization request parameters inside a JWT, signed and optionally encrypted, passed by value or by reference, so the request gains integrity, source authentication and confidentiality.

Relations diagram
flowchart LR
  s_jar["JWT-Secured Authorization Request"]
  s_oauth2["OAuth 2.0"]
  s_jwt["JSON Web Token"]
  s_par["Pushed Authorization Requests"]
  style s_jar stroke-width:3px
  s_jar -->|Extends| s_oauth2
  s_jar -->|Builds on| s_jwt
  s_jar -->|Works with| s_par

Open

Documented support

No sourced support entries collected yet. This says nothing about how widely it is used.

Refresh Token and Authorization Expiration

Status unknown

New token endpoint response parameters that tell the client when the refresh token and the underlying user authorization expire.

Relations diagram
flowchart LR
  s_refresh_token_expiration["Refresh Token and Authorization Expiration"]
  s_oauth2["OAuth 2.0"]
  style s_refresh_token_expiration stroke-width:3px
  s_refresh_token_expiration -->|Extends| s_oauth2

Open

Documented support

No sourced support entries collected yet. This says nothing about how widely it is used.

Deferred Token Response

Status unknown

Lets the token endpoint answer with a deferral code and polling interval instead of a token, so any grant can complete asynchronously by polling or callback.

Relations diagram
flowchart LR
  s_deferred_token_response["Deferred Token Response"]
  s_oauth21["OAuth 2.1"]
  style s_deferred_token_response stroke-width:3px
  s_deferred_token_response -->|Extends| s_oauth21

Open

Documented support

No sourced support entries collected yet. This says nothing about how widely it is used.

RAR Metadata and Error Remediation

Status unknown

Metadata for discovering the authorization details types a server supports, and a standard way to signal and remediate failures caused by insufficient authorization details.

Relations diagram
flowchart LR
  s_rar_metadata_remediation["RAR Metadata and Error Remediation"]
  s_rar["Rich Authorization Requests"]
  s_as_metadata["Authorization Server Metadata"]
  style s_rar_metadata_remediation stroke-width:3px
  s_rar_metadata_remediation -->|Extends| s_rar
  s_rar_metadata_remediation -->|Works with| s_as_metadata

Open

Documented support

No sourced support entries collected yet. This says nothing about how widely it is used.

Security practice

OAuth 2.0 Security Best Current Practice

Status unknown

The current security advice for OAuth 2.0: an updated threat model, mitigations for attacks found since RFC 6749, and the deprecation of the implicit grant and other less secure modes.

Relations diagram
flowchart LR
  s_oauth_security_bcp["OAuth 2.0 Security Best Current Practice"]
  s_oauth2["OAuth 2.0"]
  s_security_topics_update["Updates to OAuth 2.0 Security BCP"]
  s_browser_based_apps["OAuth 2.0 for Browser-Based Applications"]
  style s_oauth_security_bcp stroke-width:3px
  s_oauth_security_bcp -->|Works with| s_oauth2
  s_security_topics_update -->|Extends| s_oauth_security_bcp
  s_browser_based_apps -->|Builds on| s_oauth_security_bcp

Open

Documented support

No sourced support entries collected yet. This says nothing about how widely it is used.

Updates to OAuth 2.0 Security BCP

Status unknown

Extends the security advice of RFC 6749, RFC 6750 and RFC 9700 to threats discovered after those were published.

Relations diagram
flowchart LR
  s_security_topics_update["Updates to OAuth 2.0 Security BCP"]
  s_oauth_security_bcp["OAuth 2.0 Security Best Current Practice"]
  style s_security_topics_update stroke-width:3px
  s_security_topics_update -->|Extends| s_oauth_security_bcp

Open

Documented support

No sourced support entries collected yet. This says nothing about how widely it is used.

OAuth 2.0 for Browser-Based Applications

Status unknown

Threats, consequences and best practices for single-page and other browser-based applications that use OAuth 2.0, including the backend-for-frontend pattern.

Relations diagram
flowchart LR
  s_browser_based_apps["OAuth 2.0 for Browser-Based Applications"]
  s_oauth_security_bcp["OAuth 2.0 Security Best Current Practice"]
  s_oauth2["OAuth 2.0"]
  style s_browser_based_apps stroke-width:3px
  s_browser_based_apps -->|Builds on| s_oauth_security_bcp
  s_browser_based_apps -->|Extends| s_oauth2

Open

Documented support

No sourced support entries collected yet. This says nothing about how widely it is used.

OAuth 2.0 for Native Apps

Status unknown

Native apps make authorization requests only through an external user agent, primarily the system browser, and why: the security and usability reasons, and how apps and servers implement it.

Relations diagram
flowchart LR
  s_native_apps["OAuth 2.0 for Native Apps"]
  s_oauth2["OAuth 2.0"]
  s_pkce["PKCE"]
  style s_native_apps stroke-width:3px
  s_native_apps -->|Extends| s_oauth2
  s_native_apps -->|Builds on| s_pkce

Open

Documented support

No sourced support entries collected yet. This says nothing about how widely it is used.

Security of Cross-Device Flows

Status unknown

Threats against flows that start on one device and finish on another, practical mitigations, protocol selection guidance and formal analysis results.

Relations diagram
flowchart LR
  s_cross_device_bcp["Security of Cross-Device Flows"]
  s_device_grant["Device Authorization Grant"]
  s_ciba["Client-Initiated Backchannel Authentication"]
  style s_cross_device_bcp stroke-width:3px
  s_cross_device_bcp -->|Works with| s_device_grant
  s_cross_device_bcp -->|Works with| s_ciba

Open

Documented support

No sourced support entries collected yet. This says nothing about how widely it is used.

Delegation and chaining

Token Exchange

Published RFCRFC 8693

A client trades one token for another, for example to act on behalf of a user towards a different audience.

Relations diagram
flowchart LR
  s_token_exchange["Token Exchange"]
  s_oauth2["OAuth 2.0"]
  s_identity_chaining["Identity and Authorization Chaining"]
  s_id_jag["Identity Assertion JWT Authorization Grant"]
  s_txn_tokens["Transaction Tokens"]
  style s_token_exchange stroke-width:3px
  s_token_exchange -->|Extends| s_oauth2
  s_identity_chaining -->|Builds on| s_token_exchange
  s_id_jag -->|Builds on| s_token_exchange
  s_txn_tokens -->|Builds on| s_token_exchange

Explainer

Documented support

  • Keycloak (Identity provider): Standard token exchange implementing RFC 8693 source (verified 2026-11-11)
  • Google Cloud (Cloud): Security Token Service implements the standard OAuth 2.0 token exchange source (verified 2026-11-11)
  • Okta (Identity provider): On-Behalf-Of Token Exchange on custom authorization servers source (verified 2026-11-11)

JWT Bearer Grant and Client Authentication

Published RFCRFC 7523

Uses a signed JWT as an authorization grant or as a client credential at the token endpoint.

Relations diagram
flowchart LR
  s_jwt_bearer["JWT Bearer Grant and Client Authentication"]
  s_jwt["JSON Web Token"]
  s_oauth2["OAuth 2.0"]
  s_identity_chaining["Identity and Authorization Chaining"]
  s_id_jag["Identity Assertion JWT Authorization Grant"]
  s_spiffe_client_auth["OAuth SPIFFE Client Authentication"]
  style s_jwt_bearer stroke-width:3px
  s_jwt_bearer -->|Builds on| s_jwt
  s_jwt_bearer -->|Extends| s_oauth2
  s_identity_chaining -->|Builds on| s_jwt_bearer
  s_id_jag -->|Builds on| s_jwt_bearer
  s_spiffe_client_auth -->|Profiles| s_jwt_bearer

Explainer

Documented support

No sourced support entries collected yet. This says nothing about how widely it is used.

Identity and Authorization Chaining

Approved, with the RFC Editordraft-ietf-oauth-identity-chaining-172026-08-21

Carries identity and authorization across trust domains by exchanging a token in one domain for a grant usable in another.

Relations diagram
flowchart LR
  s_identity_chaining["Identity and Authorization Chaining"]
  s_token_exchange["Token Exchange"]
  s_jwt_bearer["JWT Bearer Grant and Client Authentication"]
  s_id_jag["Identity Assertion JWT Authorization Grant"]
  style s_identity_chaining stroke-width:3px
  s_identity_chaining -->|Builds on| s_token_exchange
  s_identity_chaining -->|Builds on| s_jwt_bearer
  s_id_jag -->|Profiles| s_identity_chaining

Explainer

Documented support

No sourced support entries collected yet. This says nothing about how widely it is used.

Identity Assertion JWT Authorization Grant (ID-JAG)

Working-group draftdraft-ietf-oauth-identity-assertion-authz-grant-062026-10-31

The enterprise IdP issues a short-lived grant that lets one SSO-connected app get an access token at another app, without a consent redirect.

Relations diagram
flowchart LR
  s_id_jag["Identity Assertion JWT Authorization Grant"]
  s_identity_chaining["Identity and Authorization Chaining"]
  s_token_exchange["Token Exchange"]
  s_jwt_bearer["JWT Bearer Grant and Client Authentication"]
  style s_id_jag stroke-width:3px
  s_id_jag -->|Profiles| s_identity_chaining
  s_id_jag -->|Builds on| s_token_exchange
  s_id_jag -->|Builds on| s_jwt_bearer

ExplainerDeep dive

Documented support

  • Model Context Protocol (Specification): Enterprise-Managed Authorization extension is built on ID-JAG source (verified 2026-11-11)
  • Okta (Identity provider): Cross App Access (XAA) implements the ID-JAG flow source (verified 2026-11-11)
  • Ping Identity (PingFederate 13.1) (Identity provider): PingFederate 13.1 issues ID-JAGs through OAuth token exchange source (verified 2026-11-11)
  • Keycloak (Identity provider)experimental: Accepts ID-JAG on the receiver side only, labeled experimental source (verified 2026-11-11)

Transaction Tokens

WG last call or write-updraft-ietf-oauth-transaction-tokens-112026-08-21

Short-lived tokens that carry the user and request context through a chain of internal workloads behind an API gateway.

Relations diagram
flowchart LR
  s_txn_tokens["Transaction Tokens"]
  s_token_exchange["Token Exchange"]
  style s_txn_tokens stroke-width:3px
  s_txn_tokens -->|Builds on| s_token_exchange

Explainer

Documented support

  • IBM Verify (Identity provider): Issues transaction tokens based on draft-ietf-oauth-transaction-tokens source (verified 2026-11-11)

Token formats

JSON Web Token (JWT)

Published RFCRFC 7519

A compact, signed (or encrypted) set of claims, the format most OAuth and OpenID tokens use.

Relations diagram
flowchart LR
  s_jwt["JSON Web Token"]
  s_jwt_bearer["JWT Bearer Grant and Client Authentication"]
  s_jwt_at["JWT Access Token Profile"]
  s_jwt_bcp["JWT Best Current Practices"]
  s_sd_jwt["Selective Disclosure for JWTs"]
  s_wimse_creds["WIMSE Workload Credentials"]
  s_status_list["Token Status List"]
  s_oidc_core["OpenID Connect Core"]
  s_set["Security Event Token"]
  s_jar["JWT-Secured Authorization Request"]
  style s_jwt stroke-width:3px
  s_jwt_bearer -->|Builds on| s_jwt
  s_jwt_at -->|Profiles| s_jwt
  s_jwt_bcp -->|Works with| s_jwt
  s_sd_jwt -->|Builds on| s_jwt
  s_wimse_creds -->|Builds on| s_jwt
  s_status_list -->|Builds on| s_jwt
  s_oidc_core -->|Builds on| s_jwt
  s_set -->|Builds on| s_jwt
  s_jar -->|Builds on| s_jwt

Explainer

Documented support

No sourced support entries collected yet. This says nothing about how widely it is used.

JWT Access Token Profile

Published RFCRFC 9068

A standard layout for access tokens issued as JWTs, so resource servers from different vendors can validate them the same way.

Relations diagram
flowchart LR
  s_jwt_at["JWT Access Token Profile"]
  s_jwt["JSON Web Token"]
  s_introspection["Token Introspection"]
  style s_jwt_at stroke-width:3px
  s_jwt_at -->|Profiles| s_jwt
  s_introspection -.-|Alternative to| s_jwt_at

Explainer

Documented support

No sourced support entries collected yet. This says nothing about how widely it is used.

JWT Best Current Practices (bis)

Approved, with the RFC Editordraft-ietf-oauth-rfc8725bis-102026-11-06

Updates RFC 8725's guidance on validating JWTs safely: algorithms, explicit typing, and audience and issuer checks.

Relations diagram
flowchart LR
  s_jwt_bcp["JWT Best Current Practices"]
  s_jwt["JSON Web Token"]
  style s_jwt_bcp stroke-width:3px
  s_jwt_bcp -->|Works with| s_jwt

Explainer

Documented support

No sourced support entries collected yet. This says nothing about how widely it is used.

Token Introspection

Published RFCRFC 7662

A resource server asks the authorization server whether a token is active and what it allows.

Relations diagram
flowchart LR
  s_introspection["Token Introspection"]
  s_oauth2["OAuth 2.0"]
  s_jwt_at["JWT Access Token Profile"]
  s_revocation["Token Revocation"]
  style s_introspection stroke-width:3px
  s_introspection -->|Extends| s_oauth2
  s_introspection -.-|Alternative to| s_jwt_at
  s_revocation -->|Works with| s_introspection

Explainer

Documented support

No sourced support entries collected yet. This says nothing about how widely it is used.

Selective Disclosure for JWTs (SD-JWT)

Published RFCRFC 9901

A JWT whose holder can reveal only some of its claims, with an optional key binding proof.

Relations diagram
flowchart LR
  s_sd_jwt["Selective Disclosure for JWTs"]
  s_jwt["JSON Web Token"]
  s_sd_jwt_vc["SD-JWT-based Verifiable Credentials"]
  s_delegate_sd_jwt["Delegate SD-JWT"]
  style s_sd_jwt stroke-width:3px
  s_sd_jwt -->|Builds on| s_jwt
  s_sd_jwt_vc -->|Profiles| s_sd_jwt
  s_delegate_sd_jwt -->|Extends| s_sd_jwt

Explainer

Documented support

No sourced support entries collected yet. This says nothing about how widely it is used.

Token Revocation

Status unknown

An endpoint where a client tells the authorization server that a refresh or access token is no longer needed, invalidating it and, where applicable, other tokens from the same grant.

Relations diagram
flowchart LR
  s_revocation["Token Revocation"]
  s_oauth2["OAuth 2.0"]
  s_introspection["Token Introspection"]
  style s_revocation stroke-width:3px
  s_revocation -->|Extends| s_oauth2
  s_revocation -->|Works with| s_introspection

Open

Documented support

No sourced support entries collected yet. This says nothing about how widely it is used.

Delegate SD-JWT

Status unknown

Lets an SD-JWT holder delegate to a further holder by allowing the Key Binding JWT to itself be an SD-JWT, optionally with its own key binding; aimed at agentic systems.

Relations diagram
flowchart LR
  s_delegate_sd_jwt["Delegate SD-JWT"]
  s_sd_jwt["Selective Disclosure for JWTs"]
  style s_delegate_sd_jwt stroke-width:3px
  s_delegate_sd_jwt -->|Extends| s_sd_jwt

Open

Documented support

No sourced support entries collected yet. This says nothing about how widely it is used.

Sender-constrained tokens

DPoP

Published RFCRFC 9449

Binds tokens to a key the client holds and proves possession with a signed header on each request, at the application layer.

Relations diagram
flowchart LR
  s_dpop["DPoP"]
  s_oauth2["OAuth 2.0"]
  s_mtls["Mutual-TLS Client Authentication and Certificate-Bound Tokens"]
  s_wpt["WIMSE Workload Proof Token"]
  s_fapi2["FAPI 2.0 Security Profile"]
  style s_dpop stroke-width:3px
  s_dpop -->|Extends| s_oauth2
  s_dpop -.-|Alternative to| s_mtls
  s_wpt -.-|Alternative to| s_dpop
  s_fapi2 -->|Builds on| s_dpop

Open

Documented support

  • Okta (Identity provider): DPoP sender-constrained access tokens, based on RFC 9449 source (verified 2026-11-11)
  • Auth0 (Identity provider): DPoP sender constraining for supported grant types source (verified 2026-11-11)
  • Keycloak (Identity provider): DPoP is listed as a supported server feature source (verified 2026-11-11)
  • Duende IdentityServer (Library): DPoP (RFC 9449) is listed in its supported specifications source (verified 2026-11-11)

Mutual-TLS Client Authentication and Certificate-Bound Tokens

Published RFCRFC 8705

Authenticates the client with a TLS client certificate and binds access tokens to that certificate.

Relations diagram
flowchart LR
  s_mtls["Mutual-TLS Client Authentication and Certificate-Bound Tokens"]
  s_oauth2["OAuth 2.0"]
  s_dpop["DPoP"]
  s_wimse_mtls["WIMSE Mutual TLS"]
  s_fapi2["FAPI 2.0 Security Profile"]
  style s_mtls stroke-width:3px
  s_mtls -->|Extends| s_oauth2
  s_dpop -.-|Alternative to| s_mtls
  s_wimse_mtls -->|Works with| s_mtls
  s_fapi2 -->|Builds on| s_mtls

Open

Documented support

  • Auth0 (Identity provider): mTLS token binding (certificate-bound tokens), advertised in its discovery document source (verified 2026-11-11)
  • Spring Authorization Server (Library): tls_client_auth and self_signed_tls_client_auth client authentication (RFC 8705) source (verified 2026-11-11)
  • Duende IdentityServer (Library): RFC 8705 is listed in its supported specifications source (verified 2026-11-11)
  • node-oidc-provider (Library): RFC 8705 is in its list of implemented specs source (verified 2026-11-11)

Attestation-Based Client Authentication

WG last call or write-updraft-ietf-oauth-attestation-based-client-auth-122026-10-18

A client instance authenticates with an attestation from its backend plus a proof of possession, for apps that cannot keep a secret.

Relations diagram
flowchart LR
  s_attestation_client_auth["Attestation-Based Client Authentication"]
  s_oauth2["OAuth 2.0"]
  s_spiffe_client_auth["OAuth SPIFFE Client Authentication"]
  style s_attestation_client_auth stroke-width:3px
  s_attestation_client_auth -->|Extends| s_oauth2
  s_spiffe_client_auth -->|Profiles| s_attestation_client_auth

Open

Documented support

No sourced support entries collected yet. This says nothing about how widely it is used.

OAuth SPIFFE Client Authentication

Status unknown

Profiles RFC 7521, RFC 7523 and attestation-based client authentication so an OAuth client can authenticate with a SPIFFE SVID (JWT, WIT or X.509) instead of a client secret.

Relations diagram
flowchart LR
  s_spiffe_client_auth["OAuth SPIFFE Client Authentication"]
  s_spiffe["SPIFFE"]
  s_jwt_bearer["JWT Bearer Grant and Client Authentication"]
  s_attestation_client_auth["Attestation-Based Client Authentication"]
  style s_spiffe_client_auth stroke-width:3px
  s_spiffe_client_auth -->|Builds on| s_spiffe
  s_spiffe_client_auth -->|Profiles| s_jwt_bearer
  s_spiffe_client_auth -->|Profiles| s_attestation_client_auth

Open

Documented support

No sourced support entries collected yet. This says nothing about how widely it is used.

Discovery and registration

Authorization Server Metadata

Published RFCRFC 8414

A well-known JSON document that lists an authorization server's endpoints and capabilities.

Relations diagram
flowchart LR
  s_as_metadata["Authorization Server Metadata"]
  s_oauth2["OAuth 2.0"]
  s_prm["Protected Resource Metadata"]
  s_rar_metadata_remediation["RAR Metadata and Error Remediation"]
  style s_as_metadata stroke-width:3px
  s_as_metadata -->|Extends| s_oauth2
  s_prm -->|Works with| s_as_metadata
  s_rar_metadata_remediation -->|Works with| s_as_metadata

Open

Documented support

  • Model Context Protocol (Specification): MCP authorization spec uses RFC 8414 Authorization Server Metadata, with path insertion source (verified 2026-11-11)
  • Keycloak (Identity provider): Keycloak's MCP compliance table lists RFC 8414 as Supported source (verified 2026-11-11)

Protected Resource Metadata

Published RFCRFC 9728

A well-known document in which a resource server says which authorization servers it trusts and how to call it.

Relations diagram
flowchart LR
  s_prm["Protected Resource Metadata"]
  s_as_metadata["Authorization Server Metadata"]
  style s_prm stroke-width:3px
  s_prm -->|Works with| s_as_metadata

Open

Documented support

  • Model Context Protocol (Specification): MCP authorization spec (2025-11-25) uses RFC 9728 Protected Resource Metadata to discover the authorization server source (verified 2026-11-11)
  • Kong Gateway (OpenID Connect plugin) (Product): The OIDC plugin advertises an upstream API as an RFC 9728 protected resource source (verified 2026-11-11)

Dynamic Client Registration

Published RFCRFC 7591

Clients register themselves at an authorization server through an API instead of a manual console step.

Relations diagram
flowchart LR
  s_dcr["Dynamic Client Registration"]
  s_oauth2["OAuth 2.0"]
  s_cimd["Client ID Metadata Documents"]
  style s_dcr stroke-width:3px
  s_dcr -->|Extends| s_oauth2
  s_cimd -.-|Alternative to| s_dcr

Open

Documented support

No sourced support entries collected yet. This says nothing about how widely it is used.

Client ID Metadata Documents

Working-group draftdraft-ietf-oauth-client-id-metadata-document-032026-11-02

The client_id is an HTTPS URL that serves the client's metadata, so clients need no registration step at each server.

Relations diagram
flowchart LR
  s_cimd["Client ID Metadata Documents"]
  s_dcr["Dynamic Client Registration"]
  style s_cimd stroke-width:3px
  s_cimd -.-|Alternative to| s_dcr

Open

Documented support

  • Model Context Protocol (Specification): MCP authorization spec has clients use Client ID Metadata Documents when the authorization server indicates support source (verified 2026-11-11)
  • Ping Identity (PingFederate 13.1) (Identity provider): PingFederate 13.1 supports Client ID Metadata Documents for OAuth clients source (verified 2026-11-11)
  • Keycloak (Identity provider)experimental: Keycloak's MCP integration guide lists CIMD support as experimental source (verified 2026-11-11)

Workload identity

SPIFFE

Outside the IETF and OpenIDsource

A workload identity standard from the CNCF: SPIFFE IDs, X.509 and JWT SVIDs, and a Workload API, implemented by SPIRE.

Relations diagram
flowchart LR
  s_spiffe["SPIFFE"]
  s_wimse_arch["WIMSE Architecture"]
  s_spiffe_client_auth["OAuth SPIFFE Client Authentication"]
  s_workload_identity_practices["Workload Identity Practices"]
  s_wimse_identifier["Workload Identifier"]
  style s_spiffe stroke-width:3px
  s_wimse_arch -->|Works with| s_spiffe
  s_spiffe_client_auth -->|Builds on| s_spiffe
  s_workload_identity_practices -->|Works with| s_spiffe
  s_wimse_identifier -->|Works with| s_spiffe

Open

Documented support

  • Istio (Product): Its SPIRE integration guide sets the SPIFFE ID format workloads must use source (verified 2026-11-11)
  • Google Cloud (Cloud): Managed workload identities are based on SPIFFE source (verified 2026-11-11)
  • Anthropic (Claude API) (Product): Workload identity federation accepts SPIFFE JWT-SVIDs source (verified 2026-11-11)
  • OpenAI API (Product): Workload identity federation accepts SPIFFE JWT-SVIDs as subject tokens source (verified 2026-11-11)

WIMSE Architecture

Working-group draftdraft-ietf-wimse-arch-082026-07-06

The IETF's architecture for workload identity across systems and clouds, including tokens passed along call chains.

Relations diagram
flowchart LR
  s_wimse_arch["WIMSE Architecture"]
  s_spiffe["SPIFFE"]
  s_wimse_creds["WIMSE Workload Credentials"]
  s_aims["AI Identity Management System"]
  s_workload_identity_practices["Workload Identity Practices"]
  s_wimse_identifier["Workload Identifier"]
  style s_wimse_arch stroke-width:3px
  s_wimse_arch -->|Works with| s_spiffe
  s_wimse_creds -->|Builds on| s_wimse_arch
  s_aims -->|Builds on| s_wimse_arch
  s_workload_identity_practices -->|Works with| s_wimse_arch
  s_wimse_identifier -->|Builds on| s_wimse_arch

Open

Documented support

No sourced support entries collected yet. This says nothing about how widely it is used.

WIMSE Workload Credentials

Working-group draftdraft-ietf-wimse-workload-creds-032026-10-30

Defines the Workload Identity Token (a JWT) and the Workload Identity Certificate (X.509) that bind a key to a workload identifier.

Relations diagram
flowchart LR
  s_wimse_creds["WIMSE Workload Credentials"]
  s_wimse_arch["WIMSE Architecture"]
  s_jwt["JSON Web Token"]
  s_wpt["WIMSE Workload Proof Token"]
  s_wimse_httpsig["WIMSE HTTP Message Signatures"]
  s_wimse_mtls["WIMSE Mutual TLS"]
  style s_wimse_creds stroke-width:3px
  s_wimse_creds -->|Builds on| s_wimse_arch
  s_wimse_creds -->|Builds on| s_jwt
  s_wpt -->|Builds on| s_wimse_creds
  s_wimse_httpsig -->|Builds on| s_wimse_creds
  s_wimse_mtls -->|Builds on| s_wimse_creds

OpenDeep dive

Documented support

  • SPIFFE (Specification): The WIT-SVID spec defines every WIT-SVID as a WIMSE Workload Identity Token source (verified 2026-11-11)
  • Solo.io (Istio 1.30.x ambient) (Product)alpha: Solo's Istio ambient distribution supports WIMSE workload identity tokens as an alpha feature source (verified 2026-11-11)

WIMSE Workload Proof Token

Working-group draftdraft-ietf-wimse-wpt-022026-08-27

A per-request signed JWT that proves possession of the key in a Workload Identity Token, bound to the target and message.

Relations diagram
flowchart LR
  s_wpt["WIMSE Workload Proof Token"]
  s_wimse_creds["WIMSE Workload Credentials"]
  s_dpop["DPoP"]
  s_wimse_httpsig["WIMSE HTTP Message Signatures"]
  style s_wpt stroke-width:3px
  s_wpt -->|Builds on| s_wimse_creds
  s_wpt -.-|Alternative to| s_dpop
  s_wimse_httpsig -.-|Alternative to| s_wpt

Open

Documented support

No sourced support entries collected yet. This says nothing about how widely it is used.

WIMSE HTTP Message Signatures

With the IESGdraft-ietf-wimse-http-signature-082026-10-28

Workload-to-workload authentication by signing HTTP messages (RFC 9421) with the key in a Workload Identity Token.

Relations diagram
flowchart LR
  s_wimse_httpsig["WIMSE HTTP Message Signatures"]
  s_wimse_creds["WIMSE Workload Credentials"]
  s_wpt["WIMSE Workload Proof Token"]
  style s_wimse_httpsig stroke-width:3px
  s_wimse_httpsig -->|Builds on| s_wimse_creds
  s_wimse_httpsig -.-|Alternative to| s_wpt

Open

Documented support

No sourced support entries collected yet. This says nothing about how widely it is used.

WIMSE Mutual TLS

Working-group draftdraft-ietf-wimse-mutual-tls-032026-10-30

Workload-to-workload authentication at the transport layer with Workload Identity Certificates.

Relations diagram
flowchart LR
  s_wimse_mtls["WIMSE Mutual TLS"]
  s_wimse_creds["WIMSE Workload Credentials"]
  s_mtls["Mutual-TLS Client Authentication and Certificate-Bound Tokens"]
  style s_wimse_mtls stroke-width:3px
  s_wimse_mtls -->|Builds on| s_wimse_creds
  s_wimse_mtls -->|Works with| s_mtls

Open

Documented support

No sourced support entries collected yet. This says nothing about how widely it is used.

AI Identity Management System (AIMS)

Status unknown

Best practices for authenticating and authorizing AI agent interactions on top of the WIMSE architecture and the OAuth 2.0 family: which existing standards to apply, where the gaps are.

Relations diagram
flowchart LR
  s_aims["AI Identity Management System"]
  s_wimse_arch["WIMSE Architecture"]
  s_oauth2["OAuth 2.0"]
  style s_aims stroke-width:3px
  s_aims -->|Builds on| s_wimse_arch
  s_aims -->|Builds on| s_oauth2

Open

Documented support

No sourced support entries collected yet. This says nothing about how widely it is used.

Workload Identity Practices

Status unknown

How workloads on container orchestrators and cloud platforms get credentials for external authentication today, without managing long-lived secrets themselves.

Relations diagram
flowchart LR
  s_workload_identity_practices["Workload Identity Practices"]
  s_wimse_arch["WIMSE Architecture"]
  s_spiffe["SPIFFE"]
  style s_workload_identity_practices stroke-width:3px
  s_workload_identity_practices -->|Works with| s_wimse_arch
  s_workload_identity_practices -->|Works with| s_spiffe

Open

Documented support

No sourced support entries collected yet. This says nothing about how widely it is used.

Workload Identifier

Status unknown

A canonical URI-based identifier that names a workload within a trust domain, to be carried in X.509 certificates and JWT-based tokens for authentication, authorization and policy.

Relations diagram
flowchart LR
  s_wimse_identifier["Workload Identifier"]
  s_wimse_arch["WIMSE Architecture"]
  s_spiffe["SPIFFE"]
  style s_wimse_identifier stroke-width:3px
  s_wimse_identifier -->|Builds on| s_wimse_arch
  s_wimse_identifier -->|Works with| s_spiffe

Open

Documented support

No sourced support entries collected yet. This says nothing about how widely it is used.

Verifiable credentials

SD-JWT-based Verifiable Credentials (SD-JWT VC)

With the IESGdraft-ietf-oauth-sd-jwt-vc-262026-11-06

A credential format on SD-JWT with a type (vct), issuer key discovery and type metadata, used by digital identity wallets.

Relations diagram
flowchart LR
  s_sd_jwt_vc["SD-JWT-based Verifiable Credentials"]
  s_sd_jwt["Selective Disclosure for JWTs"]
  s_status_list["Token Status List"]
  s_openid4vci["OpenID for Verifiable Credential Issuance"]
  s_openid4vp["OpenID for Verifiable Presentations"]
  style s_sd_jwt_vc stroke-width:3px
  s_sd_jwt_vc -->|Profiles| s_sd_jwt
  s_sd_jwt_vc -->|Builds on| s_status_list
  s_openid4vci -->|Works with| s_sd_jwt_vc
  s_openid4vp -->|Works with| s_sd_jwt_vc

Open

Documented support

No sourced support entries collected yet. This says nothing about how widely it is used.

Token Status List

Approved, with the RFC Editordraft-ietf-oauth-status-list-212026-11-03

A compressed bit list that issuers publish so verifiers can check whether a token or credential has been revoked or suspended.

Relations diagram
flowchart LR
  s_status_list["Token Status List"]
  s_jwt["JSON Web Token"]
  s_sd_jwt_vc["SD-JWT-based Verifiable Credentials"]
  style s_status_list stroke-width:3px
  s_status_list -->|Builds on| s_jwt
  s_sd_jwt_vc -->|Builds on| s_status_list

Open

Documented support

No sourced support entries collected yet. This says nothing about how widely it is used.

OpenID for Verifiable Credential Issuance

FinalFinal1.0, approved September 2025

An OAuth-based API for issuing verifiable credentials into a wallet.

Relations diagram
flowchart LR
  s_openid4vci["OpenID for Verifiable Credential Issuance"]
  s_oauth2["OAuth 2.0"]
  s_sd_jwt_vc["SD-JWT-based Verifiable Credentials"]
  s_haip["OpenID4VC High Assurance Interoperability Profile"]
  style s_openid4vci stroke-width:3px
  s_openid4vci -->|Builds on| s_oauth2
  s_openid4vci -->|Works with| s_sd_jwt_vc
  s_haip -->|Profiles| s_openid4vci

Open

Documented support

  • EU Digital Identity Wallet reference implementation (Government): Reference library implementing OpenID4VCI source (verified 2026-11-11)

OpenID for Verifiable Presentations

FinalFinal1.0, approved July 2025

A protocol for a verifier to request and receive credential presentations from a wallet.

Relations diagram
flowchart LR
  s_openid4vp["OpenID for Verifiable Presentations"]
  s_oauth2["OAuth 2.0"]
  s_sd_jwt_vc["SD-JWT-based Verifiable Credentials"]
  s_haip["OpenID4VC High Assurance Interoperability Profile"]
  style s_openid4vp stroke-width:3px
  s_openid4vp -->|Builds on| s_oauth2
  s_openid4vp -->|Works with| s_sd_jwt_vc
  s_haip -->|Profiles| s_openid4vp

Open

Documented support

  • Google Wallet (Wallet): Presents ISO mdoc digital IDs to verifiers over OpenID4VP source (verified 2026-11-11)

OpenID4VC High Assurance Interoperability Profile

FinalFinal1.0, approved December 2025

Narrows OpenID4VCI and OpenID4VP options for high-assurance deployments such as government wallets.

Relations diagram
flowchart LR
  s_haip["OpenID4VC High Assurance Interoperability Profile"]
  s_openid4vci["OpenID for Verifiable Credential Issuance"]
  s_openid4vp["OpenID for Verifiable Presentations"]
  style s_haip stroke-width:3px
  s_haip -->|Profiles| s_openid4vci
  s_haip -->|Profiles| s_openid4vp

Open

Documented support

No sourced support entries collected yet. This says nothing about how widely it is used.

Identity and profiles

OpenID Connect Core

FinalFinal1.0 incorporating errata set 2

Adds authentication to OAuth 2.0: an ID Token that tells the client who signed in, plus a UserInfo endpoint.

Relations diagram
flowchart LR
  s_oidc_core["OpenID Connect Core"]
  s_oauth2["OAuth 2.0"]
  s_jwt["JSON Web Token"]
  s_ciba["Client-Initiated Backchannel Authentication"]
  style s_oidc_core stroke-width:3px
  s_oidc_core -->|Builds on| s_oauth2
  s_oidc_core -->|Builds on| s_jwt
  s_ciba -->|Extends| s_oidc_core

Explainer

Documented support

No sourced support entries collected yet. This says nothing about how widely it is used.

FAPI 2.0 Security Profile

FinalFinalapproved February 2025

A high-security profile for APIs such as open banking: PAR, PKCE and sender-constrained tokens are required.

Relations diagram
flowchart LR
  s_fapi2["FAPI 2.0 Security Profile"]
  s_par["Pushed Authorization Requests"]
  s_pkce["PKCE"]
  s_dpop["DPoP"]
  s_mtls["Mutual-TLS Client Authentication and Certificate-Bound Tokens"]
  style s_fapi2 stroke-width:3px
  s_fapi2 -->|Builds on| s_par
  s_fapi2 -->|Builds on| s_pkce
  s_fapi2 -->|Builds on| s_dpop
  s_fapi2 -->|Builds on| s_mtls

Explainer

Documented support

  • ConnectID (Australia) (Product): Adopted FAPI 2.0 for its ecosystem (stated by the OpenID FAPI working group) source (verified 2026-11-11)
  • Authlete (Product): Supports the FAPI 2.0 Security Profile source (verified 2026-11-11)

Client-Initiated Backchannel Authentication (CIBA)

FinalFinalapproved September 2021

Authentication started by the client and approved by the user on a separate device, for example at a call centre or point of sale.

Relations diagram
flowchart LR
  s_ciba["Client-Initiated Backchannel Authentication"]
  s_oidc_core["OpenID Connect Core"]
  s_cross_device_bcp["Security of Cross-Device Flows"]
  style s_ciba stroke-width:3px
  s_ciba -->|Extends| s_oidc_core
  s_cross_device_bcp -->|Works with| s_ciba

Explainer

Documented support

No sourced support entries collected yet. This says nothing about how widely it is used.

Authorization APIs

AuthZEN Authorization API

FinalFinalAuthorization API 1.0, approved January 2026

A standard request and response between a policy enforcement point and a policy decision point: subject, action, resource, decision.

Explainer

Documented support

  • OpenFGA (Product)experimental: Can run as an AuthZEN-compliant PDP (experimental flag) source (verified 2026-11-11)
  • Keycloak (Identity provider)experimental: Experimental AuthZEN Authorization API PDP support (26.7.0) source (verified 2026-11-11)

Security events

Security Event Token (SET)

Published RFCRFC 8417

A JWT that describes a security event, such as a revoked session or a changed credential.

Relations diagram
flowchart LR
  s_set["Security Event Token"]
  s_jwt["JSON Web Token"]
  s_ssf["Shared Signals Framework"]
  style s_set stroke-width:3px
  s_set -->|Builds on| s_jwt
  s_ssf -->|Builds on| s_set

Open

Documented support

No sourced support entries collected yet. This says nothing about how widely it is used.

Shared Signals Framework (SSF)

FinalFinal1.0, approved September 2025

How a transmitter and a receiver set up streams of Security Event Tokens and deliver them by push or poll.

Relations diagram
flowchart LR
  s_ssf["Shared Signals Framework"]
  s_set["Security Event Token"]
  s_caep["CAEP"]
  s_risc["RISC"]
  style s_ssf stroke-width:3px
  s_ssf -->|Builds on| s_set
  s_caep -->|Profiles| s_ssf
  s_risc -->|Profiles| s_ssf

Open

Documented support

  • Google Workspace (Product)beta: SSF receiver for CAEP session revocation (closed beta) source (verified 2026-11-11)

CAEP

FinalFinal1.0, approved September 2025

Continuous Access Evaluation Profile: SSF events about session and credential changes so relying parties can re-evaluate access.

Relations diagram
flowchart LR
  s_caep["CAEP"]
  s_ssf["Shared Signals Framework"]
  style s_caep stroke-width:3px
  s_caep -->|Profiles| s_ssf

Open

Documented support

  • Okta Identity Threat Protection (Identity provider): Receives CAEP-compliant Security Event Tokens source (verified 2026-11-11)
  • Jamf (Product): Emits CAEP-compliant signals as an SSF transmitter source (verified 2026-11-11)

RISC

FinalFinal1.0, approved September 2025

Risk Incident Sharing and Coordination: SSF events about account compromise, such as a leaked credential.

Relations diagram
flowchart LR
  s_risc["RISC"]
  s_ssf["Shared Signals Framework"]
  style s_risc stroke-width:3px
  s_risc -->|Profiles| s_ssf

Open

Documented support

  • Google Cross-Account Protection (Identity provider): Cross-Account Protection is based on RISC source (verified 2026-11-11)