Identity Continuation Assertion for OAuth 2.0 Token Exchange

1.1. Relationship to ID-JAG and Identity Chaining

This document profiles Token Exchange [RFC8693], JWT [RFC7519], ID-JAG [I-D.ietf-oauth-identity-assertion-authz-grant], and OAuth Identity Chaining [I-D.ietf-oauth-identity-chaining]. It adds:¶

• the Identity Continuation Assertion subject-token type;¶

• an identity_continuation_handle claim in continuation-capable ID-JAGs;¶

• RAS binding of that claim to accepted authorization state;¶

• continuation-exchange validation rules;¶

• intra-domain Transaction Token context; and¶

• discovery metadata.¶

5.1. Token Type and Media Type

The Identity Continuation Assertion is identified as follows:¶

Name:        Identity Continuation Assertion
Token type:  urn:ietf:params:oauth:token-type:identity-continuation
JOSE typ:    oauth-identity-continuation+jwt

The assertion is a signed JWT in JWS Compact Serialization [RFC7519], with media type application/oauth-identity-continuation+jwt (Section 13). It MUST NOT be encrypted (JWE) or use nested signing. This profile relies on TLS for confidentiality and defines only signed JWS Compact Serialization, keeping a single interoperable representation. The IdP MUST verify the typ header per [RFC8725], which keeps the assertion from being consumed as another token type.¶

5.2. Claims

The following is a non-normative example of the Identity Continuation Assertion claim set:¶

{
  "iss": "https://ca.expenses.example/",
  "aud": "https://idp.example/",
  "identity_continuation_handle": "kW4uJ8pTe2NxA6rQvD1zYs",

  "act": {
    "iss": "https://expenses.example/",
    "sub": "expense-service"
  },

  "cnf": {
    "jkt": "base64url-current-actor-key-thumbprint"
  },

  "iat": 1710000500,
  "exp": 1710000800,
  "jti": "k7Qm2Xp9Rf4sLc3vBw8aZ1"
}

The claims have the following meanings and requirements:¶

iss:

REQUIRED. The Chain Authority issuer. The IdP MUST verify tenant trust and the signing key.¶

aud:

REQUIRED. A single string exactly matching the IdP issuer identifier, not its token endpoint URL.¶

identity_continuation_handle:

REQUIRED. The hop being continued (Section 6).¶

act:

REQUIRED. The current actor presenting the Token Exchange request, encoded as a single-level act claim per [RFC8693]. The act object contains a REQUIRED iss and a REQUIRED sub, both non-empty strings. Additional members MAY carry further identity attributes but are non-authoritative and MUST NOT affect identity, authorization, lineage, or issuance; a recipient MUST ignore members it does not understand, and exp, nbf, aud, scope, cnf, and nested act MUST NOT be present. The IdP MUST reject a non-conforming act. The IdP, not the assertion, constructs lineage (Section 8.10).¶

cnf:

REQUIRED. A confirmation claim [RFC7800] that binds the assertion to the presenting actor's key. It MUST contain exactly one method: jkt, the JWK SHA-256 thumbprint [RFC7638] of the DPoP key [RFC9449].¶

iat, exp:

REQUIRED. exp MUST follow iat, and exp - iat MUST NOT exceed 300 seconds, bounding how long a captured assertion could be replayed.¶

jti:

REQUIRED. A replay-detection identifier that MUST be unique per iss during the assertion validity window and MUST contain at least 128 bits of entropy.¶

The assertion MUST NOT contain top-level sub, auth_time, acr, amr, or sid; those values come from the root-chain envelope.¶

Other top-level claims MAY appear but MUST be ignored for validation, authorization, and issuance.¶

Offline-segment evidence MAY be retained separately and SHOULD remain in the control plane ([I-D.mcguinness-oauth-actor-receipts], [I-D.mcguinness-oauth-actor-proofs]).¶

5.3. Claims That Are Deliberately Excluded

The assertion MUST NOT convey these Token Exchange request values:¶

audience (target)
resource
scope
authorization_details
requested_token_type

They remain request parameters. Assertion aud identifies the IdP, not the requested target.¶

5.4. Chain Authority Issuance

The Chain Authority MUST issue only for an actor in the attested RAS's trust domain unless tenant configuration explicitly authorizes that external actor and its keys. Keeping issuance in-domain prevents a handle-holding party from bypassing the RAS-acceptance path. Actor authentication and the issuance protocol are deployment-specific.¶

A presenting workload is a control-plane participant, not a bare-handle-transporting application (Section 6.1): it reads the handle from its own intra-domain context and presents it to its Chain Authority, along with its key and any narrowing hints. That handle is advisory input, not an authority the workload asserts; the checks below re-verify it against RAS-bound state before any assertion issues.¶

It MUST authenticate the actor and issue only after establishing that:¶

1. the handle came through an authenticated, confidential, integrity-protected chain path or equivalent authenticated state;¶

2. the presenting actor is authorized under Chain Authority policy to continue the chain;¶

3. the presenting actor controls the key placed in cnf; and¶

4. act names that actor and, if offline attenuation reached the actor, its delegation artifact is valid.¶

Possession of a handle or Transaction Token is insufficient. The Chain Authority MUST bind the actor to the current transaction, verify that the handle matches that transaction's RAS-bound state, and recheck authoritative, uncached RAS state to confirm that the authorization remains active and continuation remains permitted; a cached read could attest a hop the RAS has since revoked. It MUST enforce per-transaction and per-actor rate and fan-out limits with audit records. Target or purpose hints MAY narrow Chain Authority issuance but MUST NOT control the IdP's target decision. Propagated context MUST NOT override the root-chain envelope.¶

6.1. Continuation Handle Carriers

A handle travels by one of three carriers, depending on context lifetime:¶

An external or requesting application never selects or persists a bare handle for transport; it carries an artifact from which trusted server-side state derives the handle. An authorized intra-domain control-plane workload is different: it reads the handle from that state and presents it to its Chain Authority (Section 5.4).¶

6.2. Handle Freshness and Unlinkability

Handles are unlinkable across hops but not among participants in one hop, and revoked handles fail the next continuation exchange. Section 12 covers the residual correlation channels.¶

8.1. Direct ID-JAG Request

A direct request, in which the subject token is a normal subject token such as an ID Token, refresh token, or SAML assertion:¶

grant_type=urn:ietf:params:oauth:grant-type:token-exchange
requested_token_type=urn:ietf:params:oauth:token-type:id-jag
audience=https://ras.travel.example/
resource=https://api.travel.example/
scope=trips.read
subject_token=<id_token | refresh_token | SAML assertion>
subject_token_type=<normal-subject-token-type>
actor_token=<sender-constrained-current-actor-credential> (OPTIONAL)
actor_token_type=<actor-token-type>                       (OPTIONAL)

On a direct request, actor_token is OPTIONAL (Section 8.2). The direct request and its ID-JAG conform to the base ID-JAG profile ([I-D.ietf-oauth-identity-assertion-authz-grant]) except where this document extends it for continuation-capable issuance.¶

