The ID-JAG rules explorer

The JWT header "typ" MUST be "oauth-id-jag+jwt" (explicit typing per RFC 8725 Section 3.11).

iss, sub, aud, client_id, jti, exp, and iat are REQUIRED claims of the ID-JAG.

When present, resource carries the RFC 8707 Resource Identifier of the Resource Server as a single URI or an array of URIs; the engine additionally requires array entries to be non-empty unique strings.

When present, authorization_details MUST be a JSON array of authorization detail objects (RFC 9396).

When present, scope, tenant, aud_tenant, aud_sub, and email MUST each be a JSON string.

It is RECOMMENDED that the ID-JAG contain an email and/or aud_sub claim (subject resolution plus JIT provisioning).

act is OPTIONAL (RFC 8693 Section 4.1); the engine surfaces actor context informationally and never renders a verdict on it.

When both sub and sub_id are present, they MUST identify the same End-User; the engine flags the pair for confirmation.

aud + aud_tenant and aud_sub MUST be unique within the Resource Authorization Server; requires RAS-side state.

The signature MUST be validated as required by RFC 7521 Section 5.2 with an allow-listed algorithm; the engine pins verification to RS256 and ES256 and rejects alg none and every other value as rule outcomes.

The ID-JAG signature MUST verify against the issuing IdP's published keys; the engine verifies a supplied JWK, and key discovery is a host concern.

The aud claim MUST be a string or a single-element array whose element is the RAS issuer identifier; anything else is rejected (this prevents audience injection attacks).

The aud claim MUST contain the issuer identifier of the Resource Authorization Server; a mismatch is rejected with invalid_grant.

The client_id claim MUST identify the same client as the request's client authentication; a mismatch is client-continuity failure, rejected with invalid_grant.

exp and iat MUST be NumericDate values (numbers of seconds).

The assertion's Issuer must be recognized by the authorization server: the engine checks iss against the trusted issuer the host supplies (-04 states the trust; the explicit rejection enters with -05).

Subject identifiers MUST be unique when scoped with issuer (and tenant for multi-tenant issuers); requires RAS-side state.

When the RAS is multi-tenant the IdP MUST include the tenant claim (Section 6.3); needs deployment input.

The IdP must know the client_id relationship, maintained out of band; when clients use Client-ID Metadata Documents the URL client_id acts as a shared global namespace and removes the mapping.

A sub_id in the SAML NameID Subject Identifier Format MUST contain format (saml-nameid), issuer, and nameid, and MAY contain nameid_format, name_qualifier, sp_name_qualifier, and sp_provided_id; a malformed or unsupported format is rejected with invalid_grant.

The RAS MUST compare every member it uses for that issuer's subject resolution and MUST NOT resolve on the nameid value alone unless local policy says so; a nameid without scoping members is the resolution trap.

sub_id members MUST derive from the SSO <NameID> for that RAS, with optional fields present exactly when the attributes are; needs IdP-side state.

The RAS MUST reject with invalid_grant when sub_id is missing when required, malformed, or unauthorized; policy input decides.

An IdP Authorization Server SHOULD include urn:ietf:params:oauth:token-type:id-jag in identity_chaining_requested_token_types_supported.

A Resource Authorization Server SHOULD include urn:ietf:params:oauth:grant-profile:id-jag in authorization_grant_profiles_supported (advertisement means the processing rules are implemented).

A RAS advertising urn:ietf:params:oauth:grant-profile:id-jag MUST also include urn:ietf:params:oauth:grant-type:jwt-bearer in grant_types_supported.

authorization_grant_profiles_supported MUST be a JSON array of strings, each naming a supported grant profile.

A client SHOULD include urn:ietf:params:oauth:grant-profile:id-jag in its authorization_grant_profiles_supported.

A client advertising the id-jag profile MUST include both urn:ietf:params:oauth:grant-type:token-exchange and urn:ietf:params:oauth:grant-type:jwt-bearer in its grant_types.

requested_token_type is REQUIRED and must be urn:ietf:params:oauth:token-type:id-jag.

audience is REQUIRED and identifies the Resource Authorization Server for the ID-JAG.

Implementations MUST accept Identity Assertions as subject_token and MAY accept refresh tokens.

subject_token_type is REQUIRED and must be consistent with the subject_token.

actor_token is OPTIONAL and its processing is out of scope.

The IdP MUST validate the subject assertion and check its audience against the authenticated client_id.

Refresh-token subject tokens get standard refresh-grant validation at the IdP.

A refresh-token exchange SHOULD re-assemble current subject claims for the issued ID-JAG.

Granted resource, scope, and authorization_details values MUST be reflected in the issued ID-JAG.

An expired assertion MUST be rejected with invalid_grant (RFC 7521 Section 5.2).

The JWT header "typ" MUST be "oauth-id-jag+jwt" (explicit typing per RFC 8725 Section 3.11).

iss, sub, aud, client_id, jti, exp, and iat are REQUIRED claims of the ID-JAG.

When present, resource is a string or a non-empty JSON array of unique strings (RFC 8707 resource identifiers).

