Identity Continuation Assertion for OAuth 2.0 Token Exchange

1.1. When to Use This Profile Versus Offline Attenuation

Use this profile when a boundary re-mints the user's identity, that is:¶

• the next audience uses a pairwise subject only the IdP can resolve;¶

• the target trusts the IdP, not the previous issuer, to name the user; and¶

• current revocation and policy must be rechecked at every boundary.¶

Use offline attenuation, such as [I-D.li-oauth-delegated-authorization], when the subject and the trusted issuer both stay stable across the boundary and offline delegation semantics are acceptable, for example intra-domain fan-out under one workload identity. The two compose: offline attenuation inside a trust domain, continuation where a boundary re-mints the subject.¶

1.2. 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 handle propagation; and¶

• discovery metadata.¶

3.1. Token Type and Media Type

The Identity Continuation Assertion has token type urn:ietf:params:oauth:token-type:identity-continuation and media type application/oauth-identity-continuation+jwt (Section 11). It is a JWT [RFC7519] in JWS Compact Serialization. The CAI MUST set the JOSE typ header to oauth-identity-continuation+jwt and MUST sign with an asymmetric algorithm the IdP accepts (Section 9.9). The assertion MUST NOT be encrypted (JWE) or use nested signing.¶

3.2. Claims

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

{
  "iss": "https://cai.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": 1710000620,
  "jti": "k7Qm2Xp9Rf4sLc3vBw8aZ1"
}

The claims have the following meanings and requirements:¶

iss:

REQUIRED. The CAI that issued the assertion; the IdP verifies its issuer trust per Section 6.3.4, rule 3, and its signature per rule 2.¶

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 4).¶

act:

REQUIRED. The current actor presenting the Token Exchange request, encoded as a single-level act claim per [RFC8693], with a REQUIRED iss and 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.¶

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.¶

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 is a subject token whose subject the IdP resolves from the referenced hop, not an [RFC7523] JWT-profile assertion. It MUST NOT contain a top-level sub, auth_time, acr, amr, or sid claim (these come from the root-chain envelope), nor the Token Exchange request parameters audience, resource, scope, authorization_details, or requested_token_type (these are supplied by the request). The assertion's aud identifies the IdP, not the requested target.¶

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

6.1. Overview

A continuation reuses the Token Exchange loop once per boundary: the root exchange mints the first ID-JAG, and each later boundary mints the next from an Identity Continuation Assertion. Handles H0 and H1 below name the successive hops (Section 4).¶

  Client      Workload    CAI         IdP         RAS
  |           |           |           |           |
  | base ID-JAG exchange  |           |           |
  |---------------------------------->|           |
  | issue ID-JAG (H0)     |           |           |
  |<----------------------------------|           |
  | present ID-JAG        |           |           |
  |---------------------------------------------->|
  | issue access token, bind H0       |           |
  |<----------------------------------------------|
  |           |           |           |           |
  | carrier surfaces H0 to a later workload       |
  |           |           |           |           |
  |           | request assertion     |           |
  |           |---------->|           |           |
  |           | attest hop, actor, key|           |
  |           |<----------|           |           |
  |           | present assertion     |           |
  |           |---------------------->|           |
  |           | issue ID-JAG (H1)     |           |
  |           |<----------------------|           |

H1 then travels to the next boundary exactly as H0 did, and the loop repeats until a hop reaches a terminal RAS. A hop is PENDING when the IdP issues its ID-JAG, ACCEPTED once the RAS binds it, and CONTINUABLE while a mapped CAI attests the still-active binding (Section 6.5). The workload that continues is a later party, not the original client that established the chain.¶

Each role validates only within its authority, and no artifact or role alone authorizes continuation (Section 9.7). The sections that follow trace artifact production and processing: the CAI issues the assertion (Section 6.2), the IdP validates the exchange and issues the next ID-JAG (Section 6.3), the accepting RAS binds and processes it (Section 6.4), and the domain surfaces the handle to later continuers (Section 6.6).¶

6.2. Issuing the Assertion