8.2. Establishing a Chain

The IdP, not the client, establishes a chain. It MUST do so when a direct ID-JAG exchange is governed by a continuation-capable governing authorization, and MUST include the root handle in the ID-JAG. The exchange MUST include a valid DPoP proof [RFC9449], and the IdP MUST bind the resulting ID-JAG to that key in cnf; without valid proof it MUST NOT include an identity_continuation_handle. The IdP MAY defer materializing chain state until the first continuation, provided the handle still resolves to the same root and envelope; this does not relax the reservation durability of Section 8.8. Without continuation authorization, the IdP MUST NOT establish a chain or include a handle. Advertised support (Section 8.11) signals capability, not authority.¶

The root subject token MUST resolve to one of these lifecycle anchors:¶

• a refresh token's OAuth grant;¶

• an ID Token sid [OIDC.FrontChannelLogout] resolving to an active IdP session for that user and client; or¶

• a SAML SessionIndex [SAML2.Core] resolving to an active IdP session for that user and presenter.¶

The IdP MUST NOT root a chain from an unresolved anchor or an access token. Non-user-rooted authority is out of scope. sid and SessionIndex are used only for resolution and MUST NOT enter assertions or chain context.¶

Server-side consent and policy make the governing authorization continuation-capable and populate the root-chain envelope of Section 2 (the authenticated user, authentication context, authorization basis, permitted actors or trust domains, depth, governing authorization, and expiry). Token claims cannot supply these values. Every dimension is an establishment-time ceiling: later policy MAY narrow or revoke it but MUST NOT broaden it; broadening requires a new chain. An envelope MAY enumerate exact audience and resource pairs with their permitted scopes and authorization details [RFC9396]; otherwise it records a stable, policy-based basis, fixed at establishment, against which the IdP evaluates each requested target at request time. A policy-based basis is not whatever the user could authorize later: it is the enforceable record captured at establishment, and consent granted afterward cannot broaden it.¶

The root actor is the authenticated OAuth client under the mapping in Section 8.5. An optional actor_token MUST be valid, MUST be accepted for continuation, and MUST designate the IdP where applicable. It MUST also be sender-constrained to the confirmed key and MUST identify that client. Only after validation does the IdP record the root actor and key. The root actor's identity rests entirely on this client authentication (Section 8.5); base ID-JAG's recommendation to use a confidential client therefore applies to a continuation-capable root.¶

For every root or child hop, the IdP records the target RAS and the Chain Authorities mapped to it; the mapping MAY be static tenant configuration. Only a mapped Chain Authority may attest that hop. A terminal RAS ignores the handle; only a continuation-aware RAS can bind it and make the hop continuable. Grant-profile advertisement is discovery only; a party that requires onward continuation SHOULD consult it when available.¶

Establishment is at-least-once: retrying a lost response MAY create a second chain. Revocation of the governing authorization applies to every chain rooted in it, and the actor-chain depth bound is enforced per branch; the IdP MUST enforce configured fan-out, rate, and hop-count limits as an aggregate keyed to the governing authorization; a retried establishment MUST NOT evade these limits.¶

8.3. Chained ID-JAG Request

A chained request, in which the subject token is an Identity Continuation Assertion:¶

grant_type=urn:ietf:params:oauth:grant-type:token-exchange
requested_token_type=urn:ietf:params:oauth:token-type:id-jag
audience=https://ras.travel.example/
resource=https://api.travel.example/
scope=trips.read
subject_token=<identity-continuation-assertion>
subject_token_type=<identity-continuation-token-type>
actor_token=<sender-constrained-current-actor-credential>
actor_token_type=<actor-token-type>

The subject_token_type value above is urn:ietf:params:oauth:token-type:identity-continuation.¶

The requested audience, resource, scope, requested_token_type, and any authorization_details are supplied by the Token Exchange request and never by the assertion (Section 5.3). Following [I-D.ietf-oauth-identity-assertion-authz-grant], audience identifies the target Resource Authorization Server and resource ([RFC8693], originally defined in [RFC8707]) identifies the protected resource.¶

The request MAY also include authorization_details [RFC9396], which the ID-JAG profile supports in both the exchange and the issued grant; the authorization-basis check (Section 8.7, rule 14) applies equally to it and to scope. Client authentication is required on every exchange (Section 8.5) and is omitted from the example bodies for brevity.¶

8.4. Sender-Constrained Presentation

This section applies to a chained request; a direct request's DPoP requirement is specified in Section 8.2.¶

The actor MUST present a DPoP proof [RFC9449] for the key in cnf.jkt. The IdP MUST verify the match and reject absent or invalid proof.¶

DPoP is the single mandatory confirmation method for interoperability: a different confirmation method in the onward grant would make the target validate that confirmation differently than for a directly issued ID-JAG. This version therefore defines no mutual-TLS variant [RFC8705]; see Appendix C.¶

The request MUST include a valid, accepted actor_token identifying the actor in act. It MUST be sender-constrained to the same key and MUST NOT be bearer. For a JWT, the IdP verifies cnf.jkt; for an opaque token, it obtains equivalent confirmation from authoritative metadata such as introspection [RFC7662]. Any audience or applicability restriction MUST designate the IdP.¶

The IdP MUST compare the actor iss and sub as case-sensitive strings with no transformation or canonicalization ([RFC7519]), across actor_token, act, and the authenticated client. Identities in different tenants never compare equal.¶

The onward ID-JAG MUST use the same DPoP key. The actor proves possession again at the target RAS.¶

Key rotation takes effect when the actor obtains a new assertion and actor token bound to the new key.¶

8.5. Client Identity and Authentication

The current actor MUST authenticate as an OAuth client, and the IdP MUST map that client authoritatively to an actor identity; self-asserted mappings MUST NOT be accepted. On a continuation exchange the IdP MUST also match that identity to the assertion's act and the actor_token; at root establishment neither is present, so client authentication alone identifies the root actor.¶

A sender-constrained JWT MAY serve as both client assertion and actor_token when it satisfies both profiles. For [RFC7523], its sub is the client_id, and the IdP MUST authorize its issuer for that client. Otherwise the client authenticates separately.¶

The onward ID-JAG client_id is the current actor's identifier at the target RAS. The actor therefore needs a registration or resolvable client identity at each target, as required by ID-JAG.¶

Four signals identify the actor on a continuation exchange, and all four, with the confirmed key, must agree:¶

The apparent redundancy is conjunctive trust: a mismatch on any one, or a key not proven live, fails the exchange (Section 8.7, rules 9 through 11).¶

8.6. Continuation Handle Delivery

The IdP delivers the hop reference in the issued ID-JAG's identity_continuation_handle claim (Section 6, rule 1; Section 8.10), not as a separate Token Exchange response parameter. Each hop's handle is distinct and its parent reference is immutable (Section 6, rules 1 and 8). The accepting Resource Authorization Server binds it to authorization state (Section 9); the current domain then surfaces it to continuers through intra-domain chain context (Section 10).¶

