Identity Continuation Assertion for OAuth 2.0 Token Exchange

5.1.1. Root Exchange Request

The root exchange 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 to issue a continuation-capable ID-JAG. The request presents a subject token supported by the base profile, such as an ID Token, refresh token, or SAML assertion:¶

POST /token HTTP/1.1
Host: idp.example
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:token-exchange
&requested_token_type=urn:ietf:params:oauth:token-type:id-jag
&audience=https://ras.gateway.example/
&resource=https://gateway.example/
&scope=tools.invoke
&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>

Processing an actor_token on the root exchange is outside the scope of both this document and the base profile ([I-D.ietf-oauth-identity-assertion-authz-grant], Section 4.3.3), and the root actor is the authenticated client (Section 5.1.3).¶

5.1.2. Chain Establishment

The IdP MUST establish a chain when tenant policy permits continuation for the root exchange and the root subject token resolves to a lifecycle anchor (Section 6.1). To establish a chain, the IdP MUST include the root handle in the ID-JAG. Absent permission to continue, the IdP MUST NOT establish a chain or include an identity_continuation_handle.¶

Tenant policy may also restrict establishment to particular clients, grants, or targets.¶

The lifecycle anchor is the user's active IdP session or, for a durable chain, a refresh token's OAuth grant. When the subject token resolves to no anchor, the IdP issues the ID-JAG without a handle, as under the base profile. No request parameter requests chain establishment. Advertised support (Section 7.1) indicates capability and does not authorize establishment.¶

For every hop it creates, root or child, the IdP MUST record the RAS audience placed in the ID-JAG; the issuers it trusts to attest that RAS's hops are read from current tenant configuration at each exchange (Section 7.3).¶

Establishment is at-least-once. Retrying a lost response MAY create a second chain, and the limits of Section 6.3 apply across every chain rooted in one chain authorization.¶

5.1.3. Root Actor

The root actor is the authenticated OAuth client, identified by the mapping in Section 5.5.2. The base profile's recommendation to use a confidential client applies to a root exchange that establishes a chain.¶

This document places no proof-of-possession requirement on the root exchange. The root client's obligations are those of the base profile, and sender constraint becomes a requirement for an actor that continues (Section 5.5.2).¶

5.1.4. Chain Authorization

The IdP MUST associate each chain with the chain authorization under which it was established. The IdP records:¶

• the authenticated user and tenant;¶

• the root actor;¶

• the authentication context (auth_time, acr, amr);¶

• the lifecycle anchor; and¶

• restrictions on which actors may continue and what authority they may obtain.¶

The representation is implementation-specific. The association, root facts, and restrictions remain fixed for the chain's lifetime. Later requests or policy changes cannot replace the authorization, change those facts, or relax those restrictions.¶

The IdP authorizes each continuation under the recorded chain authorization and current policy (Section 5.5.3). Policy can restrict access but cannot exceed that authorization. Policy evaluation is outside the scope of this document.¶

The root request's audience and scope describe the root ID-JAG. They do not by themselves authorize or limit later targets. RAS-local permissions and CAI attestation do not independently authorize onward access.¶

5.2.1. Hop Acceptance

Two parties hold facts about a hop, neither carried on the wire:¶

The IdP learns of acceptance through a trusted CAI's attestation and maintains no synchronized acceptance state (Section 1.1). The CAI attests only hops the RAS has accepted. A RAS acting as CAI attests its own hops; a separate CAI confirms acceptance and activity according to the RAS's authorization semantics (Section 5.4).¶

An issued hop cannot be continued without a trusted CAI's attestation. Unless the CAI is compromised (Section 9.4), no trusted CAI attests an issued-but-rejected ID-JAG, so continuation fails closed.¶

A hop is continuable while a CAI trusted for its RAS can attest it as accepted and still active, and neither it nor any ancestor is revoked; whether a particular continuation from it succeeds is decided by the validation rules of the continuation exchange (Section 5.5.3).¶

RAS acceptance and recorded eligibility (Section 5.2) are prerequisites for CAI issuance. The IdP authorizes downstream access under the chain authorization and current policy (Section 5.5.3).¶

5.4.1. Assertion Issuance Request

A CAI that is an OAuth authorization server, including a RAS acting as its own CAI, MAY issue assertions from its token endpoint using Token Exchange [RFC8693] as profiled in this and the following subsections. Such a RAS SHOULD support this method of issuance, so that a workload in its domain has one request to implement. Issuance by other means remains deployment-specific (Section 5.3).¶

A workload obtains assertions from the token endpoint of the CAI its deployment designates. For a RAS acting as its own CAI, this is the RAS's token endpoint, discoverable through the RAS's metadata (Section 7.2); a separate CAI is configured within the trust domain, which this document leaves to the deployment (Section 5.3).¶

The current actor acts as an OAuth client of the CAI. It makes a Token Exchange request to the CAI's token endpoint with the following parameters:¶

grant_type:

REQUIRED. The value urn:ietf:params:oauth:grant-type:token-exchange.¶

requested_token_type:

REQUIRED. The value urn:ietf:params:oauth:token-type:identity-continuation.¶

subject_token:

REQUIRED. Either the access token the client received on the call it is continuing, or the Transaction Token that carries the hop's handle for that call.¶

subject_token_type:

REQUIRED. urn:ietf:params:oauth:token-type:access_token or urn:ietf:params:oauth:token-type:txn_token [I-D.ietf-oauth-transaction-tokens], matching the subject_token.¶

The audience, resource, scope, actor_token, and actor_token_type parameters MUST NOT be included: targets and scope are chosen at the IdP exchange (Section 3.2), and the authenticated client is the actor named in act.¶

The following example carries the client's authentication and its DPoP proof (Section 5.4.2):¶

POST /token HTTP/1.1
Host: cai.example
Content-Type: application/x-www-form-urlencoded
DPoP: <proof of possession of the key to be placed in cnf>

grant_type=urn:ietf:params:oauth:grant-type:token-exchange
&requested_token_type=urn:ietf:params:oauth:token-type:identity-continuation
&subject_token=<access token presented to the client>
&subject_token_type=urn:ietf:params:oauth:token-type:access_token
&client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer
&client_assertion=<JWT>

5.4.2. Client Authentication

The client MUST authenticate to the CAI's token endpoint ([RFC6749], Section 2.3). The client MUST include in the request a DPoP proof [RFC9449] of the client's own key. The CAI MUST verify that proof and bind the assertion to the proven key in cnf. The CAI's verification is defense in depth: the actor proves possession of that key again to the IdP at the continuation exchange, which is the security boundary for continuation (Section 5.5.2).¶

