Identity Continuation Profile for Agent Principal Federation

1.1. Protocol Overview

An agent calls a tool gateway, and the gateway calls a tool in another resource domain for the same agent. Inbound, the gateway is the API for the agent's access token; outbound, it is the continuing client at the Continuation Assertion Issuer (CAI), the IdP, and the tool's RAS. Here the gateway's RAS also performs the CAI role.¶

Agent        IdP       GatewayRAS/CAI     Gateway        ToolRAS
  |           |               |              |               |
  | (1) governed grant with handle H0        |               |
  |---------->|               |              |               |
  |<----------|               |              |               |
  | (2) redeem; RAS binds H0  |              |               |
  |-------------------------->|              |               |
  |<--------------------------|              |               |
  | (3) call with access token               |               |
  |----------------------------------------->|               |
  |           |               | (4) assertion for H0         |
  |           |               |<-------------|               |
  |           |               |------------->|               |
  |           | (5) onward grant: same agent, gateway as client
  |           |<-----------------------------|               |
  |           |----------------------------->|               |
  |           |               |              | (6) redeem    |
  |           |               |              |-------------->|
  |           |               |              |<--------------|

1. The agent's client obtains a governed grant for the gateway's RAS, which roots a chain where policy permits (Section 3).¶

2. The client redeems it, and the RAS binds the handle (Section 4).¶

3. The agent calls the gateway, which applies the API processing of [FEDERATION].¶

4. The gateway exchanges the access token at the CAI for an assertion (Section 5).¶

5. The gateway presents the assertion to the IdP, which checks the chain, the gateway's Continuation Association, and the agent's authorization for the tool, and issues an onward grant naming the same agent, with the gateway as client (Section 6).¶

6. The tool's RAS processes the onward grant as any governed grant (Section 7).¶

Three lifetimes are independent, as in Section 6 of [ICA]: a grant's short redemption window, the access token each RAS issues under its own policy, and the chain that the IdP holds. Ending a chain stops new continuations only. Grants and access tokens already issued, and any refresh token a target issues, keep their own lifetimes (Section 9). Appendix A shows the messages.¶

1.2. Scope

This document applies under these conditions:¶

• One IdP: Every RAS in a chain trusts the IdP that issued the root grant. Continuity across a chain of IdPs is out of scope.¶

• One agent: Continuation never changes the Agent Principal. A continuing client is governed as a client, through its Continuation Associations, its attribution as client_id, and its registrations. One that exercises its own authority and needs authorization, attribution, or disablement as a principal is an Agent Principal of its own ("Governance Boundary and Execution Independence" in [FEDERATION]), and its acting for another agent is multi-agent delegation, which [FEDERATION] excludes.¶

• An accepted grant: The gateway's access token comes from a RAS that redeemed a governed grant. Where the IdP itself issues the gateway's access tokens, there is no hop to continue.¶

Whether a call still serves approved work is outside this document, as in [FEDERATION]. This document defines one claim, continuation_via (Section 6.5.2), and no new token format, error code, or request parameter.¶

3.1. Governed Chain Authorization

For a governed chain, the IdP records these facts in the chain authorization (Section 5.1.4 of [ICA]), in addition to those ICA requires, and treats them as follows at each continuation:¶

The Continuation Association, the Target Tenant, the user's subject at the target, and the continuing client's registration there are evaluated for each onward grant. Current policy can narrow the chain authorization but cannot exceed it (Section 5.1.4 of [ICA]). The limits of Section 6.3 of [ICA], including the actor-lineage depth bound, apply to the IdP's hop records, whose lineage entries are the root client and the continuing clients.¶

The IdP MUST also enforce a finite continuation window, whose length is configured: it refuses a continuation request received after the hop's deadline, with invalid_grant as for those limits. A hop's deadline is the time the IdP issued the hop plus the window configured then. Shortening the window can bring existing deadlines forward; lengthening it applies only to hops issued afterwards. The deadline limits when a continuation can be requested, not when its onward grant issues, so an onward grant whose issuance is deferred after a timely request can issue after it. The window bounds how long a CAI, including one that a compromised gateway operator controls, can obtain continuations from a hop it accepted. It does not bound the chain: each continuation creates a hop with a deadline of its own, and the hop-count limit of Section 6.3 of [ICA] bounds how far a chain extends (Section 12.1, Section 11.1).¶

3.2. Delegated Root

The root ID-JAG follows "Delegated Issuance: ID-JAG" in [FEDERATION], and its anchors are those of Section 6.1 of [ICA]. For an ID Token subject, the anchor is the user's IdP session that the ID Token's sid identifies; sid is optional, so an IdP that establishes session-anchored chains includes it in the ID Tokens it issues to agents' clients. The root exchange can use either resolution mode of [FEDERATION], including presented-evidence mode, in which the request carries the agent's workload credential as actor_token; [FEDERATION] processes it ("Agent Resolution Input Validation"), and Section 5.1.1 of [ICA] leaves that processing out of scope.¶

3.3. Self-Acting Root and Agent Session

This section extends [ICA] to chains with no user. The root WAG follows "Self-Acting Issuance: WAG" in [FEDERATION] and carries the root handle, which the IdP generates under rules 1 and 2 of Section 4 of [ICA]. A self-acting chain has no authentication context, so its onward WAGs carry no auth_time, acr, or amr.¶