The CAI mints the Identity Continuation Assertion a workload presents to continue a chain across a boundary. It MUST issue only for an actor in the attested RAS's trust domain; actor authentication and the issuance protocol are deployment-specific. The CAI MUST set the assertion's aud to the IdP recorded in the hop's RAS binding (Section 6.4); it MUST NOT accept an IdP audience supplied by the requester.¶

The current actor is a control-plane participant, not a bare-handle transporter: it presents the handle read from its own intra-domain context, with its key and any narrowing hints, to its CAI. The handle is advisory input, re-verified against RAS-bound state (Section 6.5) by the checks below before any assertion issues.¶

The CAI 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 current actor is authorized under CAI policy to continue the chain;¶

3. the current actor controls the key placed in cnf;¶

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

5. the actor is bound to the current transaction and the handle matches that transaction's RAS-bound state; and¶

6. a recheck against authoritative RAS state confirms the authorization remains active and continuation remains permitted.¶

Possession of a handle or carrier token alone is insufficient. Target or purpose hints can narrow CAI issuance but MUST NOT control the IdP's target decision, and propagated context MUST NOT override the root-chain envelope.¶

6.3. Token Exchange

An Identity Continuation Assertion is used as the subject_token of an OAuth 2.0 Token Exchange request [RFC8693]. The root exchange and a continuation exchange use the same Token Exchange framework: a continuation exchange substitutes an Identity Continuation Assertion for the root credential and additionally supplies the actor authentication and DPoP proof described below. The IdP establishes the chain; no request parameter asks it to do so (Section 6.3.2).¶

POST /token HTTP/1.1
Host: idp.example
Content-Type: application/x-www-form-urlencoded
DPoP: <proof of possession of the cnf 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=<id_token | refresh_token | SAML assertion>
&subject_token_type=<normal-subject-token-type>
&client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer
&client_assertion=<JWT>

POST /token HTTP/1.1
Host: idp.example
Content-Type: application/x-www-form-urlencoded
DPoP: <proof of possession of the cnf 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=urn:ietf:params:oauth:token-type:identity-continuation
&actor_token=<sender-constrained-current-actor-credential>
&actor_token_type=<actor-token-type>
&client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer
&client_assertion=<JWT>

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache

{
  "issued_token_type": "urn:ietf:params:oauth:token-type:id-jag",
  "access_token": "<continuation-capable ID-JAG, compact JWS>",
  "token_type": "N_A",
  "expires_in": 300
}

{
  "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"
}

6.4. Continuation-Aware RAS Processing

Only a RAS from which continuation occurs implements this extension. A terminal RAS processes an ordinary ID-JAG and ignores the handle; because no later continuation uses the terminal hop, the RAS need not bind its handle.¶

A continuation-aware Resource Authorization Server, one that implements this extension and advertises the continuation grant profile (Section 7), MUST, on accepting a continuation-capable ID-JAG:¶

1. accept the ID-JAG per [I-D.ietf-oauth-identity-assertion-authz-grant], which includes validating the grant, authenticating the presenting client, verifying the sender constraint, applying local authorization policy, and issuing an access token sender-constrained to the confirmed key; and¶

2. bind identity_continuation_handle, the ID-JAG's issuer and tenant, and the confirmed key to the authorization state it establishes, recording whether continuation is permitted.¶

The RAS MUST bind the handle and issue the access token as one outcome: no access token without its binding, and no binding without a token. Repeated redemption of one ID-JAG MUST bind to the same hop authorization record, so a retry cannot create multiple records for one grant. The RAS MUST NOT place the handle in an access token, external authorization claim, or protected-API authorization input. It exposes the binding only privately within its trust domain.¶

6.5. Hop Activation

A hop moves through three states, spanning the IdP, RAS, and CAI. These are conceptual states, not values carried on the wire. The IdP creates it PENDING. Successful RAS binding makes it ACCEPTED. A mapped CAI 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 CAI lets the IdP evaluate the hop as CONTINUABLE for one request; CONTINUABLE is not stored but holds only while rules 3, 4, and 5 of Section 6.3.4 hold for that request.¶

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 CAI attestation.¶