The CAI MUST issue only for an actor it is authoritative to associate with the RAS-accepted authorization, typically one in the RAS's trust domain; actor authentication is deployment-specific.¶

5.4.3. Request Validation

The CAI MUST verify that the subject_token is of the type its subject_token_type declares (Section 5.4.1) and is one of the following:¶

• an access token the accepting RAS issued, that RAS being one whose hops the CAI attests, unexpired, and valid for a protected resource that the authenticated client operates, as determined from the CAI's registration or configuration of that client; or¶

• a Transaction Token valid for the CAI's trust domain under [I-D.ietf-oauth-transaction-tokens], Section 12.2, carrying the typ header and issuer that specification defines, and carrying the hop's handle as chain context (Section 5.3, Section 5.4.6).¶

A token of another type presented as subject_token, such as an ID-JAG or an Identity Continuation Assertion, is unacceptable (Section 5.4.5).¶

With an access token, the client is a resource server exchanging a token it received, the scenario of the example in [RFC8693], Section 2.3. A RAS acting as CAI resolves its own token; a separate CAI resolves it as Section 5.4.6 describes. In this exchange the subject_token identifies the RAS authorization context from which continuation is requested; its subject is not copied into the resulting assertion.¶

Either subject_token type supplies the facts below. The CAI MUST authenticate the actor and issue only after establishing these facts:¶

1. The handle came through an authenticated, confidential, integrity-protected channel or equivalent authenticated state.¶

2. The current actor controls the key placed in cnf.¶

3. act names that actor. If offline attenuation reached the actor, the attenuated credential it received, the subject_token or the carrier that conveyed it, is valid (Appendix A.1).¶

4. The handle is the one bound to the authorization context the actor presents, its access token or carrier, and the actor is a party that context was issued or forwarded to (Section 5.3, Section 5.2.1). Selecting another intact context is the actor's choice; substituting a handle within a context is not. The handle is input to verify, never authority in itself (Section 4).¶

5. Evidence that is authoritative by the RAS's own authorization semantics, whatever the carrier, confirms that the authorization remains active and that its binding still records it as eligible for continuation. That evidence is either a recheck of RAS authorization state or, where the RAS's authorization is a self-contained short-lived token the RAS itself issued, that token's validity (Section 5.4.6).¶

The subject token's integrity protection and the authenticated request establish fact 1; the DPoP proof, fact 2; client authentication, fact 3, whose attenuation condition the CAI establishes by validating the attenuated credential it received; and the bound handle and the RAS's acceptance evidence, facts 4 and 5.¶

Section 9.1 traces the binding chain these facts form from ID-JAG to assertion.¶

A live recheck SHOULD be used where the tenant requires withdrawal of a hop's authorization to stop fresh assertions before the RAS's token would expire. With self-contained evidence, the CAI stops issuing when that token expires, as for any OAuth access token. Where the evidence is a self-contained token, the assertion's exp SHOULD NOT exceed that token's expiry, so that an assertion is not presentable after the evidence that supported it has lapsed (Section 6.2).¶

A domain may add its own conditions for issuing, for example limiting which of its workloads may obtain assertions, but such conditions narrow issuance only. Target or purpose hints can narrow CAI issuance, but neither they nor propagated context expand the authority the IdP may issue (Section 5.5.3).¶

5.4.4. Successful Response

A successful response is a Token Exchange response ([RFC8693], Section 2.2.1) in which access_token carries the Identity Continuation Assertion, issued_token_type is urn:ietf:params:oauth:token-type:identity-continuation, token_type is N_A (not applicable), and expires_in reflects the assertion's lifetime. The access_token member is the [RFC8693] response container; the assertion is not an OAuth access token, which token_type N_A signals. This document adds one parameter:¶

identity_continuation_authorization_server:

REQUIRED. A JSON string containing the issuer identifier ([RFC8414]) of the authorization server at which the client exchanges the assertion for an ID-JAG. The CAI MUST set its value to the assertion's aud claim. The client uses this parameter to identify the IdP without decoding the assertion.¶

The client obtains that IdP's token_endpoint from its authorization server metadata ([RFC8414]), retrieved with the oauth-authorization-server well-known URI suffix under the issuer identifier. Before sending the assertion or its own credentials there, the client MUST confirm that the returned issuer exactly matches identity_continuation_authorization_server. Where the IdP publishes no metadata, the client uses configuration bound to that issuer identifier (Section 7).¶

The client SHOULD present the assertion only to an IdP it is configured to trust; this parameter identifies the destination but does not establish trust.¶

The CAI MUST NOT include a refresh_token in the response, which would let a client obtain further assertions without presenting a token or passing the acceptance check.¶

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:identity-continuation",
  "access_token": "<Identity Continuation Assertion, compact JWS>",
  "token_type": "N_A",
  "identity_continuation_authorization_server": "https://idp.example/",
  "expires_in": 180
}

5.4.5. Error Response

On failure, the CAI returns an error response according to [RFC6749], Section 5.2, and [RFC8693], Section 2.2.2. This document specifies the following error mappings:¶

• invalid_request when the subject_token is invalid or unacceptable under policy, including when it is unknown, expired, revoked, not of the type its subject_token_type declares, not valid for a resource the client operates, has no bound handle, or names an authorization whose binding does not record it as eligible for continuation, or when the request includes a parameter this document prohibits (Section 5.4.1);¶

• unauthorized_client when the client is not permitted to use this grant type; and¶

• invalid_dpop_proof ([RFC9449]) for a failed proof.¶

DPoP nonce processing and the use_dpop_nonce error apply unchanged from [RFC9449].¶

5.4.6. Separate CAI

A separate CAI MUST obtain the handle and evidence of RAS acceptance and continued eligibility from a source authoritative for that RAS within its domain (Section 8.1):¶

• the RAS's authorization state;¶

• its introspection response [RFC7662]; or¶

• a self-contained short-lived token issued by the RAS.¶

For an access-token subject_token (Section 5.4.1), the CAI uses introspection or validates a self-contained token.¶

The handle alone does not convey the originating IdP, tenant, or eligibility for continuation. The introspection response's active member reports token activity, not continuation eligibility ([RFC7662], Section 2.2). A separate CAI relying on introspection therefore obtains the eligibility and the originating IdP and tenant from deployment-defined evidence or configuration, as the requirement above already demands.¶

With a Transaction Token, the handle arrives through the carrier of Section 5.3. Validating that token alone does not establish RAS acceptance or eligibility for continuation.¶

The IdP accepts a separate CAI's attestation only where it trusts that CAI to attest the accepting RAS's hops, from tenant configuration (Section 7.3, the issuer-trust rule of Section 5.5.3).¶