There is no advisory chain-expiry response parameter. Chain lifetime is authoritative at the IdP (Section 7); a deployment that needs advance warning of expiry conveys it through authenticated task or authorization state, an optional ID-JAG claim, or a management API, not through the Token Exchange response.¶

8.7. Request Validation

The IdP MUST reject the request unless every rule below holds. Their order is not significant, though one rule's input may come from another's resolution: the tenant used to check Chain Authority trust comes from resolving the presented handle.¶

1. the request contains exactly one each of grant_type, subject_token, subject_token_type, requested_token_type, actor_token, and actor_token_type; the grant_type is urn:ietf:params:oauth:grant-type:token-exchange, and the subject_token_type is urn:ietf:params:oauth:token-type:identity-continuation;¶

2. the request contains exactly one audience and one resource parameter, and at most one scope and one authorization_details; scope and authorization_details are OPTIONAL, each evaluated by rule 14 when present;¶

3. the assertion is a JWT containing exactly one value for each required claim defined in Section 5.2; iss, aud, identity_continuation_handle, and jti are non-empty strings; act and cnf are JSON objects, with cnf containing exactly one confirmation method; iat and exp are JSON numbers representing NumericDate values; and the JOSE typ header is oauth-identity-continuation+jwt;¶

4. the assertion signature validates using a key authorized for the assertion issuer, and the JOSE alg is an asymmetric signature algorithm on the IdP's configured allowlist (the none algorithm MUST be rejected; see Section 11.10);¶

5. the assertion aud exactly matches the IdP's issuer identifier;¶

6. assertion iss is trusted for the tenant, mapped to the hop's accepting RAS, and authorized to pair with the actor_token issuer for that tenant;¶

7. the handle identifies a RAS-accepted hop (Section 9.1) on an active chain, no ancestor subtree is revoked, and the actor lineage that results from collapsing consecutive same-actor entries, as the onward act will (Section 8.10), is within its depth bound; the bound counts lineage entries, not hops;¶

8. the assertion does not contain a top-level sub, auth_time, acr, amr, or sid claim, nor an audience, resource, scope, authorization_details, or requested_token_type claim (Section 5.2, Section 5.3);¶

9. the assertion's act claim is present, conforms to the schema of Section 5.2, and identifies the current actor;¶

10. the request and actor are bound:¶

    • the request is authenticated as an OAuth client that is the same entity as the current actor (Section 8.5);¶

    • the actor_token_type names a token type the IdP supports, and the actor_token has a trusted issuer for the actor's domain and tenant, is valid for that type, is accepted, designates the IdP where applicable, and authenticates the actor;¶

    • the actor_token is sender-constrained to the key confirmed by the assertion's cnf (Section 8.4);¶

    • that actor is the actor named in act; and¶

    • that actor is permitted by the chain's continuation authorization (Section 8.2) to continue from the presented hop;¶

11. the request proves possession of the key confirmed by cnf with a DPoP proof [RFC9449] matching cnf.jkt (Section 8.4);¶

12. jti is not yet reserved for the assertion issuer, or is RESERVED or ISSUED under a fingerprint matching this request (permitting idempotent retry; see the reservation rules in Section 8.8); a RESERVED or ISSUED jti under a different fingerprint, or a FAILED jti, is rejected;¶

13. iat and exp are valid NumericDates, iat is within permitted future clock skew (which SHOULD NOT exceed 60 seconds), exp follows iat, the assertion is unexpired, and its lifetime does not exceed 300 seconds;¶

14. requested audience, resource, scopes, and authorization details are within the root-chain envelope as recorded at establishment and within current IdP actor policy; authorization-details containment uses the comparison rules defined for each authorization-detail type, since [RFC9396] defines no generic comparison, and a detail type whose rules the IdP does not implement is rejected;¶

15. the requested output token type is urn:ietf:params:oauth:token-type:id-jag; and¶

16. the IdP can resolve, for the requested audience, both the audience-local subject and the current actor's client identifier (Section 8.5).¶

8.8. Replay Reservation and Retry

The reservation model gives a client idempotent recovery after a lost response while preventing one assertion from authorizing more than one distinct request. It fixes each assertion's outcome to a single request fingerprint.¶

After validation, grant issuance MUST atomically reserve (iss, jti) and bind it to a fingerprint containing audience and resource as exact strings, scope as an order-independent set, the exact authorization_details JSON as received after form decoding (different serializations are different requests), the actor (its iss and sub), the confirmed key (its cnf.jkt thumbprint), and a SHA-256 hash of the exact subject_token value after form decoding, which binds the fingerprint to the specific assertion and its handle.¶

The record states are RESERVED, ISSUED, and FAILED, distinct from the hop states of Section 9.1. Reservation MUST occur only after target and policy validation. Once reserved, the tuple MUST NOT be released for another fingerprint. An identical retry MUST return the same previously issued grant, not a new one; a different fingerprint MUST be rejected. Only one concurrent request can reach ISSUED; a concurrent request under a matching fingerprint waits for or retries that result. The IdP MUST retain the tuple through exp plus the maximum permitted clock skew, using the same clock used to evaluate exp. A reservation that does not reach ISSUED before exp becomes FAILED; a FAILED tuple is terminal and requires a fresh assertion.¶

Replay uniqueness MUST use (iss, jti), not an unbound tenant partition; partitioning by tenant alone would let two assertion issuers in one tenant collide on a reused jti.¶

The IdP needs strongly consistent replay state. The actor-chain depth bound counts collapsed lineage entries, so an actor that repeatedly continues as itself collapses to one entry each time and never trips that bound. To bound such growth, the IdP MUST enforce a configured limit on fan-out, rate, and hop count, aggregated per governing authorization (Section 8.2), and MUST prune expired or revoked hop state.¶

After a lost response, a client MAY retry the same assertion to recover the ISSUED result or obtain a fresh assertion. A fresh assertion may create an equivalent grant and sibling hop but no additional authority. Application idempotency remains out of scope. The Chain Authority SHOULD account for retries separately from fan-out while preventing retry claims from bypassing limits; issuance SHOULD be inexpensive relative to the exchange.¶

8.9. Success and Error Responses

On success, the IdP records a PENDING child (Section 9.1) of the presented hop and issues an ID-JAG containing the resolved target sub and fresh handle. An idempotent retry (rule 12; Section 8.8) instead returns the previously issued grant unchanged, creating no new hop or handle.¶

On failure, the IdP MUST return an OAuth error [RFC6749], [RFC8693]. It SHOULD use invalid_request for malformed, inconsistent, or unacceptable tokens; invalid_dpop_proof for DPoP failure; and invalid_target, invalid_scope, or invalid_authorization_details for requests outside the envelope.¶