The CAI 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 CAI having rechecked authoritative RAS state before attesting (Section 6.2). Absent CAI compromise (Section 9.7), an issued-but-rejected ID-JAG cannot be continued because no mapped CAI may attest it. A mapped CAI is mandatory; its absence fails closed.¶

Acceptance gates continuation but does not bound downstream authority: the IdP evaluates later targets against the root envelope, and local RAS authorization neither narrows nor widens it.¶

6.6. Intra-Domain Handle Propagation

Within a trust domain, an authorized workload learns the accepted hop's handle from a trusted intra-domain carrier. The carrier:¶

• MUST be server-derived and MUST bind the handle, its originating IdP and tenant, and the current credential and key to the RAS authorization;¶

• MUST NOT be supplied or overridden by the requester;¶

• MUST NOT be accepted outside the trust domain; and¶

• MUST be re-derived when replaced.¶

The specific carrier is deployment-specific: a Transaction Token [I-D.ietf-oauth-transaction-tokens] is one realization (Appendix A.2).¶

Before deriving, the protected endpoint or carrier MUST validate live proof of possession of the confirmed key presented on the current call, and MUST derive the handle from the authorization record bound to that verified credential, key, and RAS state, never from a session or subject, which could otherwise bind the wrong user's authorization state to this call.¶

Authorized intra-domain workloads MAY read the handle. They MUST NOT place it in access tokens, external authorization claims, responses, webhooks, errors, or calls to non-participants; deployments also keep it out of logs and traces. The handle conveys no authority.¶

7.1. IdP 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 continuation-capable ID-JAG is still the urn:ietf:params:oauth:token-type:id-jag type, so this flag advertises the capability rather than a new token type. It composes additively with base ID-JAG discovery: an IdP that sets this flag also lists urn:ietf:params:oauth:token-type:id-jag in its identity_chaining_requested_token_types_supported ([I-D.ietf-oauth-identity-assertion-authz-grant]), and the flag signals only the added acceptance of continuation assertions and issuance of handle-carrying ID-JAGs.¶

7.2. Resource Authorization Server Metadata

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 6.4). 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]).¶

A Resource Authorization Server MAY advertise the Continuation Assertion Issuers it authorizes to attest the hops it accepts, so the IdP can discover the nominated issuers rather than be configured out of band (Section 9.7):¶

identity_continuation_issuers:

OPTIONAL. A JSON array of CAI issuer identifiers, each a StringOrURI [RFC7519], that this Resource Authorization Server authorizes to attest hops it accepts; an empty array authorizes none. Values are compared with the assertion iss as exact, case-sensitive strings, and duplicates are ignored. The advertisement is a nomination only: the IdP MUST establish each issuer's identity and signing keys independently, and the advertisement alone MUST NOT establish key trust or override the IdP's tenant issuer-pairing policy. Because the IdP evaluates issuer trust and keys against its current trusted issuer and key state, removing an issuer or revoking its keys de-authorizes it for existing chains. Acceptance remains the IdP's decision.¶

When a CAI's issuer identifier is that of an OAuth authorization server, the IdP obtains its signing keys from the jwks_uri in that server's metadata ([RFC8414]); a CAI without such a jwks_uri, like any other CAI, uses authenticated configuration. A RAS nomination MUST NOT by itself trigger that retrieval or authorize the issuer; the IdP applies its own issuer policy first. The IdP MUST refresh remotely obtained keys under a bounded cache policy, so a key removed from the JWK Set stops validating once the refresh takes effect.¶

9.1. Sender Constraint and Proof of Possession

A continuation assertion names the actor the IdP will treat as the chain's current holder. As a bearer token it would let any party that captured it, in transit, from a log, or from a compromised intermediary, continue the chain as that actor. The assertion MUST NOT be accepted as a bearer token [RFC7800]; every exchange requires live proof of possession of the cnf key via a DPoP proof [RFC9449] (Section 6.3.3). A captured assertion is therefore useless without the private key, and because the onward ID-JAG is bound to the same key (Section 6.3.3), possession is demonstrated continuously across the chain, not once at issuance.¶

9.2. Durable Task Authorization