5.5.1. Continuation Request

A continuation exchange presents an Identity Continuation Assertion, a DPoP proof of the cnf key, and the actor's client authentication (Section 5.5.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=<identity-continuation-assertion>
&subject_token_type=urn:ietf:params:oauth:token-type:identity-continuation
&client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer
&client_assertion=<JWT>

The request carries no actor_token or actor_token_type: the actor named in act is the authenticated client (Section 5.5.2), and the IdP rejects a request carrying either (Section 5.5.3, Section 5.5.6).¶

The continuation request, never the assertion, supplies the requested audience, resource, scope, requested_token_type, and any authorization_details [RFC9396] (Section 3.2). A request can carry multiple resource indicators [RFC8707]. The authorization rule (Section 5.5.3) applies to authorization_details and to scope alike.¶

5.5.2. Client Authentication

The current actor MUST authenticate as an OAuth client with a credential that resolves to its canonical actor identity. The canonical actor identity is the (iss, sub) pair the IdP holds for that client.¶

The iss member identifies the actor's identity authority, which determines issuer pairing (Section 5.5.3, Section 9.4) independently of the credential parameter. If the client registration specifies no other canonical actor identity, iss is the IdP's issuer identifier and sub is the client_id. This applies, for example, to a client registered without a workload identity that authenticates with a client secret or mutual-TLS certificate.¶

The IdP MUST derive that pair from its registration of the client or its configuration of the client's credential issuer, not from the client authentication method, and MUST NOT accept a self-asserted mapping.¶

For [RFC7523] client authentication, the IdP MUST authorize the assertion's issuer for the authenticated client. The canonical actor identity remains the pair derived from the IdP's configuration (Appendix A.4).¶

This mapping applies to every exchange. Client authentication identifies the root actor; this profile adds no proof-of-possession requirement to the root exchange (Section 5.1). On a continuation exchange (Section 5.5.1), the IdP MUST also match the canonical actor identity to the assertion's act.¶

The comparison runs between actor identities, never between a raw OAuth client identifier and an act value:¶

authenticated OAuth client
        |  authoritative mapping (IdP registration)
        v
canonical actor identity (iss, sub)
        ^
        |  equal
       act

The IdP MUST compare the actor iss and sub as case-sensitive strings with no transformation or canonicalization ([RFC7519]): the assertion's act is compared with the canonical actor identity, and identities in different tenants never compare equal.¶

The actor MUST prove possession of the key in cnf; for the jkt method, that proof is a DPoP proof [RFC9449]. The IdP MUST bind the onward ID-JAG to a key the actor proves in the request. This version defines only DPoP confirmation; the target validates it using [RFC9449]. Support for mutual-TLS confirmation [RFC8705] remains an open question (Appendix C).¶

A request contains one DPoP proof, so the assertion and resulting ID-JAG are bound to the same key. Client authentication may use an independent credential. Other confirmation methods could support different keys (Appendix C). Key rotation takes effect when the actor obtains an assertion bound to the new key.¶

5.5.3. Request Validation

Where the IdP offers idempotent retry, a presentation whose (iss, jti) matches an ISSUED reservation, as Section 5.5.7.1 defines, is processed under that section; an IdP that does not offer retry rejects every second presentation (Section 5.5.7). For a first presentation, the IdP MUST reject the request unless every rule below holds. Section 5.5.6 specifies error precedence when multiple rules fail.¶

1. Request parameters.¶

   • exactly one each of grant_type, subject_token, subject_token_type, requested_token_type, and audience, and no actor_token or actor_token_type ([RFC8693], Section 2.1);¶

   • zero or more resource, treated as an order-independent set, and at most one each of scope and authorization_details, all OPTIONAL and, when present, evaluated by the authorization rule; and¶

   • grant_type is urn:ietf:params:oauth:grant-type:token-exchange, subject_token_type is urn:ietf:params:oauth:token-type:identity-continuation, and requested_token_type is urn:ietf:params:oauth:token-type:id-jag;¶

2. Assertion well-formedness.¶

   • the assertion is a JWT whose JOSE typ header is oauth-identity-continuation+jwt;¶

   • it is a JWS in Compact Serialization, and is neither a JWE nor a nested JWT (Section 3.1);¶

   • it carries exactly one value for each claim required by Section 3.2 and none of the claims that section forbids;¶

   • iss, aud, identity_continuation_handle, and jti are non-empty strings, act and cnf are JSON objects with cnf naming exactly one confirmation method, and iat, exp, and any nbf are NumericDate numbers;¶

   • act carries none of the members Section 3.2 forbids (exp, nbf, aud, scope, cnf, and a nested act);¶

   • aud exactly matches the IdP's issuer identifier;¶

   • the signature validates with the issuer's resolved signing keys (Section 7);¶

   • alg is neither none nor a symmetric algorithm and is on the IdP's allowlist (Section 9.7, [RFC8725]); and¶

   • the signing key comes from trusted issuer configuration, not from a jku, x5u, or embedded jwk header, though kid MAY select among the configured keys;¶

3. Issuer trust.¶

   • the assertion iss is either the accepting RAS itself, identified by the ID-JAG aud recorded for the hop as a string or one-element array, or another issuer the IdP trusts to attest that RAS's hops, recorded from tenant configuration (Section 7.3); and¶

   • in either case, that issuer is trusted for the chain's tenant, recorded at establishment, and authorized to pair, for that tenant, with the actor's identity authority (Section 5.5.2);¶

4. Chain state.¶

   • the handle identifies a hop the IdP issued, on an active chain, that the assertion attests as accepted: a valid assertion from a CAI the IdP trusts for that hop's RAS is itself that attestation; no claim in the assertion carries it (Section 5.2.1);¶

   • neither the presented hop nor any ancestor is revoked;¶

   • the actor lineage that results from merging consecutive same-actor entries, as the onward act will (Section 5.5.5), is within its actor-lineage depth bound, which counts lineage entries, not hops; and¶

   • the continuation is within the fan-out, rate, and hop-count limits of the chain authorization (Section 6.3);¶

5. Current actor and binding.¶

   • act is present, conforms to the schema of Section 3.2, and identifies the current actor, the canonical actor identity of the authenticated client (Section 5.5.2);¶

   • the request proves possession of the cnf key with a matching DPoP proof (Section 5.5.2, [RFC9449]); the assertion is never accepted as a bearer token ([RFC7800]); and¶

   • the IdP can resolve, for the requested audience, both the user's subject identifier and the actor's client identifier (Section 5.5.5);¶