The lifecycle anchor of a self-acting chain is an agent session, which replaces the user-rooted anchors of Section 6.1 of [ICA]; the prohibition there on rooting a chain from an access token still applies. An agent session is evidence that the Agent Principal recently authenticated through one Identity Binding. It does not show that any particular work continues, and the Agent Authorization, not the session, governs what the chain may do.¶

• Creation: When a self-acting issuance establishes a chain, the IdP anchors it to the active agent session for the resolved Agent Principal and the Identity Binding it resolved through, creating one if none is active. An ended session is never revived.¶

• Refresh: Completing steps 1 to 3 of "Self-Acting Issuance: WAG" in [FEDERATION] through that binding refreshes the session: client authentication, agent resolution through the binding, and the self-acting Client Association check, whether or not issuance is then authorized. The IdP MUST NOT refresh it on any other request, including a continuation exchange or delegated issuance.¶

• Idle timeout: The IdP MUST end an agent session that has not been refreshed within its configured idle timeout.¶

• Absolute expiration: The IdP MUST set a finite absolute expiration when it creates an agent session, no later than a configured maximum, and MUST NOT extend it.¶

• Governance events: An event of Section 9 that applies to the session's Agent Principal or Identity Binding also ends the session.¶

A self-acting chain ends with its agent session (Section 6.2 of [ICA]), which neither the gateway nor the CAI can keep active (Section 11.1). IdP instances evaluate the idle timeout and the absolute expiration against shared session state; an instance that cannot confirm it refuses temporarily (Section 6.6).¶

6.1. Request

The continuing client sends the continuation request of Section 5.5.1 of [ICA], with client authentication under Section 5.5.2 of [ICA] and a DPoP proof of the assertion's cnf key. The common parameters and rules of "Token Exchange Request" in [FEDERATION] apply to it, so these parameters are REQUIRED:¶

The continuing client selects requested_token_type by the acting relationship it determined for the received access token as the API ("Profile Applicability" under "Access at the Resource Server" in [FEDERATION]). authorization_details is processed as in [FEDERATION].¶

6.2. Continuation Association

A Continuation Association permits an authenticated client to continue an Agent Principal's governed chains in one acting relationship. It belongs to the Governance Tenant of those chains and does not apply to chains in another. It can restrict targets and authority (Section 6.3), and it narrows, without replacing, the restrictions on who may continue that the chain authorization records (Section 5.1.4 of [ICA]). It has these limits:¶

• A Client Association does not imply a Continuation Association, nor the reverse.¶

• Permission to continue delegated chains does not imply permission to continue self-acting chains, nor the reverse.¶

• A Continuation Association is not an Identity Binding. A continuation exchange performs no agent resolution: the onward grant's agent comes only from the chain record, even when the continuing client is also bound to an agent of its own.¶

Policy representation and administration are outside this document.¶

6.3. Restrictions

A chain authorization's restrictions (Section 5.1.4 of [ICA]) and a Continuation Association's restrictions have the meaning this section defines; their representation is outside this document. Either can contain these members:¶

The IdP MUST evaluate each restriction as follows:¶

• Absent: An absent member restricts nothing, and the other bounds of this section still apply. Where a chain authorization records no Targets member, a target that current policy comes to permit is reachable from every such chain, as Section 9.2 of [ICA] describes. Likewise, a target that matches no authority entry has no authority limited by that restriction. Absence never removes the finite hop-count limit of Section 6.3 of [ICA] or the continuation window (Section 3.1).¶

• Present: A member present in a chain authorization is fixed for the chain's lifetime (Section 5.1.4 of [ICA]). Current policy can narrow access beneath it but cannot exceed it. A Continuation Association's members are current policy and apply as they stand at each continuation.¶

• Empty: A present member that is empty permits nothing: an empty Targets member permits no continuation, an empty Continuing clients member permits no client, and an authority entry whose scope set or authorization details are present but empty permits no access to its target.¶

• Matching: A request matches a target entry when its audience equals the entry's RAS issuer and, for an entry naming a resource, its resource equals that resource or, for an entry naming a Target Tenant, the Target Tenant resolved for it in step 7 of Section 6.4 equals that tenant. A continuing client matches when its canonical actor identity equals a recorded one. This document compares each value as an exact string, without normalization.¶

• Authority: A request is within a restriction's authority only if it is within every authority entry whose target entry it matches: each requested scope value is in the entry's scope set, if the entry has one; and, if the entry has authorization details, the request carries a non-empty authorization_details array, each of whose details is within a recorded detail of the same type under that type's rules. A request without authorization details, or with an empty array, is not within such an entry, even when its scope is, since its grant would carry the scope without the limit the details express.¶

• Unevaluable: If the IdP cannot determine that requested authorization details are within an authority entry, for example because it does not implement their type's comparison, the request is not within it.¶

• Combined: The chain authorization's restrictions, the Continuation Association's restrictions, and the agent's current authorization each bound the onward grant independently. The target RAS then applies its own policy.¶

The IdP derives a chain authorization's restrictions when it establishes the chain, from tenant policy and from the Delegation or Agent Authorization under which the root grant is issued.¶

6.4. Validation

For a first presentation of an assertion for a hop of a governed chain, the IdP MUST perform the following steps in order and MUST reject the request at the first step that fails, with the error of Section 6.6. The checks of Section 5.5.3 of [ICA] apply within the steps that cite them, changed only as stated.¶

1. Client and proof: Authenticate the client, map it to its canonical actor identity (Section 5.5.2 of [ICA]), and validate the DPoP proof.¶

2. Request parameters (ICA rule 1): The parameters of Section 6.1 replace that rule's requested token type, resource, and scope requirements.¶