Scheduled continuation MUST derive from durable RAS task authorization, not a scheduler-held handle, which would become 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 re-derives the handle from active task state and still requires an assertion from a mapped CAI.¶

9.3. Short Lifetime and Replay

The 300-second ceiling and the single-use (iss, jti) reservation (Section 6.3.5) confine replay to the IdP continuation exchange. The request fingerprint bound by that reservation ties each assertion to the one request it first authorized; without it, a resubmitted assertion could authorize a second, different request within its window.¶

9.4. Root Authentication Context

Downstream resources may gate access on authentication strength (acr) or methods (amr); if continuation could raise those claims, an actor could reach a step-up-gated resource the user never authenticated strongly enough for. Authentication context therefore comes only from the root envelope, copied unchanged into onward ID-JAGs (Section 6.3.7).¶

9.5. Envelope Enforcement and Offline Attenuation

The envelope bounds every target and authority. The CAI 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 intra-domain carrier establishes the authoritative association between the request and the handle by deriving it from the current credential's RAS-bound state (Section 6.6); a handle a workload supplies is not authoritative, and the CAI rejects substitution.¶

Keeping CAI issuance in-domain (Section 6.2) prevents a handle-holding party from bypassing the RAS-acceptance path.¶

9.6. Trust in Actor Token Issuers

The actor_token authenticates the current actor to the IdP, so a rogue or over-scoped actor-token issuer is an impersonation vector: a party controlling one issuer could mint a token naming an actor in another domain or tenant and continue that actor's chains. The IdP MUST accept actor tokens only from issuers trusted for the actor's own domain and tenant, and MUST reject an untrusted or out-of-scope issuer even when a valid CAI assertion accompanies it. CAI attestation of the hop and actor-token authentication of the actor are independent checks (Section 9.7); neither substitutes for the other.¶

9.7. Conjunctive Trust and Issuer Pairing

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

• the CAI mapped to the presented hop's accepting Resource Authorization Server, which attests the chain-to-actor transition (Section 6.3.4, rule 3);¶

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

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

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

The IdP MUST authorize CAI and actor-token issuer pairings per tenant; separate trust in each is insufficient. Tenant determination MUST derive from authenticated material, not requester-supplied input. The IdP MUST scope CAI trust by issuer, keys, tenant, and mapped RAS. Because the IdP records the accepting Resource Authorization Server for each hop, it MAY learn the candidate mapping from that server's advertised identity_continuation_issuers (Section 7). That advertisement is a nomination only: it scopes each server to naming issuers for its own hops but does not itself establish issuer or key trust. The IdP independently authenticates each CAI issuer and its signing keys (Section 7), and tenant policy authorizes the resulting server, CAI, and actor-token-issuer combination. Absent the advertisement, the mapping is configured out of band.¶

One operator may run the RAS, carrier, and CAI. Co-locating these anchors trades away the defense in depth the conjunction otherwise provides, so where independent acceptance evidence matters, deployments can separate them or audit the binding-to-attestation path. If the IdP is also co-located, even the envelope backstop becomes organizational rather than protocol-separated.¶

A compromised mapped CAI can 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 (Section 6.5) is only as trustworthy as the mapped CAI. Because the IdP has no channel to recheck RAS state itself, a CAI attesting from a cached read could attest a hop the RAS has since revoked; the authoritative recheck required at issuance (Section 6.2) narrows this window but does not close it, since revocation after issuance still lands within the assertion's lifetime plus any delay in RAS state reaching the CAI.¶

9.8. Actor Chain Integrity

The act lineage records who has acted in the delegation. A compromised actor could try to forge it, to hide its own identity, impersonate a more privileged prior actor, or fabricate a delegation that never happened. This profile denies that by construction: an assertion names only the current actor, and the IdP builds the onward lineage itself by walking the hop's immutable parent references (Section 6.3.7), never by copying a chain the assertion supplies. The IdP MUST reject any mismatch between the current actor and the assertion's act. Because lineage derives from IdP-held state rather than assertion input, a party cannot rewrite history it does not control; offline-attenuation segments, which the IdP does not observe, do not enter lineage.¶

9.9. Token, Type, and Algorithm Confusion