6. Freshness and replay.¶

   • iat is within the IdP's permitted clock skew, exp follows iat, the assertion is unexpired within that same skew, and any nbf has passed within it ([RFC7519], Section 4.1.5). One skew value applies to iat as future skew, to exp as past skew, and to reservation retention (Section 5.5.7); it SHOULD NOT exceed 60 seconds;¶

   • the assertion's lifetime does not exceed the maximum the IdP accepts (Section 3.2); and¶

   • jti is not yet reserved for the assertion issuer (Section 5.5.7); where the IdP offers idempotent retry, a presentation matching an ISSUED reservation is recovery (Section 5.5.7.1), not a continuation exchange, and any other reserved jti is rejected;¶

7. Authorization. The IdP MUST issue an ID-JAG only if the chain authorization associated with the referenced hop (Section 5.1.4) and current policy permit the authenticated actor to continue from that hop and permit the authority represented by the resulting ID-JAG. This evaluation includes the audience, resources, scopes, and authorization details, including any default scope or other defaults the IdP applies under its policy. An omitted scope uses a policy default or results in invalid_scope ([RFC6749], Section 3.3). An omitted resource does not by itself require a default. The IdP MUST reject the request if it cannot establish that authorization.¶

   The issued ID-JAG carries the scope, resource, and authorization_details values that express the granted authority. Target or purpose hints reaching the CAI (Section 5.4.3) MUST NOT control the IdP's target decision, and propagated context MUST NOT expand the authority permitted by the chain authorization and current policy. The IdP evaluates each authorization detail according to its type ([RFC9396]) and rejects a type whose authorization semantics it does not implement.¶

5.5.4. Successful Response

The response to a continuation exchange follows the base ID-JAG profile: the IdP returns the ID-JAG in access_token, with token_type N_A (not applicable; [RFC8693], Section 2.2.1). The IdP MUST NOT include a refresh_token: a renewable credential would let the workload obtain further grants without fresh CAI attestation, or root a new chain through the refresh-token anchor, outside the hop's revocation dependencies.¶

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
}

On success, the IdP MUST record a child hop (Section 5.2.1) of the presented hop before returning an ID-JAG carrying the resolved target sub and the child hop's fresh handle. An idempotent retry (the freshness rule; Section 5.5.7.1) instead returns the previously issued grant unchanged, creating no new hop or handle.¶

The hop reference is delivered as the ID-JAG's identity_continuation_handle claim (Section 4), a claim inside access_token and not a separate Token Exchange response parameter; the accepting RAS binds it (Section 5.2), and the CAI reaches it through RAS state or intra-domain context (Section 5.3).¶

There is no chain-expiry response parameter: chain lifetime is authoritative at the IdP (Section 6), and a deployment needing advance warning conveys it through task or authorization state, an optional ID-JAG claim, or a management API.¶

5.5.5. Onward ID-JAG Construction

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 subject identifier for the target audience, and aud_sub remains available under the base profile where the target's native subject namespace differs.¶

Because the onward ID-JAG carries cnf, the actor redeems it with the DPoP-bound JWT grant, urn:ietf:params:oauth:grant-type:jwt-dpop ([I-D.parecki-oauth-jwt-dpop-grant]), and a DPoP proof of the bound key, as the base profile specifies for a key-bound ID-JAG ([I-D.ietf-oauth-identity-assertion-authz-grant], Section 9.8.1.2.1). The target RAS needs no continuation support to redeem this grant. A RAS that does not implement this profile may issue a bearer access token under the base profile. A continuation-aware RAS follows the binding requirements of Section 5.2, even if no further continuation occurs.¶

Where the recorded root authentication context contains auth_time, acr, or amr, the IdP MUST include them in the onward ID-JAG unchanged. Continuation MUST NOT extend or strengthen the authentication context, for example by raising acr or adding amr beyond the user's root authentication.¶

The IdP constructs act as follows:¶

• It places the authenticated current actor atop the presented hop's lineage, whose origin is the authenticated client of the root exchange even if the root ID-JAG carries no act (Section 5.1.3); it never copies lineage from the assertion, and siblings do not contribute.¶

• A hop's parent reference is immutable. The IdP MUST derive lineage from that hop's ancestry to the root, excluding sibling branches. Storage and traversal methods are implementation-specific.¶

• Consecutive identical actors, those whose canonical actor identities are equal under the comparison rules of Section 5.5.2, both iss and sub, merge into one entry, though the hop record remains; policy MAY limit disclosed depth, narrowing what a target sees without changing the actor-lineage depth bound the IdP enforces (the chain-state rule of Section 5.5.3).¶

• A RAS MUST NOT read the absence of a further nested act as proof that no earlier actor exists, because policy may narrow what is disclosed: act is the disclosed actor lineage, not the authoritative history, which only the IdP's hop records hold.¶

The onward ID-JAG's client_id identifies the current actor's OAuth client at the target RAS and may differ from its client identifier at the IdP. If the IdP cannot resolve that target client identity, the request fails with invalid_target (Section 5.5.6).¶

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

5.5.6. Error Response and Recovery

On failure, the IdP returns an error response ([RFC6749], Section 5.2; [RFC8693], Section 2.2.2). On a first presentation, when more than one rule of Section 5.5.3 fails, the IdP MUST return the code for the earliest failure. Request-parameter and well-formedness failures (including signature verification) come first. No chain-state code is returned before issuer trust for the hop's RAS is established, nor before the client authentication and key proof of the current-actor rule succeed, so no chain-state code reaches a caller that has not authenticated as the current actor and proved the cnf key. Among chain-state failures a permanently unusable hop precedes a limit. The contents of an unverified assertion never determine the response, and a missing hop is invalid_request, so a caller learns nothing about which handles exist.¶

For recovery, client authentication, key proof, and fingerprint matching precede chain-state checks (Section 5.5.7.1).¶

On a first presentation or matching ISSUED recovery, the IdP MUST return invalid_continuation (Section 11) when the handle identifies an issued hop that is permanently unusable: its chain has expired or ended, the hop or an ancestor is revoked, or the tenant has withdrawn the chain's permission to continue (Section 6.2). The IdP MUST NOT return invalid_continuation in any other case.¶

For other failures, the IdP MUST use the following error codes:¶

• invalid_request: a malformed, inconsistent, or unacceptable token, including an assertion that fails the well-formedness rule of Section 5.5.3 (which covers signature verification) or the issuer-trust rule; an act that does not equal the authenticated client's canonical actor identity (Section 5.5.2); an unknown handle; a lifetime above the accepted maximum; prohibited actor_token or actor_token_type parameters; or a reserved assertion that cannot be processed as idempotent recovery (Section 5.5.7.1), other than a matching ISSUED recovery whose hop is permanently unusable, which is invalid_continuation.¶