3. Assertion (ICA rules 2 and 3): The assertion is well formed and validly signed by an issuer trusted as CAI for the hop's RAS.¶

4. Current actor (ICA rule 5): The assertion's act names the authenticated client's canonical actor identity, and the DPoP proof matches its cnf. As Section 5.5.6 of [ICA] requires, these checks precede every chain-state error.¶

5. Chain state (ICA rule 4): The hop is an accepted hop of an active chain, and neither it nor an ancestor is revoked. The chain has not ended under Section 9, requested_token_type is the chain's grant type, and the chain and hop are within ICA's limits and the continuation window (Section 3.1). An ended chain takes precedence over a wrong type, which takes precedence over a limit.¶

6. Continuer: A current Continuation Association in the chain's Governance Tenant permits the client for the chain's Agent Principal and acting relationship, and so do the chain authorization's restrictions on who may continue (Section 6.3).¶

7. Target context (ICA rule 5, replacing its subject resolution): The Target Tenant for the requested resource, the continuing client's registration at the target RAS ("Issuance Prerequisites" in [FEDERATION]), and, for a delegated chain, the user's subject at the target ("Subject Resolution" in [FEDERATION]) each resolve unambiguously. A self-acting chain's subject is its Agent Principal, which is not resolved per target. Where policy requires path disclosure, the target RAS supports it (Section 6.5.2).¶

8. Freshness and replay (ICA rule 6).¶

9. Authorization (ICA rule 7): The IdP authorizes the onward grant under "Issuance Authorization" in [FEDERATION] for the chain's Agent Principal and, for a delegated chain, its user, in the root client's context, for the requested target and authority. A current Delegation Authorization or Agent Authorization that permits continuation covers them; it need not name the continuing client. The restrictions of the chain authorization and the Continuation Association also bound the target and authority (Section 6.3). Withdrawal of the root authorization as a whole is chain state (step 5), not a failure of this step.¶

Because step 6 precedes step 7, a client without a Continuation Association learns nothing about where the chain's user resolves. The rules of [FEDERATION] for agent resolution and subject tokens do not apply to the assertion. The IdP reserves the assertion's (iss, jti) only after every step succeeds, as Section 5.5.7 of [ICA] requires, so a rejected request consumes nothing.¶

An IdP that offers idempotent retry (Section 5.5.7.1 of [ICA]) MUST include requested_token_type in the request fingerprint.¶

A presentation that matches an issued reservation is recovery, not a first presentation. Recovery follows Section 5.5.7.1 of [ICA]: after client authentication, the key proof, and the fingerprint, the IdP returns the grant it issued if that grant is unexpired, neither the hop nor an ancestor is revoked, and the chain has not ended, including under Section 9. No other step of this section applies, so recovery consumes no limit, and a client whose response was lost recovers even the last continuation that a hop-count limit permits.¶

6.5. Onward Grants

The response follows Section 5.5.4 of [ICA], with issued_token_type equal to the requested grant type and no refresh token. Every onward grant carries the common claims of "Common Grant Claims, Lifetime, and Response" in [FEDERATION], a fresh child handle under Section 4 of [ICA], and cnf.jkt for the key proven in the request (Section 5.5.2 of [ICA]). The configured grant lifetime limit of "Common Grant Claims, Lifetime, and Response" in [FEDERATION] applies. The lifetime bounds that [FEDERATION] derives from a subject credential and an agent-resolution input do not apply to continuation, and the assertion's expiration does not cap the onward grant. An onward WAG MUST NOT outlive the absolute expiration of its chain's agent session.¶

6.6. Errors

Failures of the [ICA] checks within each step use the codes of Section 5.5.6 of [ICA], and client authentication failures use the authentication method's error. The governed checks use these codes, for both chain types:¶

The client is not the actor, and the subject token is the assertion, so failures that [FEDERATION] reports at issuance as actor_unauthorized or invalid_grant concern only the requested target here. A continuing client recovers as follows:¶

• invalid_continuation means that the chain has ended. Only a new root grant, which the agent's client obtains, starts a new chain (Section 8).¶

• A limit failure (invalid_grant) means that a limit of Section 6.3 of [ICA] or the continuation window (Section 3.1) refused this continuation. The limit can belong to the source hop (its fan-out or its continuation window), to the chain or a chain authorization's shared budget (hop count or rate), or to the branch as this client would extend it (actor-lineage depth), and the error does not say which. A rate-limited continuation can succeed after the limit's window; after any other limit, the same continuation fails again while policy is unchanged, and recovery requires a different request (Section 5.5.6 of [ICA]). The error establishes neither that the chain has ended nor that the incoming access token is invalid. Without information identifying the limit, a continuing client treats the failure as affecting only the request (Section 8).¶

• Any other code affects only the request.¶

When the IdP cannot confirm shared state that a continuation depends on, such as an agent session (Section 3.3) or a replay reservation (Section 5.5.7 of [ICA]), it MUST respond with HTTP status code 503 (Service Unavailable) (Section 15.6.4 of [RFC9110]), SHOULD include a Retry-After header field (Section 10.2.3 of [RFC9110]), and MUST NOT treat an agent session as ended on that basis. This temporary refusal is not an OAuth error response: the chain has not ended, and the request was not judged invalid. Because the IdP reserves an assertion only after every step succeeds, the continuing client MAY retry the same request with the same assertion while it is unexpired, after any Retry-After interval, with a fresh client assertion and DPoP proof as the retry rule of "Dedicated Client Identity" in [FEDERATION] requires; otherwise it obtains a fresh assertion. It MUST NOT treat a temporary refusal as the end of the chain.¶

