Identity Assertion JWT Authorization Grants is a working-group draft in the IETF's Web Authorization Protocol (oauth) working group. The work began as an individual submission in March 2024, motivated by the consent sprawl of app-to-app delegation, and was adopted by the working group. Revision-04 was published in May 2026 (expires 2026-11-22). Revision -05 is dated2026-10-30 and expires 2027-05-03; revision -06 followed on2026-10-31 (expires 2027-05-04), changing the IdP's error code for a subject token that fails validation. This site's rules and cites are verified against the -05 text (and the -04 text for the -04 ruleset), so the pinned revisions here trail the latest by one. None of it is an RFC; everything on this site treats it as the work in progress it is.
The -05 revision was shaped by a milestone cleanup in the draft's issue tracker, closed ahead of publication in late October 2026. Three issues carried the weightiest changes: #130on expiration and reuse, #132on sub and audience semantics, and #133on key discovery at the Resource AS. Their resolutions are visible in the -05 change log: reuse limits and re-submission rules spelled out (Section 4.4.4), sub documented as selected for the Resource Authorization Server (Section 5.2), and the key story pinned down - the issuer's jwks_uri plus the newid_jag_signing_alg_values_supported metadata member (Sections 4.4.1 and 7.1).
- Datatracker page - revision history and document state
- draft -05 full text - the primary source this site cites
- draft -06 full text - published October 31, 2026; this site's rules verify against -05 until a delta review lands
- GitHub repository - issues and the source of the draft
- oauth WG mailing list archive - the discussion record
Every claim the draft defines for the ID-JAG, with its requirement level (Section 3.1). Seven are REQUIRED; everything else is OPTIONAL, with one RECOMMENDED combination: the draft recommends the grant carryemail and/or aud_sub so the Resource AS can resolve the subject, including JIT provisioning. The header is a claim in practice: typ MUST be oauth-id-jag+jwt.
| Claim | Level | What it carries |
|---|---|---|
iss | REQUIRED | the issuer identifier of the IdP Authorization Server |
sub | REQUIRED | the End-User’s Subject Identifier, selected by the IdP for the Resource AS identified by aud (Section 5.2); unique when scoped iss+sub, or iss+tenant+sub for a multi-tenant issuer |
aud | REQUIRED | the issuer identifier of the Resource Authorization Server; a string or a single-element array (Section 4.4.1) |
client_id | REQUIRED | the client at the Resource AS that will act for the resource owner; MAY differ from the client’s IdP-side identifier (Section 5.1) |
jti | REQUIRED | unique token id (RFC 7519 Section 4.1.7); the hook for single-use enforcement (Section 4.4.4) |
exp | REQUIRED | expiry as a NumericDate (RFC 7519 Section 4.1.4) |
iat | REQUIRED | issued-at as a NumericDate (RFC 7519 Section 4.1.6) |
sub_id | OPTIONAL | a Subject Identifier per RFC 9493; the SAML NameID format defined in Section 3.2.1 carries the Resource AS’s SSO subject namespace |
resource | OPTIONAL | RFC 8707 resource identifiers; a string or a non-empty array of unique strings |
scope | OPTIONAL | a space-separated scope string (RFC 6749 Section 3.3) with the Resource AS’s meaning |
authorization_details | OPTIONAL | a JSON array of RFC 9396 authorization detail objects |
act | OPTIONAL | the RFC 8693 actor claim; the draft defines no processing for actor_token (Section 4.3) |
tenant | OPTIONAL | the End-User’s tenant at a multi-tenant issuer; MUST be present when the issuer is multi-tenant (Section 6.1) |
auth_time | OPTIONAL | when the End-User authenticated (OpenID Connect Core) |
acr | OPTIONAL | the authentication context class satisfied at authentication (OpenID Connect Core) |
amr | OPTIONAL | the authentication methods used (OpenID Connect Core) |
aud_tenant | OPTIONAL | the Resource AS’s tenant, present only when the RAS is multi-tenant and the IdP knows the identifier; aud + aud_tenant and aud_sub MUST be unique within the RAS |
aud_sub | OPTIONAL | the Resource AS’s own identifier for the End-User (OpenID Connect Enterprise Extensions) |
email | OPTIONAL | the End-User’s e-mail address (OpenID Connect Core Section 5.1) |
Sources: Sections 3.1 and 3.2.1 of draft -05; the referenced RFCs carry their own sections as noted. Rule-by-rule enforcement of each row: the rules explorer.
Discovery runs on OAuth 2.0 Authorization Server Metadata (RFC 8414). The draft adds or repurposes five members across the IdP's metadata, the Resource AS's metadata, and client metadata - and binds the advertisement to the grant types with two MUSTs, which is where misconfigurations surface (Sections 7.1, 7.2, 8).
| Member | Where | The rule |
|---|---|---|
identity_chaining_requested_token_types_supported | IdP AS metadata (Section 7.1) | SHOULD include urn:ietf:params:oauth:token-type:id-jag to advertise that the IdP issues ID-JAGs via Token Exchange; the member is defined by the identity-chaining draft |
id_jag_signing_alg_values_supported | IdP AS metadata (Section 7.1) | OPTIONAL JSON array of the algorithms the IdP signs ID-JAGs with; when present it MUST include RS256. Deliberately separate from id_token_signing_alg_values_supported: an IdP may sign grants differently from ID Tokens |
authorization_grant_profiles_supported | Resource AS metadata (Section 7.2) | MUST be a JSON array of strings; SHOULD include urn:ietf:params:oauth:grant-profile:id-jag. Advertising means the processing rules are implemented - not that any particular issuer, tenant, or request will be accepted |
grant_types_supported | Resource AS metadata (Section 7.2) | a Resource AS advertising the id-jag profile MUST also include urn:ietf:params:oauth:grant-type:jwt-bearer - the grant it redeems ID-JAGs with |
authorization_grant_profiles_supported | Client metadata (Section 8) | via Dynamic Client Registration (RFC 7591) or a Client ID Metadata Document; a client advertising the profile MUST also carry both urn:ietf:params:oauth:grant-type:token-exchange and urn:ietf:params:oauth:grant-type:jwt-bearer in its grant_types |
Check a real advertisement against these rules in the validator's Metadata tab.
| Rev | When | What changed (condensed from the draft's own document history) |
|---|---|---|
| -00 | adopted working-group draft | initial revision as adopted by the OAuth working group |
| -01 | first working-group revision | ID-JAG definition moved to the document root; standard OAuth role names adopted; proposed tenant claim; authentication claims from the ID Token |
| -02 | multi-tenant + RAR groundwork | Rich Authorization Requests authorization_details examples; refresh token as an optional subject_token input; DPoP usage described; aud_tenant and aud_sub claims added |
| -03 | generalization | terms section added; language generalized beyond enterprise deployments; resource/audience roles in Token Exchange clarified; authorization_grant_profiles_supported metadata added |
| -04 | May 2026 | XAA vs ID-JAG terminology settled; the SAML NameID sub_id claim added for Resource ASs resolving users by SAML; client metadata property for DCR and CIMD; cross-domain use restriction |
| -05 | October 30, 2026 (expires May 3, 2027) | invalid_target and resource governance; subject-token storage considerations; mTLS binding alongside DPoP; single-audience limit on Token Exchange; id_jag_signing_alg_values_supported; sub documented as selected for the Resource AS; access_denied profiled alongside invalid_grant; reuse limits clarified; SAML NameID stability and scope rules tightened |
| -06 | October 31, 2026 (expires May 4, 2027) | the IdP Authorization Server error for a subject token that fails validation changed from invalid_grant to invalid_request (as RFC 8693 Section 2.2.2 requires); rationale documented for using access_denied rather than invalid_target when the Client or End-User is not authorized for the target |
Primary source: the Document History appendix of draft -05 (the -06 row comes from the -06 history); adoption and publication dates cross-checked against the datatracker record.
The draft's requirements run on BCP 14 (Section 2): the keywords mean exactly what RFC 2119 and RFC 8174 say, and only in all caps. Reading the capitalization is reading the enforcement model:
| Keywords | Where they bite | How the engine grades them |
|---|---|---|
| MUST / MUST NOT / REQUIRED | absolute requirements (BCP 14: RFC 2119 with RFC 8174’s all-caps rule, cited in Section 2). They concentrate in the processing rules: claim presence and shapes (Section 3.1), the IdP’s exchange processing (Section 4.3.3), and the Resource AS’s validation set (Section 4.4.1). | a failed rule in this class is rejection-grade: invalid_grant |
| SHOULD / SHOULD NOT / RECOMMENDED | strong defaults that legitimate exceptions can override: ES256 support at the Resource AS (Section 3), carrying email and/or aud_sub (Section 3.1), withholding refresh tokens (Section 4.4.4), the metadata advertisements (Sections 7 and 8). | graded informational: reported, never rejection-grade |
| MAY / OPTIONAL | genuinely discretionary: accepting refresh tokens as subject tokens (Section 4.3), enforcing jti single-use (Section 4.4.4), narrowing requested grants by policy (Section 4.3.3), the act claim (Section 3.1). | rules a token alone cannot decide render external: the validator says what it would need |
The grading (invalid_grant / informational / external) is what the validator console shows on every verdict row.
Normative - the documents the draft builds on:
- draft-ietf-oauth-identity-assertion-authz-grant-05 (work in progress) - this page's primary source
- RFC 2119 and RFC 8174 - BCP 14, the keywords
- RFC 6749 - The OAuth 2.0 Authorization Framework
- RFC 7519 - JSON Web Token (JWT)
- RFC 7521 - Assertion Framework for OAuth 2.0
- RFC 7523 - JWT Profile for OAuth 2.0 Authorization Grants
- RFC 7591 - OAuth 2.0 Dynamic Client Registration
- RFC 8414 - OAuth 2.0 Authorization Server Metadata
- RFC 8693 - OAuth 2.0 Token Exchange
- RFC 8707 - Resource Indicators for OAuth 2.0
- RFC 8725 - JSON Web Token Best Current Practices
- RFC 9396 - OAuth 2.0 Rich Authorization Requests
- RFC 9493 - Subject Identifiers for Security Event Tokens
- RFC 9728 - OAuth 2.0 Protected Resource Metadata
- draft-ietf-oauth-identity-chaining-17 (work in progress)
- OpenID Connect Core 1.0
- OpenID Connect Enterprise Extensions 1.0
- SAML 2.0 Core (OASIS)
Informative - context:
- Datatracker: draft-ietf-oauth-identity-assertion-authz-grant
- oauth-wg/oauth-identity-assertion-authz-grant - the draft's issue tracker
- How XAA works - the flagship explainer on this site