• invalid_dpop_proof: a DPoP failure.¶

• unauthorized_client: the chain authorization or current policy does not permit this actor to continue from the hop. Other actors may still continue; withdrawal of the chain's permission is invalid_continuation.¶

• invalid_grant: continuation would exceed actor-lineage depth, fan-out, hop-count, or rate limits (Section 6.3). A rate-limited request can be retried after the policy-defined window; other limit failures require a different request.¶

• invalid_target: the requested audience or a requested resource is not permitted by the chain authorization or current policy, or the IdP cannot resolve the user's subject identifier or the actor's client identifier at the target.¶

• invalid_scope: a requested scope is not permitted by the chain authorization or current policy, or scope is omitted and no policy default exists ([RFC6749], Section 3.3).¶

• invalid_authorization_details: a requested authorization detail is not permitted by the chain authorization or current policy, or its type is one the IdP does not implement.¶

DPoP nonce processing and the use_dpop_nonce error apply unchanged from [RFC9449].¶

Recovery from invalid_continuation requires a new root exchange, authorized under current policy and resolving to an active anchor (Section 5.1). Establishing a new chain does not reactivate the old chain's handles.¶

Other errors apply to the request and do not establish that the chain is permanently unusable. An actor-lineage depth rejection concerns the particular continuation whose resulting lineage would exceed the bound, not the hop itself; a continuation that merges into an existing lineage entry, or a later policy raising the bound, may still succeed.¶

After a lost response, the client MAY retry the same assertion where the IdP offers idempotent retry (Section 5.5.7.1), or obtain a fresh assertion. Expired acceptance evidence can prevent fresh assertion issuance; shared fan-out or hop-count limits can prevent a subsequent exchange (Section 6.3). A fresh assertion may create an equivalent grant and sibling hop but no additional authority.¶

A client cannot distinguish on the wire a presentation whose request does not match its reservation's fingerprint from one whose reservation is RESERVED or FAILED: all three return invalid_request (Section 5.5.7.1). The client can retry the original request within the retry window, since pending issuance may complete, or obtain a fresh assertion. Other invalid_request failures, such as malformed requests or prohibited parameters, require correcting or abandoning the request.¶

5.5.7. Replay Reservation and Retry

The IdP MUST issue at most one grant per assertion, including under concurrent presentations: it reserves the assertion's (iss, jti) as an atomic first-writer decision once validation succeeds and before it issues the grant, and MUST retain the reservation through exp plus the permitted clock skew (one value, per the freshness rule of Section 5.5.3). Uniqueness is keyed on (iss, jti), since partitioning by tenant alone would let two assertion issuers in one tenant collide on a reused jti. The reservation MUST be visible to every IdP instance that accepts assertions for that issuer, and an instance that cannot reach that shared state MUST reject the request rather than issue. Without idempotent retry this needs only the set of (iss, jti) values presented within that window.¶

A request that fails validation creates no reservation and does not modify any existing reservation.¶

The IdP MUST reject a second presentation of a reserved assertion unless it offers idempotent retry.¶

A consumed assertion is not equivalent to a fresh one. With live acceptance evidence, the CAI refuses a fresh assertion once the hop's authorization has lapsed (Section 5.4.3); with self-contained evidence, issuance continues until the RAS token expires, and single-use still keeps each consumed assertion from authorizing more than its one grant within that tail (Section 9.1). Single-use therefore bounds staleness and multiplicity; it does not itself establish that the hop was accepted.¶

B.1.1. Provisioning

The exchanges below presuppose the following configuration. Every item is an ordinary OAuth or ID-JAG registration except the four the profile adds: the IdP's continuation policy, its trust in GatewayRAS as an assertion issuer, its advertisement of identity_continuation_supported, and GatewayRAS's advertisement of the continuation profile.¶

IdP (Section 5.5.2, Section 9.4, Section 5.1, Section 7.1):¶

• Register agent-app and tool-gateway as confidential clients in tenant-123, with canonical actor identities (https://agent.example/, agent-app) and (https://gateway.example/, tool-gateway).¶

• Authorize https://gateway.example/ to issue tool-gateway's client credential.¶

• Trust GatewayRAS's issuer, https://ras.gateway.example/, and its signing keys to attest its hops. Authorize GatewayRAS and https://gateway.example/ as a CAI and actor identity authority pair for tenant-123.¶

• Configure tenant policy to grant agents read access to productivity tools and permit tool-gateway to continue.¶

• Advertise identity_continuation_supported and hold tool-gateway's client identifier at WikiRAS, placed in the onward ID-JAG's client_id.¶

GatewayRAS (Section 7.2, Section 5.4.3):¶

• Advertise the continuation grant profile and trust the IdP as ID-JAG issuer.¶

• Register tool-gateway as an OAuth client associated with the resource it operates, https://gateway.example/. The CAI uses this association when checking whether it can issue an assertion for a token presented to that resource.¶

ToolGateway (Section 5.5.2): provision a DPoP key pair and a client-authentication credential issued by https://gateway.example/.¶

WikiRAS (base profile): register tool-gateway as a client, trust the IdP as ID-JAG issuer, and support the DPoP-bound JWT grant.¶

ToolGateway authenticates to the IdP with the following [RFC7523] client assertion issued by the gateway domain (Appendix B.1.5). Its earlier exchange at GatewayRAS uses a separate client assertion addressed to GatewayRAS (Appendix B.1.4).¶

{
  "iss": "https://gateway.example/",
  "sub": "tool-gateway",
  "aud": "https://idp.example/",
  "iat": 1710000230,
  "exp": 1710000290,
  "jti": "tg-cred-01"
}

In this example, iss and sub match ToolGateway's configured canonical actor identity, used in the assertion's act and onward lineage (Section 5.5.2, Section 3.2).¶

B.1.2. Root Exchange

AgentApp exchanges Alice's ID Token, whose sid anchors the chain to her IdP session (Section 5.1), for an ID-JAG addressed to GatewayRAS, the one audience it knows:¶

POST /token HTTP/1.1
Host: idp.example
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:token-exchange
&requested_token_type=urn:ietf:params:oauth:token-type:id-jag
&audience=https://ras.gateway.example/
&resource=https://gateway.example/
&scope=tools.invoke
&subject_token=<id_token>
&subject_token_type=urn:ietf:params:oauth:token-type:id_token
&client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer
&client_assertion=<agent-app JWT>

In this deployment, the chain authorization permits tool-gateway to continue on Alice's behalf with read access to productivity services. The IdP establishes a chain and embeds H0 (Section 5.1).¶

The authorization uses the tenant's current classification of productivity services. A wiki added to that class can therefore be reached without a new chain, while removing it prevents further continuation to it. That is deployment policy, not a requirement of this profile (Section 5.1.4, Section 9.2).¶

On the wire (decoded ID-JAG for GatewayRAS):¶

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

  "client_id": "agent-app",
  "resource": "https://gateway.example/",
  "scope": "tools.invoke",

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

  "identity_continuation_handle": "Qm7zXu2VtL9pKe4RaW1nHc",

  "iat": 1710000205,
  "exp": 1710000505,
  "jti": "idjag-gateway-01"
}