10.1. Conformance Claims

The roles are the IdP, the continuation-aware RAS and its CAI, the continuing client, and the target RAS. An implementation claims delegated continuation, self-acting continuation, or both, for each role it implements. Each claim requires the same realization under [FEDERATION] and the applicable requirements of [ICA] as this document changes them. A target RAS that does not continue the chain implements [FEDERATION] with DPoP support at its token endpoint, and nothing from this document unless it supports path disclosure (Section 6.5.2).¶

An IdP claiming delegated continuation can additionally claim grant-anchored continuation. This claim requires support for refresh-token subjects under "Subject Token Validation" in [FEDERATION] and grant anchors under Section 6.1 of [ICA]. Such chains can continue after the user's session ends, as unattended work needs (Appendix A.7). A delegated continuation claim alone does not guarantee grant-anchor support.¶

Each claim has this mandatory interoperability path:¶

• Client authentication: The continuing client, CAI, IdP, and target RAS MUST implement [RFC7523] private_key_jwt client authentication, under "Dedicated Client Identity" in [FEDERATION] for its audience, replay, and retry rules.¶

• Proof: They MUST implement DPoP [RFC9449] with the algorithms of "Client Authentication and Algorithms" in [FEDERATION].¶

• Assertion issuance: Every CAI that serves a continuing client MUST support assertion issuance at its token endpoint with an access-token subject_token (Section 5.4.1 of [ICA]), resolving the token as Section 5.4.6 of [ICA] describes when the CAI is not the accepting RAS. The continuing client MUST implement that request.¶

10.2. Metadata

A continuation-aware RAS that binds handles of governed grants MUST list urn:ietf:params:oauth:grant-profile:governed-agent-continuation in authorization_grant_profiles_supported (Section 7.2 of [ID-JAG]), together with the governed profile URIs that identify the grants it accepts. The value indicates handle binding under Section 5.2 of [ICA] with the access-token protection and eligibility of Section 4, and redemption of onward grants with jwt-dpop (Section 7), which the RAS also lists in grant_types_supported ("Authorization Server Metadata" in [FEDERATION]). A RAS lists ICA's urn:ietf:params:oauth:grant-profile:id-jag-continuation, with the requirements of Section 7.2 of [ICA], only if it also binds handles of chains established without this document. Listing governed-agent-continuation for WAGs in this parameter, which Section 8 of [WAG] also uses, awaits coordination (Appendix B.3).¶

An IdP that supports delegated continuation advertises identity_continuation_supported (Section 7.1 of [ICA]), which indicates continuation-capable ID-JAG issuance; an IdP that supports only self-acting continuation does not. Support for self-acting continuation is established through trusted configuration ("Capability Discovery" in [FEDERATION]); no IdP metadata advertises it. The same holds for grant-anchored continuation (Section 10.1). Advertisement indicates capability and does not authorize continuation.¶

11.1. Identity Provider

• Continuation window: To keep continuation available throughout the authorization that the accepting RAS derives from a hop, a deployment sizes the window of Section 3.1 to cover the redemption window of the grant that carries the hop's handle, plus the lifetime of the access tokens, and of any refresh authorization, that the RAS issues for it. A shorter window limits how long a compromised CAI can use the hop (Section 12.1). Its cost is that the IdP rejects new continuation requests from a hop whose tokens are still accepted, and the gateway fails those requests without prompting a new root grant (Section 8). A deployment whose gateway or client continues from durable task state sets the window to the task's needs, as in Appendix A.7. This document sets no default. Lengthening the window does not extend the deadlines of hops already issued, so it cannot restore continuation from a hop whose deadline has passed. Continuation can still proceed from a later hop within its own deadline; a task with no such hop, such as the scheduled variant once H0's deadline passes, needs a new chain.¶

• Agent sessions: A working agent obtains a new WAG at least as often as its gateway access token expires, since WAG redemption yields no refresh token, so a deployment sets the idle timeout longer than that token's lifetime. If the token outlives the session, continuation fails, and the gateway's response leads the agent's client to a new root grant (Section 8). Work that a gateway performs after the agent stops authenticating, such as queued work, loses continuation at the idle timeout; work that must outlive the agent's authentication needs a durable anchor (Appendix B.4).¶

• Restored relationships: The IdP can determine whether a change ended a chain when it applies the change or at the next continuation, for example by comparing a revision of each relationship, recorded at establishment and changed by every disablement or withdrawal (Section 9).¶

11.2. Continuing Client

• Several Governance Tenants: A gateway that serves several Governance Tenants is configured in each, because [ICA] scopes actor identities and CAI trust to one tenant. It selects the registration for a continuation by configuration. Where each Governance Tenant reaches the gateway through a Target Tenant that the gateway's RAS trusts for that issuer tenant alone, the Target Tenant the access token carries ("Access Token Issuance and Response" in [FEDERATION]; by default its audience) identifies the Governance Tenant. Where one Target Tenant is trusted for several, the gateway obtains the tenant its RAS bound to the authorization (Section 4) by deployment-specific means; this document defines no carrier for it. A continuation authenticated with another tenant's registration fails validation, since its canonical actor identity and Continuation Association belong to that other tenant (steps 4 and 6 of Section 6.4): the identity mismatch of step 4 comes first, with invalid_request (Section 5.5.6 of [ICA]).¶

12.1. Gateway Compromise