The IdP MUST return invalid_continuation (Section 13) when the presented handle cannot support this continuation, distinguishing a dead hop from the invalid_request of a malformed request. Such a handle is terminal: retrying it cannot succeed. Recovery requires establishing a new chain and succeeds only where the governing authorization is still continuation-capable: a session-anchored chain re-roots by re-authenticating the user, a grant-anchored chain from its still-valid grant without the user; a handle disabled by withdrawn continuation authorization cannot re-root at all. Target-specific errors (invalid_target, invalid_scope, invalid_authorization_details) leave the chain otherwise continuable, so a client abandons only the current request.¶

8.10. Onward ID-JAG

The onward ID-JAG conforms to the base ID-JAG profile ([I-D.ietf-oauth-identity-assertion-authz-grant]) except where this document extends it: its sub is the IdP-issued pairwise subject for the target audience, and aud_sub remains available under the base profile where the target's native subject namespace differs. The following is a non-normative example of the onward ID-JAG issued by the IdP:¶

{
  "iss": "https://idp.example/",
  "aud": "https://ras.travel.example/",
  "sub": "travel-pairwise-subject",

  "client_id": "expense-service",
  "resource": "https://api.travel.example/",
  "scope": "trips.read",

  "identity_continuation_handle": "Uc9fB3mHs5LdK7gEnX2wRj",

  "auth_time": 1710000000,
  "acr": "urn:example:loa:2",
  "amr": ["pwd", "mfa"],

  "act": {
    "iss": "https://expenses.example/",
    "sub": "expense-service",
    "act": {
      "iss": "https://expenses.example/",
      "sub": "expense-app"
    }
  },

  "cnf": {
    "jkt": "base64url-current-actor-key-thumbprint"
  },

  "iat": 1710000025,
  "exp": 1710000325,
  "jti": "idjag-travel-01"
}

The IdP constructs act by placing the authenticated current actor atop the presented hop's lineage; it never copies lineage from the assertion. Siblings do not contribute. Consecutive identical actors collapse to one entry, though the hop record remains; policy MAY limit disclosed depth, narrowing what a target sees without changing the depth bound the IdP enforces (Section 8.7, rule 7).¶

The target RAS validates the ID-JAG, issues its access token, and, if continuation-aware, binds the handle. The ID-JAG client_id is the current actor's identifier at that RAS.¶

8.11. Authorization Server Metadata

An IdP that supports this profile SHOULD signal it in its authorization server metadata [RFC8414] with the following parameter:¶

identity_continuation_supported:

OPTIONAL. Boolean value indicating that the IdP accepts Identity Continuation Assertions of the urn:ietf:params:oauth:token-type:identity-continuation subject token type and issues continuation-capable ID-JAGs carrying the identity_continuation_handle claim. Default false.¶

A Resource Authorization Server advertises separately, by listing the grant profile urn:ietf:params:oauth:grant-profile:id-jag-continuation in its authorization_grant_profiles_supported [I-D.ietf-oauth-identity-assertion-authz-grant], that it recognizes a continuation-capable ID-JAG and binds the identity_continuation_handle claim to authorization state (Section 9). This value is distinct from the base ID-JAG grant profile, which signals only ordinary ID-JAG processing and no handle binding. Because a continuation-capable ID-JAG is an ID-JAG, a Resource Authorization Server that advertises urn:ietf:params:oauth:grant-profile:id-jag-continuation MUST also advertise the base urn:ietf:params:oauth:grant-profile:id-jag profile and the urn:ietf:params:oauth:grant-type:jwt-bearer grant type on which ID-JAG depends ([I-D.ietf-oauth-identity-assertion-authz-grant]). These are distinct capabilities: the IdP signal covers continuation issuance and acceptance; the Resource Authorization Server profile covers handle binding.¶

Absent these signals, a party learns of support out of band or by attempting an exchange.¶

9.1. Hop Activation

A hop moves through three states. The IdP creates it PENDING. Successful RAS binding makes it ACCEPTED. A mapped Chain Authority attests a hop only once it is ACCEPTED, so a PENDING hop yields no assertion and reaches no continuation exchange. A fresh assertion from the mapped Chain Authority lets the IdP evaluate the hop as CONTINUABLE for one request; CONTINUABLE is not stored but holds only while rules 6, 7, and 9 to 11 of Section 8.7 hold for that request. There is no RAS callback.¶

ACCEPTED is a state of the RAS's own authorization, not an IdP transition delivered by callback; the IdP learns of it only through a Chain Authority attestation.¶

The Chain Authority assertion is trusted evidence of acceptance, not IdP-verifiable proof: the IdP has no channel back to the RAS to confirm acceptance directly (Appendix A.4), so it relies on the mapped Chain Authority having rechecked authoritative RAS state before attesting (Section 5.4). A compromised mapped Chain Authority can thus attest a hop that its Resource Authorization Server refused, or for which it denied continuation, overriding that server's local decision; the envelope still bounds the result, but the accept-and-continue gate is only as trustworthy as the mapped Chain Authority. Absent such compromise, an issued-but-rejected ID-JAG cannot be continued because no mapped Chain Authority may attest it. A mapped Chain Authority is mandatory; its absence fails closed. Acceptance gates continuation but does not bound downstream authority (Section 9.2).¶

9.2. A Gate, Not a Ceiling

RAS acceptance is a gate, not a downstream ceiling. The IdP evaluates later targets against the root envelope; local RAS authorization neither narrows nor widens it. Cross-domain scope vocabularies are not generally comparable, so RAS-derived narrowing, if ever defined, would need signed constraints and an explicit intersection model.¶

9.3. Durable Task Authorization

Scheduled continuation MUST root in durable RAS authorization, not a scheduler-held handle: a scheduler holding the handle would turn it into a durable, bearer-like credential outside the per-call key proof and RAS binding that gate every other use. The scheduler holds only a task identifier; each authenticated run derives the handle from active task state and still requires an assertion from a mapped Chain Authority.¶

11.1. Sender Constraint and Proof of Possession

The assertion MUST NOT be accepted as bearer [RFC7800]. It requires live proof of the actor's cnf key.¶

11.2. Short Lifetime and Replay

The 300-second ceiling and atomic reservation of (iss, jti) (Section 8.8) limit replay to the IdP continuation exchange.¶

11.3. Root Authentication Context

Authentication context comes only from the root envelope. Continuation MUST NOT extend or strengthen it, for example by presenting a higher acr or added amr than the user performed at root; the IdP MUST copy it unchanged into onward ID-JAGs (Section 8.10) when [I-D.ietf-oauth-identity-assertion-authz-grant] requires those claims.¶

11.4. Envelope Enforcement and Offline Attenuation

The envelope bounds every target and authority. The Chain Authority validates any offline attenuation segment; the IdP still enforces only the envelope. Because the assertion is target-agnostic, a permitted actor may select any target within that ceiling.¶