B.1.3. GatewayRAS Binds H0 and Issues the Access Token

AgentApp redeems the ID-JAG at GatewayRAS with the jwt-bearer grant, exactly as for any ID-JAG, and nothing in this profile asks it to sender-constrain the exchange; GatewayRAS issues a bearer access token here, its own policy choice (Section 5.2):¶

POST /token HTTP/1.1
Host: ras.gateway.example
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
&assertion=<the ID-JAG above>
&client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer
&client_assertion=<agent-app JWT>

GatewayRAS advertises the continuation grant profile (Section 7.2) and so recognizes the handle. It binds H0, the issuing IdP, and the tenant it associates with that IdP to the authorization state behind the access token, in the same outcome that issues the token (Section 5.2); the ID-JAG carried no cnf, so there is no key to record.¶

Server-side state at GatewayRAS:¶

{
  "identity_continuation_handle": "Qm7zXu2VtL9pKe4RaW1nHc",
  "status": "ACCEPTED",
  "continuation_eligible": true,
  "authorization_state": "gw-authz-7a1e",
  "idp": "https://idp.example/",
  "tenant": "tenant-123",
  "client_id": "agent-app",
  "bound_at": 1710000210
}

GatewayRAS issues the access token as a signed JWT that carries H0 as a claim, the access-token carrier of Section 8.1.¶

On the wire (decoded access token):¶

{
  "iss": "https://ras.gateway.example/",
  "aud": "https://gateway.example/",
  "sub": "gateway-pairwise-subject",
  "client_id": "agent-app",
  "scope": "tools.invoke",
  "identity_continuation_handle": "Qm7zXu2VtL9pKe4RaW1nHc",
  "iat": 1710000210,
  "exp": 1710000810,
  "jti": "at-gw-0001"
}

AgentApp calls the gateway with this token. It chooses which token to present, and with it which authorization, but cannot alter the handle inside the token. A RAS that sender-constrains its tokens closes the bearer-ingress exposure of Section 9.1; Appendix B.2 shows that variant.¶

B.1.4. ToolGateway Obtains the Assertion

ToolGateway validates the access token as any resource server would. Resolving the tool call, it selects the wiki as the upstream. To continue Alice's chain there it needs an Identity Continuation Assertion, which it obtains by exchanging the access token it just received at GatewayRAS's token endpoint, authenticating as the OAuth client tool-gateway and proving its own key (Section 5.4.1):¶

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

grant_type=urn:ietf:params:oauth:grant-type:token-exchange
&requested_token_type=urn:ietf:params:oauth:token-type:identity-continuation
&subject_token=<the access token above>
&subject_token_type=urn:ietf:params:oauth:token-type:access_token
&client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer
&client_assertion=<tool-gateway JWT>

The DPoP proof on this request proves the tool-gateway key, which GatewayRAS places in the assertion's cnf; had the access token been sender-constrained, its own cnf would not be matched against this proof (Section 9.1).¶

GatewayRAS confirms the token is its own, unexpired, and addressed to https://gateway.example/, the resource tool-gateway is registered to operate. It reads H0 from the token, rechecks that the authorization remains active and that its binding still records it as eligible for continuation, then issues the assertion bound to the proven key (Section 5.4.3).¶

On the wire (issuance response):¶

{
  "issued_token_type": "urn:ietf:params:oauth:token-type:identity-continuation",
  "access_token": "<the assertion below, compact JWS>",
  "token_type": "N_A",
  "identity_continuation_authorization_server": "https://idp.example/",
  "expires_in": 120
}

The identity_continuation_authorization_server identifies the IdP from which ToolGateway obtains the next ID-JAG.¶

On the wire (decoded assertion):¶

{
  "iss": "https://ras.gateway.example/",
  "aud": "https://idp.example/",
  "identity_continuation_handle": "Qm7zXu2VtL9pKe4RaW1nHc",

  "act": {
    "iss": "https://gateway.example/",
    "sub": "tool-gateway"
  },

  "cnf": {
    "jkt": "base64url-tool-gateway-key-thumbprint"
  },

  "iat": 1710000230,
  "exp": 1710000350,
  "jti": "n3Vt7Jq2Xd5PbR9wLc1eKs"
}

B.1.5. ToolGateway Continues to WikiRAS

ToolGateway resolves the token endpoint of https://idp.example/, the identity_continuation_authorization_server it was given, using Section 5.4.4, and presents the assertion there as the subject_token of a continuation exchange, with client authentication and a DPoP proof of the assertion's cnf key, requesting an ID-JAG for WikiRAS. The IdP maps the registered client tool-gateway to its canonical actor identity (Section 5.5.2):¶

POST /token HTTP/1.1
Host: idp.example
Content-Type: application/x-www-form-urlencoded
DPoP: <proof signed by the tool-gateway 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.wiki.example/
&resource=https://api.wiki.example/
&scope=wiki.read
&subject_token=<identity-continuation-assertion>
&subject_token_type=urn:ietf:params:oauth:token-type:identity-continuation
&client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer
&client_assertion=<tool-gateway client assertion>

The IdP validates the exchange (Section 5.5.3):¶

• Issuer trust: the assertion is signed by GatewayRAS, the RAS recorded for H0's hop, which that rule accepts directly.¶

• Chain state: H0 names an accepted hop on an active chain.¶

• Current actor and binding: the act claim names tool-gateway, the authenticated client, and the DPoP proof matches cnf.¶

• Authorization: the chain authorization permits tool-gateway to obtain wiki.read for Alice, and current policy classifies the wiki as an eligible productivity service. The root tools.invoke scope does not independently authorize this access.¶

The IdP resolves Alice's wiki subject and issues the ID-JAG with H1 and tool-gateway atop agent-app in the lineage.¶