A compromised gateway that can still authenticate and prove its key can continue each chain whose access token it has received, to any target that the chain authorization, the agent's current authorization, and its Continuation Associations permit, and can use the downstream tokens it holds until they expire. Where its operator does not control the CAI, it cannot continue a chain whose token it has not received, because the CAI attests only hops bound to tokens presented to it (Section 5.4.3 of [ICA]). Where its operator runs the CAI, as when the gateway's own RAS performs that role, the CAI can attest any hop its RAS accepted, as Section 9.5 of [ICA] notes for a compromised RAS, until the chain ends or the hop's continuation window passes. In either case it cannot change the agent or user, convert the acting relationship, or exceed the agent's own authorization. The window does not bound the chain: where policy permits continuation to a target whose RAS the operator also runs, each hop accepted there has a window of its own, and only the hop-count limit of Section 6.3 of [ICA] bounds how far the operator can extend the chain. Narrow Continuation Associations, chain authorizations that restrict targets, a short continuation window, short downstream token lifetimes, and sender-constrained ingress reduce the exposure; the last also keeps a stolen bearer token at the gateway from inducing an honest continuation (Section 9.1 of [ICA], Section 4).¶

12.2. The Continuing Client Is Not an Actor

Placing the gateway in act, as Section 5.5.5 of [ICA] does for the current actor, would give every agent behind a gateway the same outermost actor, recreating at the actor level the shared-client problem. A governed RAS and API would have to process nested act, which [FEDERATION] rejects, and a WAG, which carries no act, could not represent the gateway at all.¶

The agent acts for the user, and the gateway forwards the agent's request. A forwarding intermediary is still disclosed, in continuation_via, so attribution and path-based policy need no lineage in act.¶

The user's approval reaches the gateway through the Delegation Authorization, which must permit continuation for a delegated chain to exist. Continuation never turns a delegated chain into a WAG, which would let an agent act on its own authority because a user's request reached it.¶

12.3. Attribution Through an Intermediary

Downstream records attribute an action to the Agent Principal and, for delegated access, the user, with the continuing client as client_id and every continuing client on the path in continuation_via. A target RAS can therefore audit and authorize the path without consulting the IdP, and so can an API whose RAS supports path disclosure; the IdP's hop records remain authoritative. A handle does not distinguish a root grant from an onward grant; a resource that must tell a gateway from the agent's own client uses the authenticated client_id or the presence of continuation_via, which only onward grants carry. Where the gateway shares a registration with agents' clients ("Issuance Prerequisites" in [FEDERATION]), only continuation_via tells them apart.¶

12.4. Self-Acting Chains

[ICA] anchors a chain to state showing that its principal is still present and records what the chain may do separately. An Agent Authorization is often indefinite, so as an anchor it cannot tell a working agent from one that has stopped; a dedicated-client assertion lasts one request, and routine credential rotation would end chains. Only the agent's own authentication refreshes an agent session, so a gateway cannot extend a chain it continues, and keeping it per Identity Binding stops activity on one platform from sustaining chains rooted through another. The absolute expiration bounds a session the agent keeps active, as the absolute authorization expiration of "Optional RAS Refresh Tokens" in [FEDERATION] bounds refresh; without it, a chain would substitute for the refresh token that [WAG] prohibits.¶

When an agent stops authenticating through a binding, its self-acting chains through that binding end within the idle timeout without administrative action. A party holding the agent's credential can keep its session active, as a stolen user credential can keep a user session active, until the absolute expiration or the credential's revocation (Section 9).¶

12.5. Induced Continuation

An agent induced to misuse its authority ("Misuse by an Authorized Agent" in [FEDERATION]) can ask a gateway to continue its request to any target its chain permits. The scope of the agent's access token at the gateway does not limit that authority, as [ICA] notes for incoming access-token scopes. The chain authorization, the agent's current Delegation or Agent Authorization, and the continuing client's Continuation Association bound each onward grant instead (Section 6.4), and the target applies its own authorization. A deployment that needs onward authority narrower than the agent's authorization records narrower restrictions in the chain authorization or the Continuation Association.¶

12.6. Governance Events End the Chain

The root's Identity Binding, Client Association, and credential are the chain's only link between the agent and an authenticated client. When any is withdrawn, the chain has no current basis, even if another binding resolves the same agent for new issuance. An ended chain stays ended, as in Section 6.2 of [ICA], and reactivation permits new decisions only, as in [FEDERATION].¶

12.7. Disablement Windows

Issued onward grants and downstream access tokens, including those a gateway has cached, remain usable after a chain ends until they expire or their revocation is applied. A refresh token that a target RAS issues under "Optional RAS Refresh Tokens" in [FEDERATION] extends access further; a deployment that relies on chain ending configures its targets not to issue refresh tokens to continuing clients, so that renewal is another continuation.¶

15.1. Normative References

[FEDERATION]

McGuinness, K., "OAuth 2.0 Profile for Agent Principal Federation", Work in Progress, Internet-Draft, draft-mcguinness-oauth-governed-agent-federation, 9 October 2026, <https://mcguinness.github.io/agent-principal-profiles/draft-mcguinness-oauth-governed-agent-federation.html>.

[ICA]

McGuinness, K. and A. Parecki, "Identity Continuation Assertion for OAuth 2.0 Token Exchange", Work in Progress, Internet-Draft, draft-mcguinness-oauth-id-continuation-assertion-02, 8 September 2026, <https://datatracker.ietf.org/doc/html/draft-mcguinness-oauth-id-continuation-assertion-02>.