Wrong-handle association can continue the wrong user's bounded chain. The TTS establishes the authoritative association between the request and the handle by deriving it from the current credential's RAS-bound state; a handle a workload supplies is not authoritative, and the Chain Authority rejects substitution. Another carrier MAY be used only if it provides the same properties (Section 10): server-derived; bound to the credential, key, and RAS authorization; non-overridable; domain-confined; and re-derived when replaced.¶

11.5. Trust in the Transaction Token Service

A faulty TTS can splice a valid wrong-user hop into a transaction, and every downstream check at the Chain Authority and IdP still sees a well-formed continuation. The TTS MUST key derivation to the presented credential, not a session or subject, and SHOULD be monitored independently.¶

One operator MAY run the RAS, TTS, and Chain Authority. Where independent acceptance evidence matters, deployments SHOULD separate them or audit the binding-to-attestation path.¶

11.6. Trust in the Chain Authority

The IdP MUST scope Chain Authority trust by issuer, keys, tenant, and mapped RAS. Deployments SHOULD minimize that scope and monitor anomalies. Trust is established out of band or through federation, as in [RFC7523]. Handle confidentiality provides defense in depth, not authorization.¶

11.7. Trust in Actor Token Issuers

The IdP MUST accept actor tokens only from issuers trusted for the actor's domain and tenant. An untrusted or out-of-scope issuer MUST be rejected even with a valid Chain Authority assertion.¶

11.8. Conjunctive Trust and Issuer Pairing

A continuation requires all of these, and no one of them suffices alone:¶

• the Chain Authority mapped to the presented hop's accepting Resource Authorization Server, which attests the chain-to-actor transition (Section 8.7, rule 6);¶

• the workload identity issuer trusted for the current actor's trust domain, which authenticates the actor through the actor_token (Section 8.7, rule 10);¶

• live proof of possession of the confirmed key (Section 8.7, rule 11); and¶

• the IdP's own root-chain envelope and current-actor policy (Section 8.7, rule 14).¶

The IdP MUST authorize Chain Authority and actor-token issuer pairings per tenant; separate trust in each is insufficient.¶

The anchors MAY be co-located, with this resulting blast radius:¶

No compromise listed above yields authority beyond the root-chain envelope. Co-locating anchors trades away the defense in depth that the conjunction otherwise provides. If the IdP is also co-located, even the envelope backstop becomes organizational rather than protocol-separated.¶

11.9. Actor Chain Integrity

Lineage is IdP-constructed. An assertion names only the current actor; the IdP MUST reject any mismatch. Offline-segment actors do not enter lineage.¶

11.10. Token, Type, and Algorithm Confusion

The IdP MUST verify typ, reject alg=none and symmetric algorithms, and allowlist asymmetric algorithms. It MUST select keys from trusted issuer configuration; kid MAY select among them. It MUST NOT trust assertion jku, x5u, embedded jwk, or other supplied key material.¶

13.1. OAuth Extensions Error Registration

IANA is requested to register the following error in the "OAuth Extensions Error Registry" established by [RFC6749].¶

Error Name:

invalid_continuation¶

Error Usage Location:

token endpoint response¶

Related Protocol Extension:

Identity Continuation Assertion for OAuth 2.0 Token Exchange¶

Change Controller:

IETF¶

Specification Document(s):

This document, Section 8.9¶

13.2. OAuth URI Registration

IANA is requested to register the following value in the "OAuth URI" registry established by [RFC6755] and used for token type identifiers by [RFC8693].¶

URN:

urn:ietf:params:oauth:token-type:identity-continuation¶

Common Name:

Token type URI for the Identity Continuation Assertion¶

Change Controller:

IETF¶

Specification Document:

This document, Section 5.1¶

IANA is also requested to register the following grant-profile value in the same registry.¶

URN:

urn:ietf:params:oauth:grant-profile:id-jag-continuation¶

Common Name:

Grant profile identifier for a continuation-capable ID-JAG, whose accepting Resource Authorization Server binds the identity_continuation_handle claim to authorization state¶

Change Controller:

IETF¶

Specification Document:

This document, Section 8.11, Section 9¶

13.3. Media Type Registration

IANA is requested to register the following media type in the "Media Types" registry, in the manner described in [RFC6838], corresponding to the JOSE typ header value oauth-identity-continuation+jwt.¶

Type name:

application¶

Subtype name:

oauth-identity-continuation+jwt¶

Required parameters:

N/A¶

Optional parameters:

N/A¶

Encoding considerations:

binary; the +jwt structured syntax suffix [RFC8417] registers this encoding. An Identity Continuation Assertion is a JWT [RFC7519], a series of base64url-encoded values (some of which may be empty) separated by period ('.') characters.¶

Security considerations:

See Section 11 of this document.¶

Interoperability considerations:

N/A¶

Published specification:

This document, Section 5.1¶

Applications that use this media type:

Applications using OAuth 2.0 Token Exchange [RFC8693] to perform identity continuation across SaaS boundaries.¶

Fragment identifier considerations:

N/A¶

Additional information:

Deprecated alias names for this type: N/A
Magic number(s): N/A
File extension(s): N/A
Macintosh file type code(s): N/A¶

Person & email address to contact for further information:

Karl McGuinness (public@karlmcguinness.com)¶

Intended usage:

COMMON¶

Restrictions on usage:

N/A¶

Author:

Karl McGuinness¶

Change controller:

IETF¶

13.4. JSON Web Token Claims Registration

IANA is requested to register the following claim in the "JSON Web Token Claims" registry established by [RFC7519].¶

Claim Name:

identity_continuation_handle¶

Claim Description:

An opaque, IdP-generated reference to one hop of a delegation chain, used to correlate a continuation to its chain and parent hop and to resolve the per-audience subject. This claim appears in an Identity Continuation Assertion and in a continuation-capable ID-JAG, and its value may also travel in intra-domain chain context; it MUST NOT be placed in an access token or a Resource Server's external authorization claims (Section 6, rules 3 and 4).¶

Change Controller:

IETF¶

Specification Document(s):

This document, Section 6¶

13.5. OAuth Authorization Server Metadata Registration

IANA is requested to register the following value in the "OAuth Authorization Server Metadata" registry established by [RFC8414].¶

Metadata Name:

identity_continuation_supported¶

Metadata Description:

Boolean value indicating support for the Identity Continuation Assertion profile¶

Change Controller:

IETF¶

Specification Document(s):

This document, Section 8.11¶

Note: The token type URI urn:ietf:params:oauth:token-type:id-jag referenced by this document is registered by [I-D.ietf-oauth-identity-assertion-authz-grant] and is not registered here.¶

Note: The authorization_grant_profiles_supported metadata parameter and the base urn:ietf:params:oauth:grant-profile:id-jag value referenced by this document are defined and registered by [I-D.ietf-oauth-identity-assertion-authz-grant] and are not registered here; this document registers only the urn:ietf:params:oauth:grant-profile:id-jag-continuation value.¶

14.1. Normative References

[I-D.ietf-oauth-identity-assertion-authz-grant]