On the wire (decoded ID-JAG for WikiRAS):¶

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

  "client_id": "tool-gateway",
  "resource": "https://api.wiki.example/",
  "scope": "wiki.read",

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

  "identity_continuation_handle": "Zp3kRt8VbN2wLq6YsD4mXe",

  "act": {
    "iss": "https://gateway.example/",
    "sub": "tool-gateway",
    "act": {
      "iss": "https://agent.example/",
      "sub": "agent-app"
    }
  },

  "cnf": {
    "jkt": "base64url-tool-gateway-key-thumbprint"
  },

  "iat": 1710000235,
  "exp": 1710000535,
  "jti": "idjag-wiki-01"
}

A target not permitted by the chain authorization and current policy fails with invalid_target; the chain stays continuable and only that tool call fails (Section 5.5.6). Appendix B.3.4 illustrates a grant that excludes a newly requested target.¶

B.1.6. WikiRAS Redeems an Ordinary ID-JAG

ToolGateway redeems the ID-JAG at WikiRAS with the DPoP-bound JWT grant and a DPoP proof of the same key (Section 5.5.5). WikiRAS follows the base profile: it validates the ID-JAG, ignores the handle, and issues an access token without binding H1 (Section 5.2). ToolGateway calls WikiAPI as Alice's wiki subject and returns the result to AgentApp.¶

Further calls to WikiAPI for Alice reuse this access token while it remains valid and covers the requested access (Section 8). Access to another upstream repeats Appendix B.1.4 and creates a sibling hop under H0 (H2, and so on).¶

B.1.7. What a Gateway Implements

The gateway domain adds two things to an ordinary OAuth deployment:¶

• GatewayRAS binds the handle when it redeems a continuation-capable ID-JAG, records whether the authorization is eligible for continuation, advertises the continuation grant profile alongside the base grants, places the handle in the access token, and issues assertions from its token endpoint (Section 5.2, Section 5.4, Section 7.2).¶

• tool-gateway exchanges the access token it received for an assertion, then presents that assertion once (Section 5.5.7), with its client credential and a DPoP proof, to the IdP for the next ID-JAG.¶

Both presuppose registrations that ID-JAG already requires: tool-gateway is an OAuth client of the IdP, holding a client-authentication credential and the key its DPoP proofs use, and a client known to WikiRAS, which the onward ID-JAG names as client_id (Section 5.5).¶

AgentApp and WikiRAS use the base profile unchanged. AgentApp proves no key anywhere and never shares Alice's identity assertion with the gateway. The IdP establishes the chain and evaluates each continuation (Section 5.1, Section 5.5).¶

B.2.1. Root Exchange (H0 at ExpenseRAS)

ExpenseApp exchanges the user's ID Token, whose sid anchors the chain to the IdP session, for an ID-JAG addressed to ExpenseRAS:¶

POST /token HTTP/1.1
Host: idp.example
Content-Type: application/x-www-form-urlencoded

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
&client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer
&client_assertion=<expense-app JWT>

In this deployment, the chain authorization permits designated workloads to continue to Expense, Travel, and Booking. Current enterprise policy also permits that access (Section 5.1.4).¶

Server-side state (IdP authorization, illustrative):¶