[ID-JAG]

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

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

[RFC6750]

Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, DOI 10.17487/RFC6750, October 2012, <https://www.rfc-editor.org/rfc/rfc6750>.

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

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

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

[RFC9110]

Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, <https://www.rfc-editor.org/rfc/rfc9110>.

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

[BCP14]

Best Current Practice 14, <https://www.rfc-editor.org/info/bcp14>.
At the time of writing, this BCP comprises the following:

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/info/rfc2119>.

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/info/rfc8174>.

15.2. Informative References

[OVERSIGHT]

McGuinness, K., "Human Oversight Profile for Agent Principal Federation", Work in Progress, Internet-Draft, draft-mcguinness-oauth-governed-agent-oversight, <https://mcguinness.github.io/agent-principal-profiles/draft-mcguinness-oauth-governed-agent-oversight.html>.

[AGENT-LIFECYCLE]

McGuinness, K., "Agent Principal Lifecycle Profile for SCIM and OAuth", Work in Progress, Internet-Draft, draft-mcguinness-oauth-governed-agent-lifecycle, n.d., <https://mcguinness.github.io/agent-principal-profiles/draft-mcguinness-oauth-governed-agent-lifecycle.html>.

[AGENT-MANAGEMENT]

McGuinness, K., "SCIM Profile for Agent Principal Management", Work in Progress, Internet-Draft, draft-mcguinness-scim-agent-federation, 18 September 2026, <https://mcguinness.github.io/agent-principal-profiles/draft-mcguinness-scim-agent-federation.html>.

[EMA]

Model Context Protocol, "Enterprise-Managed Authorization", n.d., <https://github.com/modelcontextprotocol/ext-auth/blob/main/specification/stable/enterprise-managed-authorization/2026-07-28/enterprise-managed-authorization.mdx>.

[GUIDE]

McGuinness, K., "Implementer's Guide for Agent Principal Federation", <https://github.com/mcguinness/agent-principal-profiles/blob/main/IMPLEMENTERS-GUIDE.md>.

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

[MCP]

Model Context Protocol, "Model Context Protocol Specification, Revision 2026-07-28", 28 July 2026, <https://modelcontextprotocol.io/specification/2026-07-28>.

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

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

[RFC7662]

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

[WAG]

Carleton, P., Steele, N., Parecki, A., Schwenkschuster, A., and B. Campbell, "Workload Authorization Grant", Work in Progress, Internet-Draft, draft-carleton-workload-authz-grant-02, 2 November 2026, <https://datatracker.ietf.org/doc/html/draft-carleton-workload-authz-grant-02>.

A.1. Root Grant and Gateway Access Token

The agent's client exchanges Alice's ID Token, whose sid resolves to her IdP session, as in [FEDERATION], but for audience https://ras.gateway.example/, resource https://gateway.example/mcp, and scope tools.invoke. The root ID-JAG:¶

{
  "iss": "https://idp.example/",
  "sub": "alice-gw",
  "aud": "https://ras.gateway.example/",
  "iat": 1789646463,
  "exp": 1789646763,
  "jti": "gw-grant-1",
  "client_id": "analysis-gw",
  "resource": "https://gateway.example/mcp",
  "scope": "tools.invoke",
  "auth_time": 1789646400,
  "act": {"iss": "https://idp.example/", "sub": "agent-42"},
  "cnf": {"jkt": "JKT_K"},
  "identity_continuation_handle": "Qm7zXu2VtL9pKe4RaW1nHc"
}

The client redeems it with a proof of K. GatewayRAS binds the handle, H0, and issues GW_ACCESS_TOKEN, DPoP-bound and carrying H0:¶

{
  "iss": "https://ras.gateway.example/",
  "sub": "gw-user-7",
  "aud": "https://gateway.example/mcp",
  "iat": 1789646464,
  "exp": 1789647064,
  "jti": "gw-access-1",
  "client_id": "analysis-gw",
  "scope": "tools.invoke",
  "act": {"iss": "https://idp.example/", "sub": "agent-42"},
  "cnf": {"jkt": "JKT_K"},
  "identity_continuation_handle": "Qm7zXu2VtL9pKe4RaW1nHc"
}

The agent calls a tool with this token and a proof of K. The gateway validates both, enforces the actor gate for agent-42 acting for Alice, and routes the call to the file service in acme-data.¶

[MCP] has MCP clients send access tokens with the Bearer scheme and defines no DPoP usage, so this walkthrough assumes that the agent's client and the gateway also support DPoP for this hop. With a bearer-only MCP client, GatewayRAS issues a bearer access token, and the hop is eligible for continuation only where resource policy permits continuation from bearer access tokens for analysis-gw and the gateway resource (Section 4).¶

A.2. Assertion

GW_CAI_PROOF proves G, and GW_ASSERTION_1 is a private_key_jwt assertion for tool-gateway addressed to GatewayRAS:¶

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

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange
&requested_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type
%3Aidentity-continuation
&subject_token=GW_ACCESS_TOKEN
&subject_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type
%3Aaccess_token
&client_id=tool-gateway
&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth
%3Aclient-assertion-type%3Ajwt-bearer
&client_assertion=GW_ASSERTION_1

GatewayRAS confirms that the token is its own, unexpired, and issued for the resource tool-gateway operates, reads H0, rechecks that the authorization is active and eligible, and names https://idp.example/ in identity_continuation_authorization_server. The assertion, ICA_ASSERTION:¶