Parecki, A., McGuinness, K., and B. Campbell, "Identity Assertion JWT Authorization Grant", Work in Progress, Internet-Draft, draft-ietf-oauth-identity-assertion-authz-grant-04, 21 May 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-identity-assertion-authz-grant-04>.

[I-D.ietf-oauth-transaction-tokens]

Tulshibagwale, A., Fletcher, G., and P. Kasselman, "Transaction Tokens", Work in Progress, Internet-Draft, draft-ietf-oauth-transaction-tokens-11, 30 July 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-transaction-tokens-11>.

[OIDC.FrontChannelLogout]

OpenID Foundation, "OpenID Connect Front-Channel Logout 1.0", <https://openid.net/specs/openid-connect-frontchannel-1_0.html>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC6749]

Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, <https://www.rfc-editor.org/rfc/rfc6749>.

[RFC7519]

Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, <https://www.rfc-editor.org/rfc/rfc7519>.

[RFC7523]

Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants", RFC 7523, DOI 10.17487/RFC7523, May 2015, <https://www.rfc-editor.org/rfc/rfc7523>.

[RFC7638]

Jones, M. and N. Sakimura, "JSON Web Key (JWK) Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September 2015, <https://www.rfc-editor.org/rfc/rfc7638>.

[RFC7662]

Richer, J., Ed., "OAuth 2.0 Token Introspection", RFC 7662, DOI 10.17487/RFC7662, October 2015, <https://www.rfc-editor.org/rfc/rfc7662>.

[RFC7800]

Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)", RFC 7800, DOI 10.17487/RFC7800, April 2016, <https://www.rfc-editor.org/rfc/rfc7800>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC8414]

Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", RFC 8414, DOI 10.17487/RFC8414, June 2018, <https://www.rfc-editor.org/rfc/rfc8414>.

[RFC8693]

Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J., and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, DOI 10.17487/RFC8693, January 2020, <https://www.rfc-editor.org/rfc/rfc8693>.

[RFC8707]

Campbell, B., Bradley, J., and H. Tschofenig, "Resource Indicators for OAuth 2.0", RFC 8707, DOI 10.17487/RFC8707, February 2020, <https://www.rfc-editor.org/rfc/rfc8707>.

[RFC8725]

Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best Current Practices", BCP 225, RFC 8725, DOI 10.17487/RFC8725, February 2020, <https://www.rfc-editor.org/rfc/rfc8725>.

[RFC9396]

Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0 Rich Authorization Requests", RFC 9396, DOI 10.17487/RFC9396, May 2023, <https://www.rfc-editor.org/rfc/rfc9396>.

[RFC9449]

Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449, September 2023, <https://www.rfc-editor.org/rfc/rfc9449>.

[SAML2.Core]

OASIS, "Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0", March 2005, <https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf>.

14.2. Informative References

[GRANT-MGMT]

OpenID Foundation, "Grant Management for OAuth 2.0", <https://openid.net/specs/oauth-v2-grant-management.html>.

[I-D.fletcher-transaction-token-chaining-profile]

Fletcher, G., Kasselman, P., and S. O'Dell, "Transaction Token Authorization Grant Profile for OAuth Identity and Authorization Chaining", Work in Progress, Internet-Draft, draft-fletcher-transaction-token-chaining-profile-02, 6 July 2026, <https://datatracker.ietf.org/doc/html/draft-fletcher-transaction-token-chaining-profile-02>.

[I-D.ietf-oauth-identity-chaining]

Schwenkschuster, A., Kasselman, P., Burgin, K., Jenkins, M. J., Campbell, B., and A. Parecki, "OAuth Identity and Authorization Chaining Across Domains", Work in Progress, Internet-Draft, draft-ietf-oauth-identity-chaining-17, 19 July 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-identity-chaining-17>.

[I-D.ietf-wimse-arch]

Salowey, J. A., Rosomakho, Y., and H. Tschofenig, "Workload Identity in a Multi System Environment (WIMSE) Architecture", Work in Progress, Internet-Draft, draft-ietf-wimse-arch-08, 6 July 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-wimse-arch-08>.

[I-D.li-oauth-delegated-authorization]

Ruochen, L., Wang, W., Liu, P. C., and T. Li, "OAuth 2.0 Delegated Authorization", Work in Progress, Internet-Draft, draft-li-oauth-delegated-authorization-03, 24 July 2026, <https://datatracker.ietf.org/doc/html/draft-li-oauth-delegated-authorization-03>.

[I-D.mcguinness-oauth-actor-proofs]

McGuinness, K., "OAuth Actor-Signed Hop Proofs", Work in Progress, Internet-Draft, draft-mcguinness-oauth-actor-proofs-00, 4 July 2026, <https://datatracker.ietf.org/doc/html/draft-mcguinness-oauth-actor-proofs-00>.

[I-D.mcguinness-oauth-actor-receipts]

McGuinness, K., "OAuth Actor Receipts for Delegation Provenance", Work in Progress, Internet-Draft, draft-mcguinness-oauth-actor-receipts-00, 4 July 2026, <https://datatracker.ietf.org/doc/html/draft-mcguinness-oauth-actor-receipts-00>.

[RFC6755]

Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace for OAuth", RFC 6755, DOI 10.17487/RFC6755, October 2012, <https://www.rfc-editor.org/rfc/rfc6755>.

[RFC6838]

Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <https://www.rfc-editor.org/rfc/rfc6838>.

[RFC8417]

Hunt, P., Ed., Jones, M., Denniss, W., and M. Ansari, "Security Event Token (SET)", RFC 8417, DOI 10.17487/RFC8417, July 2018, <https://www.rfc-editor.org/rfc/rfc8417>.

[RFC8705]

Campbell, B., Bradley, J., Sakimura, N., and T. Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens", RFC 8705, DOI 10.17487/RFC8705, February 2020, <https://www.rfc-editor.org/rfc/rfc8705>.

[RFC9700]

Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett, "Best Current Practice for OAuth 2.0 Security", BCP 240, RFC 9700, DOI 10.17487/RFC9700, January 2025, <https://www.rfc-editor.org/rfc/rfc9700>.

A.1. Relationship to ID-JAG

The assertion is the Token Exchange input: its audience is the IdP and it has no top-level sub. The resulting ID-JAG is the target Resource Authorization Server's grant and contains the IdP-resolved subject and, when applicable, a continuation handle. The artifacts therefore have different issuers, audiences, subjects, and consumers.¶

A.2. Why Not a Transaction Token

A Transaction Token [I-D.ietf-oauth-transaction-tokens] carries request context within one trust domain. The assertion crosses from that domain to the IdP, is single-use, and carries neither the target subject nor general request context. It may be derived from Transaction Token context, but is not a Transaction Token profile.¶

A.3. Why Not a Cross-Domain Propagation Token