(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

The IdP creates the root hop H0 and embeds it in the ID-JAG (Section 4).¶

On the wire (decoded ID-JAG):¶

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

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

B.2.2. ExpenseRAS Binds H0; Expense TTS Carries It

ExpenseApp redeems the ID-JAG at ExpenseRAS for an access token, AT1, and ExpenseRAS binds H0, the issuing IdP, and the tenant it associates with that IdP to the authorization state behind AT1, and records that authorization as eligible for continuation (Section 5.2). The carrier is what differs: the handle stays in this record, and AT1 does not carry it.¶

Server-side state at ExpenseRAS:¶

{
  "identity_continuation_handle": "kW4uJ8pTe2NxA6rQvD1zYs",
  "status": "ACCEPTED",
  "continuation_eligible": true,
  "authorization_state": "at1-authz-2f9c",
  "idp": "https://idp.example/",
  "tenant": "tenant-123",
  "client_id": "expense-app",
  "bound_at": 1710000010
}

ExpenseApp calls ExpenseAPI with AT1. The Expense TTS resolves AT1 against that record over its own-domain interface with ExpenseRAS, derives H0, and issues a Transaction Token for expense-service, the workload that completes the request (Section 5.3). The token's req_wl names expense-api, which requested the Transaction Token; expense-service is the workload assigned to continue the transaction. The TTS records the assignment to that workload in authenticated routing state, the domain's own record of which workload handles a transaction. Neither ExpenseApp nor expense-service supplies H0.¶

Intra-domain context (decoded Transaction Token):¶

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

The Transaction Token stays inside expenses.example. The tctx.identity_continuation encoding is illustrative; the profile standardizes no carrier schema.¶

B.2.3. ExpenseService Obtains the Assertion

expense-service presents the Transaction Token as the subject_token at Expense CAI's token endpoint, authenticating as a client and proving its own key (Section 5.4.1):¶

POST /token HTTP/1.1
Host: cai.expenses.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:identity-continuation
&subject_token=<the Transaction Token above>
&subject_token_type=urn:ietf:params:oauth:token-type:txn_token
&client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer
&client_assertion=<expense-service JWT>

Expense CAI verifies the Transaction Token and reads H0. It checks the routing state that assigns this transaction to expense-service; the domain audience and req_wl alone do not establish that assignment. It rechecks with ExpenseRAS that H0's authorization remains active and is eligible for continuation, then issues the assertion bound to the proven key (Section 5.4.3).¶

The IdP accepts its assertions for hops ExpenseRAS accepts because it trusts Expense CAI for that RAS from tenant configuration at the IdP; the rest of the conjunctive trust rule applies as it does to a co-located RAS (Section 7.3, Section 9.4).¶

On the wire (decoded assertion):¶

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

B.2.4. Continuation to TravelRAS (H1)

expense-service presents the assertion to the IdP with an [RFC7523] client assertion and a DPoP proof of the continuation assertion's cnf key, requesting an ID-JAG for TravelRAS. The IdP maps the authenticated client to its canonical actor identity (Section 5.5.2):¶

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
&client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer
&client_assertion=<expense-service client assertion>

The IdP validates the exchange (Section 5.5.3):¶

• Issuer trust: Expense CAI is trusted for ExpenseRAS, the RAS recorded for H0, rather than being that RAS itself.¶

• Chain state: H0 names an accepted hop on an active chain.¶

• Current actor and binding: act names expense-service, the authenticated client, and the DPoP proof matches cnf.¶

• Authorization: TravelRAS, TravelAPI, and trips.read are permitted by the chain authorization and current policy.¶

The IdP never calls ExpenseRAS; the assertion is its evidence of acceptance (Section 5.2.1). It resolves the user's Travel subject, creates H1 as a child of H0, and places expense-service atop the root actor expense-app in the lineage (Section 5.5.5).¶

On the wire (decoded ID-JAG):¶

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

B.2.5. The Pattern Repeats to BookingRAS (H2)

expense-service redeems the ID-JAG at TravelRAS for AT2, and TravelRAS binds H1 exactly as ExpenseRAS bound H0. The Travel TTS derives H1 into a Transaction Token for travel-service. Within the illustrated tctx.identity_continuation object, only the handle changes:¶

Intra-domain context (excerpt):¶

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

travel-service obtains an assertion for H1 from Travel CAI and exchanges it for an ID-JAG with audience=https://ras.booking.example/, resource=https://api.booking.example/, and scope=stays.book, all permitted by the chain authorization and current policy. It authenticates with its own client assertion and proves the key in the continuation assertion's cnf. The IdP resolves its canonical actor identity (Section 5.5.2), creates H2 under H1, and extends the lineage:¶

On the wire (selected claims from the decoded ID-JAG):¶

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

BookingRAS is terminal: it redeems the ID-JAG under the base profile, ignores H2, issues AT3, and binds nothing (Section 5.2). travel-service calls BookingAPI with AT3.¶

B.2.6. What Differs from the Gateway Example

• The CAI is a separate service in each continuing domain, which the IdP trusts for that domain's RAS from tenant configuration (Section 7.3); a co-located RAS needs no such record, though the same conjunctive trust applies to both (Section 9.4).¶

• The handle never enters an access token; a Transaction Token Service derives it from the RAS binding for each request, and the workload presents that token to obtain the assertion.¶

• Two continuing domains produce a three-entry lineage: two continuation actors and the root actor.¶

• ExpenseRAS chooses to sender-constrain the root access token, so ExpenseApp presents DPoP proofs at the RAS and on its API call; that is RAS policy under the base profile. The gateway example uses a bearer root access token.¶

B.3.1. Setup: Anchoring the Chain to a Grant

Alice authorizes "summarize my calendar every morning." Because the task must outlive her session, briefing-agent presents a refresh token from a grant that permits continuation as the root exchange's subject token, so the chain is anchored to that grant rather than to her session (Section 5.1, Section 6). In this deployment, the grant permits only the Platform and Calendar access needed for the task, and current policy permits that access. The root ID-JAG targets PlatformRAS.¶

Server-side state (IdP grant authorization, illustrative):¶

(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

The exchange and RAS binding follow the pattern of Appendix B.2.1 and Appendix B.2.2. PlatformRAS binds H0 to a durable task authorization that it keys by its own task identifier; the record holds no bearer credential.¶

Server-side state (PlatformRAS task authorization):¶

task_id:                      task-123
owner:                        alice
actor:                        briefing-agent
identity_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
continuation_eligible:        true

Server-side state (Scheduler):¶

task_id: task-123

The Scheduler never receives H0 or any user, chain, or bearer credential; task-123 identifies a row in PlatformRAS's own state and means nothing outside the platform.¶

B.3.2. Each Run: Deriving H0 from Task State

Each run begins with no user present, so H0 comes from state the platform holds:¶

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

The task identifier is not a secret and does not authorize a run. The Scheduler's trigger authenticates and carries only task-123; BriefingAgent authenticates to the Platform TTS and proves possession of its key; and the TTS, after confirming that task-123 is active and that BriefingAgent is its designated actor, derives H0 into a fresh Transaction Token (Section 5.3). Neither the Scheduler nor BriefingAgent selects H0.¶

B.3.3. Each Run: Continuing to CalendarRAS

Each run performs assertion issuance, continuation exchange, and ID-JAG redemption:¶

 BriefingAgent    Platform CAI       IdP         CalendarRAS
       |               |             |               |
       |--exchange TT->|             |               |
       |<-assertion----|             |               |
       |---------------------------->|               |
       |      assertion + DPoP       |               |
       |<----------------------------| ID-JAG(child) |
       |-------------------------------------------->|
       |                 ID-JAG                      |
       |<--------------------------------------------| access token
       |               |             |      no binding (terminal)

BriefingAgent exchanges the Transaction Token at Platform CAI's token endpoint and presents the assertion to the IdP the response's identity_continuation_authorization_server names, with its client credential and a DPoP proof. Platform CAI applies Section 5.4.3 to durable task state rather than to a live user's request: it authenticates briefing-agent, verifies its key and transaction, and rechecks that PlatformRAS's H0 authorization remains active.¶

The assertion and onward ID-JAG use the formats shown in Appendix B.2.3 and Appendix B.2.4, with Platform CAI as the assertion issuer. briefing-agent is both the root actor and the current actor here, so the onward act merges them into one entry (Section 5.5.5). CalendarRAS is terminal and issues the access token without binding the child hop. Each run's child is a sibling, not a descendant, of the previous run's child.¶

B.3.4. A Newly Requested Target

Suppose the platform later extends the briefing to include unread mail, which requires https://api.mail.example/ behind https://ras.mail.example/. Alice's grant authorizes only Platform and Calendar access, so the IdP rejects a continuation from H0 to MailRAS. A general tenant policy allowing mail access does not by itself expand that grant (Section 5.5.3).¶

HTTP/1.1 400 Bad Request
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache

{
  "error": "invalid_target"
}

A different chain authorization could permit read access to productivity services selected by current policy, as in Appendix B.1.2. Under that authorization, adding Mail to the eligible services could permit mail.read without a new chain. A request for mail.send still fails with invalid_scope if that authorization or current policy excludes it. These outcomes follow the deployment's authorization semantics, not how the IdP stores the authorization. A target-specific failure leaves the chain continuable for other authorized targets.¶

B.3.5. What Differs from the SaaS Chain Example

• The root subject token is a refresh token, so the chain anchors to a grant and survives logout; grant-anchor support is optional (Section 6.1).¶

• H0 is bound to a durable task authorization that PlatformRAS keys by task identifier; the Scheduler holds only that identifier, which is not a secret and authorizes nothing.¶

• Every run derives H0 afresh from active task state and obtains a new assertion. Stealing the task record exposes H0 but not the agent key, and continuation still requires a fresh assertion while the authorization is active.¶

• Each run creates a sibling child of H0 rather than a descendant of the previous run's child.¶

This example uses a user-present setup event. More generally, chain establishment requires an authorized root exchange whose subject token resolves to an active user session or supported grant anchor (Section 5.1, Section 6.1). Administrative policy alone, without such an anchor, cannot establish a chain.¶