{
  "iss": "https://ras.gateway.example/",
  "aud": "https://idp.example/",
  "identity_continuation_handle": "Qm7zXu2VtL9pKe4RaW1nHc",
  "act": {"iss": "https://gateway.example/", "sub": "tool-gateway"},
  "cnf": {"jkt": "JKT_G"},
  "iat": 1789646470,
  "exp": 1789646590,
  "jti": "n3Vt7Jq2Xd5PbR9wLc1eKs"
}

A.3. Continuation

IDP_GW_PROOF proves G, and GW_ASSERTION_2 is a fresh private_key_jwt assertion addressed to https://idp.example/:¶

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

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange
&requested_token_type=urn%3Aietf%3Aparams%3Aoauth
%3Atoken-type%3Aid-jag
&client_id=tool-gateway
&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth
%3Aclient-assertion-type%3Ajwt-bearer
&client_assertion=GW_ASSERTION_2
&subject_token=ICA_ASSERTION
&subject_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type
%3Aidentity-continuation
&audience=https%3A%2F%2Fras.example%2F
&resource=https%3A%2F%2Fapi.example%2Ftenants%2Facme-data%2F
&scope=files.read

Every step of Section 6.4 passes: H0 belongs to an active delegated chain, a Continuation Association permits tool-gateway, Alice is alice-ras at https://ras.example/ and tool-gateway is gateway-files there, and Alice's Delegation Authorization permits agent-42, in analysis-client's context, to act for her with files.read. The onward ID-JAG:¶

{
  "iss": "https://idp.example/",
  "sub": "alice-ras",
  "aud": "https://ras.example/",
  "iat": 1789646471,
  "exp": 1789646771,
  "jti": "gw-grant-2",
  "client_id": "gateway-files",
  "resource": "https://api.example/tenants/acme-data/",
  "scope": "files.read",
  "auth_time": 1789646400,
  "act": {"iss": "https://idp.example/", "sub": "agent-42"},
  "continuation_via": [
    {"iss": "https://gateway.example/", "sub": "tool-gateway"}
  ],
  "cnf": {"jkt": "JKT_G"},
  "identity_continuation_handle": "Zp3kRt8VbN2wLq6YsD4mXe"
}

Its sub and act are those of the grant in the walkthrough of [FEDERATION]; its client, key, handle, identifiers, and times differ. It carries the root's auth_time, and its continuation_via lists tool-gateway, whose registration at the target client_id names.¶

A.4. Redemption at the Target

The gateway redeems the onward ID-JAG at https://ras.example/ with the jwt-dpop grant type, a private_key_jwt assertion for gateway-files, and a fresh proof of G. The RAS validates the grant and its confirmation, resolves Alice to user-108, correlates agent-42, applies the actor gate, and ignores the handle and continuation_via, since it implements only [FEDERATION]. The access token:¶

{
  "iss": "https://ras.example/",
  "sub": "user-108",
  "aud": "https://api.example/tenants/acme-data/",
  "iat": 1789646472,
  "exp": 1789647072,
  "jti": "access-gw-1",
  "client_id": "gateway-files",
  "scope": "files.read",
  "act": {"iss": "https://idp.example/", "sub": "agent-42"},
  "cnf": {"jkt": "JKT_G"}
}

The API enforces Alice's permissions, the actor gate for agent-42, and the tenant, as it would for the agent's own client. The gateway caches the token for Alice, agent-42, Target Tenant acme-data, https://ras.example/, the resource, files.read, key G, and H0 (Section 8).¶

A.5. Self-Acting Variant

The agent's client instead obtains a WAG for GatewayRAS as analysis-gw-svc. The IdP creates an agent session for agent-42 through the binding of analysis-client, with a 30-minute idle timeout and an absolute expiration eight hours later, and anchors a self-acting chain to it:¶

{
  "iss": "https://idp.example/",
  "sub": "agent-42",
  "aud": "https://ras.gateway.example/",
  "iat": 1789646580,
  "exp": 1789646880,
  "jti": "gw-wag-1",
  "client_id": "analysis-gw-svc",
  "resource": "https://gateway.example/mcp",
  "scope": "tools.invoke",
  "cnf": {"jkt": "JKT_K"},
  "identity_continuation_handle": "Lb5wNq2XzR8tKc4VmP7sYd"
}

GatewayRAS issues an access token for its local principal gw-agent-42, with no act and client_id analysis-gw-svc, by which the gateway treats it as self-acting. With an assertion for this chain's handle, issued at 1789646585, the gateway requests a WAG. The self-acting Continuation Association, the Agent Authorization of agent-42 for files.read, and the agent session all hold, and the IdP issues this onward WAG with typ oauth-wag+jwt:¶

{
  "iss": "https://idp.example/",
  "sub": "agent-42",
  "aud": "https://ras.example/",
  "iat": 1789646590,
  "exp": 1789646890,
  "jti": "gw-wag-2",
  "client_id": "gateway-files-svc",
  "resource": "https://api.example/tenants/acme-data/",
  "scope": "files.read",
  "continuation_via": [
    {"iss": "https://gateway.example/", "sub": "tool-gateway"}
  ],
  "cnf": {"jkt": "JKT_G"},
  "identity_continuation_handle": "Tf8hMv3QwJ6nZr1KxB4cGe"
}

The target RAS correlates agent-42 to service-principal-42, as in [FEDERATION], and issues an access token for it with no act and no refresh token. The agent's client obtains a new WAG each time its ten-minute gateway access token expires, which refreshes the agent session; the gateway's continuations do not.¶

A.6. Two-Gateway Variant