The choice follows Section 4: a pairwise-subject boundary can be crossed only by the IdP, which the target trusts to name the user, and IdP exchange permits current-state and envelope checks at every hop. Direct propagation instead fits deployments with a global subject, shared issuer trust, and no need for mid-chain IdP revocation, such as a single SPIFFE-style trust domain (one workload-identity namespace with no pairwise-subject boundary to cross) (Section 4). Delegated Authorization [I-D.li-oauth-delegated-authorization], whose client-issued tokens carry no subject, composes with this profile as the intra-domain layer and stops where re-issuance to a new subject begins.¶

A.4. Alternative Topology: Resolution at the Target

A pull design would have each target resolve a reference at the IdP over a back channel [RFC7662]. It requires a new target-side grant and per-request back channel. The selected push design reuses the ID-JAG grant path, adding only handle binding at continuation-source RASes; the Chain Authority supplies acceptance evidence. Pull remains a possible companion profile.¶

A.5. Why a Signed Assertion Rather Than a Bare Grant Type

The signed assertion lets the Chain Authority attest the authenticated actor, key, accepted hop, and any intra-domain policy checks that the IdP cannot observe. It does not authorize target or scope. Where that domain-local attestation is unnecessary, a recipient-bound direct grant remains a possible simplification.¶

B.1. Worked Example (Same-IdP)

This section walks the canonical same-IdP flow end-to-end for a single user: ExpenseApp invokes ExpenseSaaS; ExpenseService, the workload handling that request, calls TravelAPI to reach TravelSaaS; and TravelService, the TravelSaaS workload that handles that call, in turn calls BookingAPI to complete the itinerary. All parties trust one enterprise IdP at https://idp.example/.¶

Proof of possession uses DPoP. JWTs are shown as decoded payloads; JOSE headers, signatures, and client authentication are omitted. The handle crosses a trust boundary only inside an ID-JAG or Identity Continuation Assertion and travels within a domain only as derived chain context.¶

Participants are grouped by trust domain; all trust the IdP at https://idp.example/. Each domain from which continuation occurs has three logical roles: a Resource Authorization Server that binds the accepted hop, a Transaction Token Service (TTS) that derives its chain context, and a Chain Authority that attests continuation. A deployment may co-locate those roles.¶

• Expense domain (expenses.example): client expense-app, workload expense-service, and ExpenseRAS / Expense TTS / Expense CA, in front of ExpenseAPI.¶

• Travel domain (travel.example): workload travel-service, and TravelRAS / Travel TTS / Travel CA, in front of TravelAPI.¶

• Booking domain (booking.example): BookingRAS and BookingAPI only. It is terminal in this chain, an ordinary ID-JAG Resource Authorization Server that needs no continuation support (Section 9).¶

• Outside the trust circle: PartnerSaaS (partner.example), reached in Appendix B.1.7.¶

The user has a pairwise subject at each RAS, which only the IdP can map. Handles are H0 at ExpenseRAS, H1 at TravelRAS, and H2 at BookingRAS.¶

The root hop establishes the chain and the Expense domain's accepted authorization:¶

 ExpenseApp        IdP          ExpenseRAS       ExpenseAPI/TTS
     |               |               |                 |
     |--ID Token---->|               |                 |
     |<-ID-JAG(H0)---|               |                 |
     |------------------ID-JAG------>|                 |
     |<-------------------AT1--------| bind H0         |
     |------------------request + AT1 + DPoP--------->|
     |               |               |<-resolve AT1----|
     |               |               |--bound H0------>|
     |               |               |    derive H0 into tctx

Each continuation repeats one exchange. ExpenseService obtains the Travel grant before crossing the boundary:¶

 ExpenseService  Expense CA        IdP        TravelRAS TravelAPI/TTS
       |              |             |             |             |
       |-request H0-->|             |             |             |
       |<-assertion---|             |             |             |
       |--------------------------->|             |             |
       |     assertion + DPoP       |             |             |
       |<---------------------------| ID-JAG(H1)  |             |
       |----------------------------------------->|             |
       |                 ID-JAG                   |             |
       |<-----------------------------------------| AT2; bind H1|
       |-----------------request + AT2 + DPoP------------------>|
       |              |             |             |<-resolve AT2|
       |              |             |             |--bound H1-->|
       |              |             |             | derive into TT

Appendix B.1.6 repeats the pattern from TravelSaaS to terminal BookingRAS.¶

POST /token HTTP/1.1
Host: idp.example
Content-Type: application/x-www-form-urlencoded
DPoP: <proof signed by the expense-app key>

grant_type=urn:ietf:params:oauth:grant-type:token-exchange
requested_token_type=urn:ietf:params:oauth:token-type:id-jag
audience=https://ras.expenses.example/
resource=https://api.expenses.example/
scope=expenses.read
subject_token=<id_token>
subject_token_type=urn:ietf:params:oauth:token-type:id_token
actor_token=<sender-constrained expense-app credential>
actor_token_type=urn:ietf:params:oauth:token-type:jwt