When present, authorization_details MUST be a JSON array of authorization detail objects (RFC 9396).

When present, scope, tenant, aud_tenant, aud_sub, and email MUST each be a JSON string.

It is RECOMMENDED that the ID-JAG contain an email and/or aud_sub claim so the RAS can perform subject resolution, including JIT provisioning.

act is OPTIONAL (RFC 8693 Section 4.1); the engine surfaces actor context informationally and never renders a verdict on it.

When both sub and sub_id are present, they MUST identify the same End-User; the engine flags the pair for confirmation.

aud + aud_tenant and aud_sub MUST be unique within the Resource Authorization Server; requires RAS-side state.

RS256 is mandatory to implement for both authorization servers (Section 5 of RFC 7523), and the Resource AS SHOULD also support ES256; the engine accepts exactly RS256 and ES256 and rejects alg none and every other value as rule outcomes.

The ID-JAG signature MUST be validated against the trusted issuer's keys (from jwks_uri) as required by RFC 7521 Section 5.2.

The aud claim MUST be a string containing the RAS issuer identifier, or an array containing exactly that one element; anything else is rejected (this prevents audience injection attacks).

The aud claim MUST contain the issuer identifier of the Resource Authorization Server; a mismatch is rejected with invalid_grant.

The RAS MUST reject the ID-JAG with invalid_grant if iss does not identify an IdP Authorization Server it trusts.

If the client authenticates, the RAS MUST reject the request with invalid_grant unless the client_id claim identifies the authenticated client.

exp and iat MUST be NumericDate values (numbers of seconds).

Subject identifiers MUST be unique when scoped with issuer (and tenant for multi-tenant issuers); requires RAS-side state.

A multi-tenant issuer MUST include the tenant claim, and the RAS MUST trust iss and tenant together; needs deployment input.

The client_id relationship may be mapped out of band; when clients use Client-ID Metadata Documents the URL client_id acts as a shared global namespace and removes the mapping.

A sub_id in the SAML NameID Subject Identifier Format MUST contain format (saml-nameid), issuer, and nameid, and MAY contain nameid_format, name_qualifier, sp_name_qualifier, and sp_provided_id; a malformed or unsupported format is rejected with invalid_grant.

Transient SAML NameID Formats (such as urn:oasis:names:tc:SAML:2.0:nameid-format:transient) MUST NOT be used: their values change across sessions and cannot serve as a cross-trust-domain identifier.

The RAS MUST NOT resolve the subject using only the nameid value unless local policy defines nameid alone as the subject identifier for that SAML issuer; a nameid without scoping members is the resolution trap.

Pairwise nameid values MUST be scoped to the Service Provider of the target RAS, with the mapping maintained; needs IdP-side state.

sub_id members MUST derive from the SSO <NameID> for that RAS, with optional fields present exactly when the attributes are; needs IdP-side state.

A RAS requiring the SAML NameID sub_id MUST reject with invalid_grant when it is missing, malformed, or unauthorized; policy input decides.

An IdP Authorization Server SHOULD include urn:ietf:params:oauth:token-type:id-jag in identity_chaining_requested_token_types_supported.

id_jag_signing_alg_values_supported, when present, MUST include RS256.

authorization_grant_profiles_supported MUST be a JSON array of strings, each naming a supported grant profile.

A Resource Authorization Server SHOULD include urn:ietf:params:oauth:grant-profile:id-jag in authorization_grant_profiles_supported (advertisement means the processing rules are implemented).

A RAS advertising urn:ietf:params:oauth:grant-profile:id-jag MUST also include urn:ietf:params:oauth:grant-type:jwt-bearer in grant_types_supported.

A client SHOULD include urn:ietf:params:oauth:grant-profile:id-jag in its authorization_grant_profiles_supported.

A client advertising the id-jag profile MUST include both urn:ietf:params:oauth:grant-type:token-exchange and urn:ietf:params:oauth:grant-type:jwt-bearer in its grant_types.

requested_token_type is REQUIRED and must be urn:ietf:params:oauth:token-type:id-jag.

audience is REQUIRED and must carry exactly one Resource Authorization Server identifier.

Implementations MUST accept Identity Assertions as subject_token and MAY accept refresh tokens.

subject_token_type is REQUIRED and must be consistent with the subject_token.

actor_token is OPTIONAL; its processing is out of scope for this specification.

The IdP MUST validate the subject assertion and check its audience against the authenticated client_id.

Refresh-token subject tokens get standard refresh-grant validation at the IdP.

A refresh-token exchange SHOULD re-assemble current subject claims for the issued ID-JAG.

Granted resource, scope, and authorization_details values MUST be reflected in the issued ID-JAG.

The IdP MAY narrow requested resources, scopes, or authorization details by policy.

An expired assertion MUST be rejected with invalid_grant (RFC 7521 Section 5.2).

Validation failures map to invalid_grant; authorization denials map to access_denied.

The RAS SHOULD NOT return a refresh token on an ID-JAG exchange; the ID-JAG itself is re-submittable.

The RAS MAY enforce single use by tracking jti and MAY cap exp by policy; replay tracking needs RAS-side state.