Here tool-gateway reaches the file service through a second gateway, data-gateway at https://data-gateway.example/, whose RAS is continuation-aware and performs the CAI role. The IdP configures data-gateway as it does tool-gateway, with canonical actor identity (https://data-gateway.example/, data-gateway), a Continuation Association for agent-42's delegated chains, and the registration data-files at https://ras.example/; D is its DPoP key.¶

tool-gateway continues H0 to the data gateway's RAS, which binds the child hop H1. data-gateway then obtains an assertion for H1 and continues to https://ras.example/. The onward ID-JAG (excerpt):¶

{
  "sub": "alice-ras",
  "aud": "https://ras.example/",
  "client_id": "data-files",
  "act": {"iss": "https://idp.example/", "sub": "agent-42"},
  "continuation_via": [
    {"iss": "https://gateway.example/", "sub": "tool-gateway"},
    {"iss": "https://data-gateway.example/", "sub": "data-gateway"}
  ],
  "cnf": {"jkt": "JKT_D"}
}

In this variant, https://ras.example/ supports path disclosure (Section 6.5.2), so the access token it issues carries the same list to the API (excerpt):¶

{
  "sub": "user-108",
  "client_id": "data-files",
  "act": {"iss": "https://idp.example/", "sub": "agent-42"},
  "continuation_via": [
    {"iss": "https://gateway.example/", "sub": "tool-gateway"},
    {"iss": "https://data-gateway.example/", "sub": "data-gateway"}
  ],
  "cnf": {"jkt": "JKT_D"}
}

The API applies the actor gate to agent-42 alone. A policy that admits agent-42 only through tool-gateway matches the first entry, and the last entry identifies the client that presented the grant.¶

A.7. Scheduled Variant

Here agent-42 prepares a daily report for Alice after she has signed out, without a gateway. The client uses Alice's refresh token once to establish the chain. Later runs authenticate the client and continue from server-held task state.¶

The agent's operator runs https://ras.agents.example/ as a continuation-aware RAS and CAI for its task service https://agents.example/tasks, where the agent's client is analysis-tasks and Alice is alice-tasks to the IdP. The IdP claims grant-anchored continuation (Section 10.1), and the deployment supports durable task authorization, with Transaction Tokens carrying each scheduled run's context; an IdP without grant-anchor support issues the root ID-JAG without a handle (Section 6.1 of [ICA]). The IdP accepts refresh-token subjects from analysis-client ("Subject Token Validation" in [FEDERATION]), trusts AgentRAS as CAI for its own hops, and has a Continuation Association that permits analysis-client to continue agent-42's delegated chains to resources in acme-data. analysis-client has the default canonical actor identity of Section 5.5.2 of [ICA], (https://idp.example/, analysis-client), so the IdP pairs AgentRAS with itself as the client's identity authority.¶

{
  "sub": "alice-tasks",
  "aud": "https://ras.agents.example/",
  "client_id": "analysis-tasks",
  "resource": "https://agents.example/tasks",
  "scope": "tasks.run",
  "auth_time": 1789646400,
  "act": {"iss": "https://idp.example/", "sub": "agent-42"},
  "cnf": {"jkt": "JKT_K"},
  "identity_continuation_handle": "Wd4nKs8QpZ2vXe6TbR1mLy"
}

task_id:   task-7
user:      alice-tasks
agent:     agent-42
runner:    analysis-client
handle:    Wd4nKs8QpZ2vXe6TbR1mLy   # H0
schedule:  daily at 06:00 UTC for 30 days
status:    active

{
  "sub": "alice-ras",
  "aud": "https://ras.example/",
  "iat": 1789711205,
  "exp": 1789711505,
  "client_id": "analysis-api",
  "resource": "https://api.example/tenants/acme-data/",
  "scope": "files.read",
  "auth_time": 1789646400,
  "act": {"iss": "https://idp.example/", "sub": "agent-42"},
  "continuation_via": [
    {"iss": "https://idp.example/", "sub": "analysis-client"}
  ],
  "cnf": {"jkt": "JKT_K"},
  "identity_continuation_handle": "Hc7rVm3NxT9kQw5ZpB2sJf"
}

A.8. Negative Tests

Each case changes the stated conditions; all other checks succeed.¶

B.1. Changes to ICA

Where this document is silent, [ICA] applies unchanged.¶

B.2. Changes to FEDERATION

Where this document is silent, [FEDERATION] applies unchanged.¶

B.3. Dependencies

B.4. Open Items

[[ To be removed before publication as an RFC ]]¶

1. Home of continuation_via: Should [ICA] define it, with an acting or forwarding mode for each hop, so that this document uses ICA's claim instead of its own? Should policy ever be able to narrow it, as it can narrow the depth of act (Section 6.5.2)?¶

2. Self-acting discovery: Should the IdP advertise support for self-acting continuation in metadata?¶

3. Agent session limits: Should this document recommend default idle and absolute limits for agent sessions, and convey a session's expiration to the gateway so that long-running work can obtain a new root before it?¶

4. Continuation Association management: Should [AGENT-MANAGEMENT] model Continuation Associations beside Client Associations?¶

5. Durable self-acting anchors: Should a self-acting chain be able to anchor to a work authorization with its own lifecycle, as a delegated chain can anchor to a refresh-token grant (Section 12.4)?¶

6. Temporary refusals: Should [ICA] adopt the same HTTP 503 response for state it cannot confirm, and define an OAuth error code for policy that blocks a chain only temporarily (Section 6.6)?¶