(https://ras.expenses.example/, https://api.expenses.example/)
    permitted scopes: expenses.read

(https://ras.travel.example/, https://api.travel.example/)
    permitted scopes: trips.read

(https://ras.booking.example/, https://api.booking.example/)
    permitted scopes: stays.book

{
  "iss": "https://idp.example/",
  "aud": "https://ras.expenses.example/",
  "sub": "expense-pairwise-subject",

  "client_id": "expense-app",
  "resource": "https://api.expenses.example/",
  "scope": "expenses.read",

  "auth_time": 1710000000,
  "acr": "urn:example:loa:2",
  "amr": ["pwd", "mfa"],

  "identity_continuation_handle": "kW4uJ8pTe2NxA6rQvD1zYs",

  "cnf": {
    "jkt": "base64url-expense-app-key-thumbprint"
  },

  "iat": 1710000005,
  "exp": 1710000305,
  "jti": "idjag-expense-01"
}

{
  "identity_continuation_handle": "kW4uJ8pTe2NxA6rQvD1zYs",
  "status": "ACCEPTED",
  "authorization_state": "at1-authz-2f9c",
  "client_id": "expense-app",
  "bound_at": 1710000010
}

{
  "iss": "https://tts.expenses.example/",
  "aud": "https://expenses.example/",
  "sub": "expense-pairwise-subject",
  "txn": "txn-expense-88f2",
  "scope": "expense-report:complete",
  "req_wl": "expense-api",

  "tctx": {
    "identity_continuation": {
      "iss": "https://idp.example/",
      "tenant": "tenant-123",
      "handle": "kW4uJ8pTe2NxA6rQvD1zYs"
    }
  },

  "iat": 1710000012,
  "exp": 1710000072,
  "jti": "tt-expense-0007"
}

{
  "iss": "https://ca.expenses.example/",
  "aud": "https://idp.example/",
  "identity_continuation_handle": "kW4uJ8pTe2NxA6rQvD1zYs",

  "act": {
    "iss": "https://expenses.example/",
    "sub": "expense-service"
  },

  "cnf": {
    "jkt": "base64url-expense-service-key-thumbprint"
  },

  "iat": 1710000020,
  "exp": 1710000200,
  "jti": "b8Rn5Yx1Qe4Nk2Wf6zVc9d"
}

POST /token HTTP/1.1
Host: idp.example
Content-Type: application/x-www-form-urlencoded
DPoP: <proof signed by the expense-service key>

grant_type=urn:ietf:params:oauth:grant-type:token-exchange
requested_token_type=urn:ietf:params:oauth:token-type:id-jag
audience=https://ras.travel.example/
resource=https://api.travel.example/
scope=trips.read
subject_token=<identity-continuation-assertion>
subject_token_type=<identity-continuation-token-type>
actor_token=<sender-constrained expense-service credential>
actor_token_type=urn:ietf:params:oauth:token-type:jwt

{
  "iss": "https://idp.example/",
  "aud": "https://ras.travel.example/",
  "sub": "travel-pairwise-subject",

  "client_id": "expense-service",
  "resource": "https://api.travel.example/",
  "scope": "trips.read",

  "auth_time": 1710000000,
  "acr": "urn:example:loa:2",
  "amr": ["pwd", "mfa"],

  "identity_continuation_handle": "Uc9fB3mHs5LdK7gEnX2wRj",

  "act": {
    "iss": "https://expenses.example/",
    "sub": "expense-service",
    "act": {
      "iss": "https://expenses.example/",
      "sub": "expense-app"
    }
  },

  "cnf": {
    "jkt": "base64url-expense-service-key-thumbprint"
  },

  "iat": 1710000025,
  "exp": 1710000325,
  "jti": "idjag-travel-01"
}

"tctx": {
  "identity_continuation": {
    "iss": "https://idp.example/",
    "tenant": "tenant-123",
    "handle": "Uc9fB3mHs5LdK7gEnX2wRj"
  }
}

{
  "aud": "https://ras.booking.example/",
  "sub": "booking-pairwise-subject",
  "client_id": "travel-service",
  "resource": "https://api.booking.example/",
  "scope": "stays.book",
  "identity_continuation_handle": "Ht6mZ2pQe8VrKx4NcWy1Jd",
  "act": {
    "iss": "https://travel.example/",
    "sub": "travel-service",
    "act": {
      "iss": "https://expenses.example/",
      "sub": "expense-service",
      "act": {
        "iss": "https://expenses.example/",
        "sub": "expense-app"
      }
    }
  }
}

B.2. Background Agent Example (User-Scheduled Continuation)

The user is present when the task is created and absent at every run. Unlike the interactive example, the root hop is bound to durable, platform-owned task authorization. The Scheduler stores only an opaque task identifier; each run derives fresh context from the active authorization (Section 9.3).¶

• Platform domain (platform.example): workload briefing-agent, and PlatformRAS (the platform's own TaskRAS) / Platform TTS / Platform CA, in front of TaskAPI (https://api.platform.example/tasks); the Scheduler is an internal platform component, holding only the task identifier, that triggers each run.¶

• Calendar domain (calendar.example): CalendarRAS only, in front of CalendarAPI. It is terminal in every run, an ordinary ID-JAG Resource Authorization Server that needs no continuation support (Section 9).¶

• Mail domain (mail.example): MailRAS in front of MailAPI, reached only in the dynamic-target scenario below (Appendix B.2.3); likewise terminal.¶

The Scheduler stores only task-123. H0 remains bound to the PlatformRAS task authorization across runs; each run receives a fresh child of H0 for its terminal target.¶

(https://ras.platform.example/, https://api.platform.example/tasks)
    permitted scopes: task.manage

(https://ras.calendar.example/, https://api.calendar.example/)
    permitted scopes: calendar.read

task_id:              task-123
owner:                alice
actor:                briefing-agent
continuation_handle:  Pz6vTq1NcY4kM8bJf3RxWa  # H0
permitted_purpose:    morning-calendar-brief
schedule:             "0 7 * * *"
governing_grant:      grant-8f2c19a4  # internal reference
expiry:               1719450000  # local, not IdP lifetime
status:               active

task_id: task-123

 Scheduler   BriefingAgent      Platform TTS
     |              |                 |
     |---trigger--->|                 | task-123
     |              |-task-123 + key->|
     |              |                 | verify key + task; derive H0
     |              |<-fresh TT(H0)---|

 BriefingAgent    Platform CA       IdP         CalendarRAS
       |               |             |               |
       |--request H0-->|             |               |
       |<-assertion----|             |               |
       |---------------------------->|               |
       |      assertion + DPoP       |               |
       |<----------------------------| ID-JAG(child) |
       |-------------------------------------------->|
       |                 ID-JAG                      |
       |<--------------------------------------------| access token
       |               |             |      no binding (terminal)

HTTP/1.1 400 Bad Request
Content-Type: application/json

{
  "error": "invalid_target"
}

B.3. Gateway Example (Dynamic Upstream Audiences)

AgentApp knows the gateway audience but not the eventual upstream. The gateway knows the upstream but holds no end-user assertion addressed to it. This flow lets the gateway obtain an audience-specific grant without weakening the original assertion's audience check.¶

• AgentPlatform domain (agent.example): client agent-app only, the confidential runtime that hosts Alice's session and roots the chain; it has no Resource Authorization Server of its own in this example.¶

• Gateway domain (gateway.example): workload tool-gateway, and GatewayRAS / Gateway TTS / Gateway CA, in front of the gateway's own tool-invocation surface (resource=https://gateway.example/), scoped under tenant tenant-gw-01.¶

• Wiki domain (wiki.example): WikiRAS only, in front of WikiAPI. It is terminal in this chain, an ordinary ID-JAG Resource Authorization Server that needs no continuation support (Section 9).¶

Alice has pairwise subjects at GatewayRAS and WikiRAS, which only the IdP can map. H0 is the root hop bound at GatewayRAS; H1 is the terminal Wiki hop.¶

The runtime roots the chain at the gateway:¶

 AgentApp          IdP          GatewayRAS       GatewayAPI/TTS
     |               |               |                 |
     |--ID Token---->|               |                 |
     |<-ID-JAG(H0)---|               |                 |
     |------------------ID-JAG------>|                 |
     |<--------------gateway AT------| bind H0         |
     |------------tool request + AT + DPoP----------->|
     |               |               |<-resolve AT-----|
     |               |               |--bound H0------>|
     |               |               |    derive H0 into tctx

After resolving the tool request to Wiki, the gateway continues the chain:¶

 ToolGateway       Gateway CA        IdP          WikiRAS/API
      |                 |             |                 |
      |--request H0---->|             |                 |
      |<-assertion------|             |                 |
      |------------------------------>|                 |
      |       assertion + DPoP        |                 |
      |<------------------------------| ID-JAG(H1)      |
      |------------------------------------------------>|
      |                ID-JAG to WikiRAS                |
      |<------------------------------------------------| wiki AT
      |--------------------call WikiAPI with AT-------->|
      |                 |             |        no binding (terminal)