An attacker may try to pass one token type off as another, downgrade the signature algorithm, or steer verification to a key it controls. 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.¶

9.10. Metadata Disclosure

Advertising identity_continuation_issuers (Section 7) in publicly readable authorization server metadata reveals which CAIs a Resource Authorization Server authorizes to attest its hops, and can thereby disclose federation topology, tenant relationships, and deployment structure, the same disclosure concern the base ID-JAG profile raises for issuer-specific metadata. A deployment whose CAI relationships are sensitive SHOULD omit the advertisement and convey the nomination out of band or through access-controlled discovery.¶

11.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 6.3.8¶

11.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 3.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 7, Section 6.4¶

11.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 9 of this document.¶

Interoperability considerations:

N/A¶

Published specification:

This document, Section 3.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¶

11.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 continuation 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 is not placed in an access token or a Resource Server's external authorization claims (Section 4, rule 3).¶

Change Controller:

IETF¶

Specification Document(s):

This document, Section 4¶

11.5. OAuth Authorization Server Metadata Registration

IANA is requested to register the following values 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 7¶

Metadata Name:

identity_continuation_issuers¶

Metadata Description:

Array of issuer identifiers for Continuation Assertion Issuers (CAIs) a Resource Authorization Server authorizes to attest hops it accepts (a nomination; the IdP establishes issuer key trust independently)¶

Change Controller:

IETF¶

Specification Document(s):

This document, Section 7¶

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.¶

12.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>.

[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>.

12.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-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>.

[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 1.1: 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). 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 CAI 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 CAI attest the authenticated actor, key, accepted hop, and any intra-domain policy checks that the IdP cannot observe. It also keeps the IdP's trust coarse: the IdP trusts a CAI mapped to the accepting Resource Authorization Server (the audience the ID-JAG names), scoped per tenant. That CAI abstracts the actors, keys, and continuation policy within its trust domain, so the IdP authorizes mapped CAIs rather than the individual actors behind them. The assertion does not authorize target or scope. Where that domain-local attestation is unnecessary, a recipient-bound direct grant remains a possible simplification, but it forces the IdP to authenticate every actor and hold per-actor policy directly, which does not scale across domains.¶

A.6. Why Asymmetric Signing Only

This profile requires asymmetric signing and forbids encryption and nested signing (Section 3.1), tighter than RFC 8725 [RFC8725], which also permits verified symmetric algorithms. The restriction is deliberate: asymmetric verification avoids distributing a shared secret across domains and the key-confusion risk a symmetric key between the CAI and IdP would create (Section 9.9); TLS on every hop and the assertion's minimal contents make encryption unnecessary; and a single compact signed form removes an interoperability choice between issuers and verifiers.¶

B.1. Three-Hop Interactive Example

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/.¶

The authorization path, the sequence of accepting RASes, differs from that API-call path:¶

ExpenseApp -> ExpenseRAS -> TravelRAS -> BookingRAS

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 two roles: a Resource Authorization Server that binds the accepted hop and a CAI that attests continuation, plus a trusted intra-domain carrier, realized here as a Transaction Token Service (TTS), that derives its chain context. A deployment may co-locate these.¶

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

• Travel domain (travel.example): workload travel-service, and TravelRAS / Travel TTS / Travel CAI, 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 6.4).¶

• 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 in the ID-JAG addressed to terminal BookingRAS, which never binds it.¶

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 CAI        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://cai.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=urn:ietf:params:oauth:token-type:identity-continuation
&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.2).¶

• Platform domain (platform.example): workload briefing-agent, and PlatformRAS (the platform's own TaskRAS) / Platform TTS / Platform CAI, 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.¶

• 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+proof->|
     |              |                 | verify proof + task; derive H0
     |              |<-fresh TT(H0)---|

 BriefingAgent    Platform CAI       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
Cache-Control: no-store
Pragma: no-cache

{
  "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 CAI, 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.¶

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
     |               |               |
     |--ID Token---->|               |
     |<--ID-JAG(H0)--|               |
     |----------------ID-JAG-------->| bind H0
     |<-------------gateway AT-------|

To reach Wiki, the gateway continues the chain:¶

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