Atlassian

lzhu3@atlassian.com

Atlassian

zberg@atlassian.com

OAuth Working Group OAuth Token Exchange on-behalf-of delegation handle This document defines a standardized continuation mechanism for delegated OAuth 2.0 Token Exchange. RFC 8693 permits an authorization server to include an optional "refresh_token" in a successful Token Exchange response, but does not specify issuance policy, delegated authorization semantics, lifecycle, or security properties for continuation credentials. This specification fills that gap for asynchronous and long-running delegated service workflows by defining the Delegation Handle. The Delegation Handle is a delegation-bound continuation credential with a new token type identifier usable as the RFC 8693 "subject_token_type". An acting service presents the handle as the "subject_token" in a subsequent RFC 8693 Token Exchange request after the original subject token is no longer available. This specification standardizes delegated continuation semantics, preservation of subject and actor relationships, audience confinement, scope monotonicity, actor binding, authorization re-evaluation during continuation, token rotation, revocation, bounded delegation lifetime, and interoperability between implementations.

Introduction OAuth 2.0 Token Exchange, specified in Section 2 of and illustrated by the example in Section 2.3, is commonly used in an OAuth on-behalf-of (OBO) Token Exchange architecture. An acting service exchanges one token for an audience-specific downstream access token while preserving authorization context. In the delegated case, the downstream token represents both the subject and the actor semantics illustrated in Appendix A of . This model works well for synchronous delegated service calls. The problem addressed here appears when delegated service chains become asynchronous, long-running, autonomous, or disconnected from the original caller. The acting service may need to continue an already-established delegated Token Exchange after the original subject token is no longer available, while still preserving subject identity, actor identity, delegated scope, audience binding, and policy enforcement. The problem exists regardless of trust-domain boundaries. Within a single trust domain, it appears in ordinary OAuth OBO Token Exchange chains between services using RFC 8693 Token Exchange. Across trust domains, the same architectural model persists, but cross-domain continuation may additionally rely on a JWT authorization grant issued by an authorization server in one domain and consumed by an authorization server in another, as profiled by using and . This document standardizes the delegated continuation model itself; it does not redefine the OAuth Refresh Token grant and it does not introduce a new OAuth authorization grant type.

The Problem In a typical OAuth OBO Token Exchange deployment within a single trust domain, each intermediate service obtains an audience-specific downstream access token by presenting an incoming token and its own actor credentials to the authorization server. The authorization server preserves authorization context while changing the token audience for the next hop. This approach assumes the original subject token, or an equivalent delegated input, remains available while the chain executes. That assumption breaks down for asynchronous and long-running workflows such as background jobs, scheduled tasks, workflow engines, agent task queues, or multi-stage orchestrations. When the delegated downstream token expires after the original caller has gone offline, the acting service may need to continue the delegated chain even though it no longer possesses a usable original subject token.

Why Existing Mechanisms Are Insufficient RFC 8693 already allows an authorization server to include an optional "refresh_token" in a successful Token Exchange response; see Section 2.2.1 of . However, RFC 8693 does not define the delegated authorization semantics of such a continuation credential. In particular, it does not standardize how a continuation credential preserves subject and actor relationships, how it is confined to delegated audiences and scopes, how the authorization server re-evaluates authorization on continuation, how rotation and revocation work, or how delegation lifetime is bounded for interoperability. RFC 6749 refresh tokens are also not sufficient to describe the delegated continuation model standardized here. The OAuth Refresh Token grant in refreshes access associated with a client and a grant, but it does not define the subject-and-actor preservation model used by delegated RFC 8693 Token Exchange. This document therefore extends RFC 8693 Token Exchange rather than extending or replacing the RFC 6749 refresh-token grant.

Overall Positioning This specification is an extension to OAuth 2.0 Token Exchange. It does not propose adding refresh tokens to RFC 8693, because RFC 8693 already permits authorization servers to return an optional "refresh_token" in successful Token Exchange responses. Instead, this specification standardizes a Delegation Handle token type and the delegated continuation semantics that RFC 8693 leaves unspecified. The Delegation Handle is presented as the "subject_token" in a later RFC 8693 Token Exchange request to the authorization server that issued it. The continuation request uses the existing Token Exchange grant type. No new OAuth authorization grant type is introduced.

Non-Goals

• This document does not define a replacement for RFC 6749 refresh tokens.
• This document does not define a new OAuth authorization grant type.
• This document does not define a generic cross-domain federation framework; it only defines delegated continuation semantics that can be composed with cross-domain deployments.
• This document does not remove the need for authorization-server policy. Issuance and continuation remain policy-governed.

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. This document uses the OAuth terminology of and . The following additional terms are used: OAuth OBO Token Exchange: an architectural pattern in which an acting service uses RFC 8693 Token Exchange to obtain an audience-specific access token for a downstream service while preserving authorization context. delegated Token Exchange: an RFC 8693 Token Exchange in which subject and actor relationships are both security-relevant. audience-specific access token: an access token issued for a specific downstream resource or audience as part of an RFC 8693 Token Exchange chain. authorization context preservation: preservation of the subject, actor, and delegated authorization semantics across audience changes. Delegation Handle: a delegation-bound continuation credential with the token type identifier defined by this document. An acting service presents it as the "subject_token" in a subsequent RFC 8693 Token Exchange request and identifies it using the corresponding "subject_token_type" value. acting service: the service acting on behalf of the subject and identified as the actor in the delegated chain. subject: the end user or principal on whose behalf the delegated chain was originally established. actor: the acting principal semantics described in Appendix A of . ICTE: reserved in this document for the cross-domain profile in which a JWT authorization grant issued by the authorization server in one trust domain is conveyed by the acting service to the authorization server in another trust domain.

Architectural Model

Within a Single Trust Domain Within a single trust domain, this specification assumes an OAuth OBO Token Exchange architecture using RFC 8693 Token Exchange. Each intermediate service exchanges an incoming token for an audience-specific downstream access token. The audience changes at each hop, while authorization context is preserved. The Delegation Handle extends this model by allowing an acting service to continue an established delegated Token Exchange after the original subject token is no longer available.

Across Trust Domains Across trust domains, the same delegated Token Exchange architecture can be layered with the JWT authorization grant flow profiled by . The acting service obtains a JWT authorization grant from the authorization server in one domain and presents that assertion to the authorization server in another domain using . In this document, ICTE refers only to that cross-domain composition. ICTE is therefore a deployment model layered on top of OAuth Token Exchange rather than the general architectural concept.

Canonical Continuation Flows In a single-domain deployment, the flow is:

1. A client calls Service A with an access token whose subject is the end user and whose audience is Service A.
2. Service A, acting as the RFC 8693 client, exchanges that token for an access token whose audience is Service B. The authorization server establishes the end user as the subject and Service A as the actor.
3. If policy permits asynchronous continuation, the authorization server returns both the audience-specific access token for Service B and a Delegation Handle bound to Service A and the established delegated authorization.
4. Service A calls Service B with the audience-specific access token.
5. After the original token for Service A is unavailable, Service A presents the Delegation Handle as the "subject_token" in another RFC 8693 Token Exchange. The authorization server re-evaluates authorization and, if permitted, returns a new audience-specific access token for Service B and a rotated Delegation Handle.

In a cross-domain ICTE deployment, the Delegation Handle remains an input to the authorization server that issued it. Continuation at that server can produce the JWT authorization grant defined by ICTE for the target trust domain. The acting service then presents that JWT authorization grant to the target domain's authorization server using RFC 7523 and obtains the audience-specific access token there. The Delegation Handle itself does not cross the trust boundary unless a separate profile explicitly defines that behavior.

Contribution of This Specification This specification standardizes the pieces that RFC 8693 leaves unspecified for delegated continuation:

• the Delegation Handle token type;
• delegated continuation semantics;
• preservation of subject and actor relationships;
• audience confinement;
• scope monotonicity;
• actor binding;
• authorization re-evaluation during continuation;
• token rotation;
• revocation;
• bounded delegation lifetime; and
• interoperability between implementations.

The Delegation Handle The Delegation Handle is a delegation-bound continuation credential with the token type identifier "urn:ietf:params:oauth:token-type:delegation-handle". That identifier is usable as an RFC 8693 "subject_token_type" value. The handle is not a new OAuth grant type, an RFC 6749 refresh token, or a replacement for an OAuth refresh token. It is intended for delegated continuation of RFC 8693 Token Exchange when the original subject token is no longer available. A Delegation Handle is presented as the "subject_token" in a subsequent RFC 8693 Token Exchange request together with "subject_token_type" set to the token type defined by this document. The authorization server evaluates that continuation request as delegated Token Exchange, not as a refresh-token grant.

Token Format The Delegation Handle is a signed JWT using the JWS Compact Serialization . The JOSE header MUST include "alg" and "typ". The "typ" value MUST be "dh+jwt". The authorization server SHOULD include "kid". Implementations MUST follow the algorithm-verification and explicit-typing guidance in . In particular, a recipient MUST use an algorithm allowlist established independently of the JWT, MUST reject an algorithm not permitted for the issuer, and MUST validate that "typ" is exactly "dh+jwt" before applying Delegation Handle processing rules.

Claims and Semantics The Delegation Handle MUST contain the following claims:

• "iss": the authorization server that issued the handle.
• "sub": the subject of the established delegated Token Exchange.
• "aud": the authorization server that is permitted to accept the handle as a Token Exchange subject token.
• "act": the acting service and, when present, the preserved chain of prior actors, using the actor representation defined by RFC 8693.
• "scope": the maximum scope set available to subsequent continuation requests.
• "delegated_aud": the downstream audience or audiences for which continuation may issue audience-specific access tokens. This claim is distinct from "aud", which identifies the recipient of the Delegation Handle itself.
• "iat" and "exp": the handle issuance and expiration times.
• "jti": a unique handle identifier suitable for replay detection, rotation, and revocation.
• "continuations_remaining": a non-negative integer that bounds how many further delegated continuations are permitted in the handle family.

The "act" claim MUST preserve the actor relationship established by the initial delegated Token Exchange. Rotation or continuation MUST NOT substitute a different current actor or remove a prior actor from the chain. The "sub" value MUST remain unchanged throughout a handle family. The "scope" and "delegated_aud" values MUST NOT be widened during continuation. Authorization servers MAY enforce stricter local limits than values carried in the handle. The acting service binding MUST be established by the combination of the actor identity encoded in the handle and the client authentication used at the continuation request. The authorization server MUST verify that the authenticated client is the same acting service represented by the handle. When proof-of-possession mechanisms such as mTLS or DPoP are used, the authorization server SHOULD additionally bind the handle or the continued access token to the proof-of-possession key. The "act" claim alone is not sufficient without successful client authentication at continuation time. A Delegation Handle MAY contain additional claims. A recipient MUST reject the handle if any required claim is absent, if "continuations_remaining" is zero, or if a required claim has the wrong JSON type.

Issuance During RFC 8693 Token Exchange

Initial OAuth OBO Token Exchange The acting service performs an RFC 8693 Token Exchange as defined in Section 2 of . That initial delegated Token Exchange produces an audience-specific downstream access token. The authorization server MUST establish the subject from the "subject_token" and the actor from the "actor_token", when one is supplied, or from the authenticated client according to authorization-server policy. The established relationship MUST be represented consistently in the issued access token and Delegation Handle. Appendix A of illustrates the applicable delegation and actor semantics.

Response Extensions When the authorization server chooses to permit delegated continuation, it MAY include a Delegation Handle in the successful Token Exchange response. This document defines the response parameters "delegation_handle", "delegation_handle_expires_in", and the request parameter "request_delegation_handle".

• "request_delegation_handle" is an OPTIONAL Token Exchange request parameter. Its value is the case-sensitive string "true". It indicates that the acting service requests a Delegation Handle if authorization-server policy permits continuation. Other values MUST be rejected with "invalid_request".
• "delegation_handle" is an OPTIONAL string in a successful Token Exchange response containing the Delegation Handle.
• "delegation_handle_expires_in" is REQUIRED when "delegation_handle" is returned. Its value is a JSON number that expresses the lifetime in seconds of the returned handle from the time the response was generated.

RFC 8693 Section 2.2.1 already permits the authorization server to include an optional "refresh_token" in a successful Token Exchange response. This specification does not redefine that parameter. A Delegation Handle is carried in a distinct response parameter because it is subsequently used as an RFC 8693 "subject_token", not with the RFC 6749 Refresh Token grant. An authorization server MUST NOT return both "refresh_token" and "delegation_handle" as alternative representations of the same continuation credential.

Authorization Server Behavior On issuance, the authorization server MUST determine whether delegated continuation is allowed for the acting service, the subject, the requested downstream audience, the delegated scope, and any required authentication context. If continuation is allowed, the authorization server MUST mint a Delegation Handle bound to that delegated authorization context and MUST emit an audit record sufficient to link the handle to the original Token Exchange decision.

Example Issuance and Continuation The following non-normative example illustrates an initial delegated RFC 8693 Token Exchange followed later by continuation using a Delegation Handle.

The "delegation_handle" value above is a compactly serialized JWT. For clarity, its decoded JOSE header and claims could be:

Illustrative Decoded Delegation Handle

In this example, "aud" identifies the authorization server that accepts the handle as a Token Exchange subject token. It does not identify the downstream resource server. The "delegated_aud" claim confines the audience-specific access tokens that continuation may produce. For a multi-hop A to B to C chain, if Service B is the current acting service and Service A is a prior actor, an illustrative handle issued to Service B for continuation toward Service C could instead contain the following claims. Consistent with Section 4.1 of , the outermost "act" identifies the current actor and the nested "act" identifies a prior actor.

Illustrative Multi-Hop Delegation Handle Claims

The multi-hop handle is presented by Service B to "https://as.example.com". Service B authenticates as the current actor, and successful continuation may issue an audience-specific access token for Service C. The resulting Service C access token has an audience identifying Service C; the Delegation Handle itself continues to identify the authorization server in "aud".

Continuation Using the Delegation Handle

Continuation Request To continue a delegated Token Exchange, the acting service sends a new RFC 8693 Token Exchange request to the authorization server identified by the handle's "iss" and "aud" claims. The acting service presents the Delegation Handle as the "subject_token" and sets "subject_token_type" to "urn:ietf:params:oauth:token-type:delegation-handle". The request identifies the desired downstream audience and requested scope for the next audience-specific access token. A separate cross-domain profile, such as ICTE, MAY define a trusted authorization-server interaction that carries the authorization context farther; this document does not make a Delegation Handle issued by one authorization server directly acceptable to an unrelated authorization server. If the handle authorizes more than one value in "delegated_aud", the continuation request MUST identify one authorized downstream audience or resource from that set. The continuation request MUST NOT request an audience outside that set. The requested scope MUST be equal to or narrower than the delegated scope represented by the handle. A client MAY request narrower scope on any continuation request.

Authorization Re-evaluation On every continuation request, the authorization server MUST re-evaluate delegated authorization rather than treating the continuation as unconditional token refresh. At minimum, it MUST validate the handle signature, "typ", issuer, recipient audience, temporal claims, token identifier, and required claim types; confirm the acting service binding; check revocation and rotation state; enforce audience confinement via "delegated_aud"; enforce scope monotonicity; preserve "sub" and "act"; and re-check current authorization policy for the requested continuation. This authorization re-evaluation is a core interoperability property of this specification and is not specified by RFC 8693. Continuation remains delegated Token Exchange, not a weaker lifecycle shortcut.

Error Handling If the Delegation Handle is invalid, expired, revoked, exhausted, previously consumed, unacceptable under policy, or bound to an acting service other than the authenticated client, the authorization server MUST reject it using "invalid_request", as required by Section 2.2.2 of for an invalid or unacceptable "subject_token". Error descriptions SHOULD avoid revealing whether a particular subject, actor, or handle identifier exists. If the requested downstream audience is not within "delegated_aud", the authorization server MUST reject the continuation request and SHOULD return "invalid_target", as specified by Section 2.2.2 of . If the requested scope is broader than the scope encoded in the handle or broader than currently permitted by policy, the authorization server MUST reject the request with "invalid_scope". If local policy or current subject/session state no longer permits continuation even though the handle is structurally valid, the authorization server MUST reject the request. Implementations SHOULD log enough information to distinguish structural token failures from policy re-evaluation failures.

Rotation and Response If the continuation request succeeds, the authorization server returns a new audience-specific access token. If further continuation remains authorized and was requested, the authorization server MUST also return a replacement Delegation Handle. The replacement MUST preserve or narrow authorization state, MUST contain a lower "continuations_remaining" value, and MUST NOT have an "exp" value later than the maximum delegation lifetime established during initial issuance. When a new handle is returned, the previous handle instance MUST be treated as spent once the continuation succeeds. If two concurrent continuation requests race using the same still-valid handle, the authorization server MUST prevent both from succeeding in a way that creates inconsistent continuation state. Implementations MAY do so by one-time-use handles, transactional rotation state, or equivalent replay controls.

Bounded Delegation Lifetime The authorization server MUST establish an absolute maximum delegation lifetime during initial issuance and MUST NOT extend that deadline through rotation. Continuation MUST end when the handle expires, when "continuations_remaining" is exhausted, when revocation applies, when actor binding can no longer be established, or when policy re-evaluation no longer permits delegated continuation.

Authorization Server Policy RFC 8693 leaves issuance policy and delegated continuation semantics unspecified. This specification requires authorization-server policy to govern whether Delegation Handles are issued and continued, for which acting services, for which audiences, with which maximum scopes, for how long, and under what authentication-context requirements. Policy MUST be applied at issuance and re-applied at each continuation request. Policy changes therefore affect future continuation requests even when a previously issued handle still exists. At minimum, policy evaluation MUST be capable of deciding whether continuation is allowed for a given acting service, subject class, downstream audience, maximum scope set, continuation lifetime, and proof-of-possession or client-authentication strength. Implementations MAY additionally factor in workload type, transaction state, time of day, or other local signals.

Revocation The authorization server MUST support revocation of Delegation Handles and MUST ensure that revocation is consulted during continuation. An acting service MAY revoke a handle at the authorization server's revocation endpoint using . The "token" parameter carries the Delegation Handle, and the OPTIONAL "token_type_hint" value is "delegation_handle". The authorization server MUST authenticate the acting service and MUST verify that the handle belongs to that acting service before applying revocation. Revocation MAY be handle-specific or apply to the entire handle family. An authorization server MUST document whether revoking one handle also revokes handles rotated from it and access tokens issued through it. If a Delegation Handle is rotated, the previous handle instance MUST be rendered unusable for further continuation regardless of the authorization server's broader revocation policy. Implementations SHOULD support at least the following revocation triggers: explicit revocation of an individual handle, termination of the subject session or delegated workflow, loss or revocation of the acting service credential, and policy changes that disable future continuation for the relevant audience or scope. The authorization server MUST apply those revocation decisions before issuing any continued access token.

Relationship to Other Specifications

RFC 8693 This document extends the RFC 8693 Token Exchange request and response protocol in Section 2. Section 2.3 provides an example of an OAuth resource server acting as a Token Exchange client. This document relies on Section 2.2.1 for the observation that successful Token Exchange responses may already carry an optional "refresh_token", and on Appendix A for examples of delegation, impersonation, and actor semantics. The Delegation Handle itself is standardized here as a new token type identifier usable with "subject_token_type" and as a delegated continuation model.

RFC 6749 Refresh Tokens The Delegation Handle is not an RFC 6749 refresh token and does not use the OAuth Refresh Token grant. RFC 6749 is relevant here only as a comparison point. The Delegation Handle is used exclusively in subsequent RFC 8693 Token Exchange requests and carries delegated subject-and-actor semantics that RFC 6749 does not standardize.

JWT Authorization Grants When delegated continuation spans trust-domain boundaries, implementations may layer this model with ICTE as profiled by . The acting service conveys a JWT authorization grant issued by one domain's authorization server to another domain's authorization server, following the assertion framework of and the JWT bearer profile of . This is a deployment model layered on top of OAuth Token Exchange rather than the general delegated continuation concept itself.

Deployment Guidance Within a single trust domain, interoperable deployments MUST support RFC 8693 Token Exchange, the Delegation Handle token type defined by this document, authorization re-evaluation on continuation, audience confinement, scope monotonicity, actor binding, and revocation-aware rotation. Cross-domain deployments discussed here as ICTE layer those same properties on top of JWT authorization grants issued by one authorization server and consumed by another. The cross-domain layer does not relax the continuation rules defined by this specification.

Client Interoperability Clients SHOULD treat the Delegation Handle as opaque and simply store and present it in later continuation requests. A client that inspects the JWT for local scheduling or observability MUST NOT use that inspection as an authorization decision, because the authorization server remains authoritative on every continuation request. Only the claims and parameters defined by this specification are protocol-significant for interoperability. Authorization servers MAY include additional claims for local deployment needs, but clients MUST ignore claims they do not understand unless a future specification defines them as mandatory.

Security Considerations The Delegation Handle is a high-value delegation credential. Implementations MUST bind it to the authenticated acting service, MUST enforce audience confinement and scope monotonicity, MUST re-evaluate authorization during continuation, MUST prevent replay, and MUST bound lifetime. Deployments SHOULD use proof-of-possession client authentication or another asymmetric mechanism so that possession of the handle alone is insufficient for continuation. A handle protected only by a shared client secret does not provide the same resistance to credential exfiltration. If handles are one-time-use, the authorization server MUST ensure that successful continuation invalidates the prior handle immediately. If implementations permit limited reuse before rotation, they MUST define replay protection strong enough to prevent concurrent or delayed reuse from widening delegated authority. Stored handles SHOULD receive confidentiality protection comparable to or stronger than access tokens and SHOULD NOT be written to ordinary application logs. The security objective is not merely token renewal. The objective is interoperable continuation of delegated Token Exchange without losing subject identity, actor identity, delegated audience confinement, or authorization context preservation.

Privacy Considerations The Delegation Handle preserves the same subject identity and actor identity relationships already present in delegated Token Exchange. It does not introduce a new class of subject data, but it does extend the lifetime over which delegated continuation state may exist at the acting service. Implementations SHOULD minimize retention, scope each handle to the smallest practical unit of asynchronous work, and apply the same or stronger protections used for other delegated OAuth artifacts. Where deployment requirements permit, subject identifiers carried in continued delegated flows SHOULD be pairwise or otherwise privacy-preserving rather than globally correlatable identifiers. Implementations SHOULD minimize retention of handle bodies, audit only the information needed to support security and operational requirements, and bound retention of continuation artifacts and related logs to the delegated workflow lifetime plus a locally justified audit window.

IANA Considerations This document requests registration of a media type, an OAuth token type URI, three OAuth parameters, one OAuth token type hint, and two JWT claims.

Media Type Registration IANA is requested to register the media type "application/dh+jwt" in the "Media Types" registry. Type name: application Subtype name: dh+jwt Required parameters: N/A Optional parameters: N/A Encoding considerations: binary; content consists of a JWT serialized using the JWS Compact Serialization defined in . Security considerations: see of this document and . Interoperability considerations: N/A Published specification: this document Applications that use this media type: OAuth 2.0 authorization servers, clients, and intermediary services implementing delegated continuation of RFC 8693 Token Exchange. Fragment identifier considerations: N/A Additional information: none Person and email address to contact for further information: the authors of this document Intended usage: COMMON Restrictions on usage: none Author: the authors of this document Change controller: IETF

OAuth URI Registration IANA is requested to register the following value in the "OAuth URI" registry established for OAuth parameters: URI: urn:ietf:params:oauth:token-type:delegation-handle Common name: Delegation Handle Change controller: IETF Specification document: this document

OAuth Parameter Registrations IANA is requested to register the following parameters in the appropriate OAuth parameters registry: Parameter name: delegation_handle Parameter usage location: token response Change controller: IETF Specification document: this document Parameter name: delegation_handle_expires_in Parameter usage location: token response Change controller: IETF Specification document: this document Parameter name: request_delegation_handle Parameter usage location: token request Change controller: IETF Specification document: this document

OAuth Token Type Hint Registration IANA is requested to register the following value in the "OAuth Token Type Hints" registry: Hint value: delegation_handle Change controller: IETF Specification document: this document

JWT Claim Registrations IANA is requested to register the following claim names in the "JSON Web Token Claims" registry: Claim name: delegated_aud Claim description: downstream audience or audiences for which continued delegated Token Exchange may issue audience-specific access tokens Change controller: IETF Specification document: this document Claim name: continuations_remaining Claim description: maximum number of further delegated continuations permitted with a Delegation Handle Change controller: IETF Specification document: this document

Normative References Informative References

Acknowledgments The authors thank reviewers and implementers who clarified the need to position this work as a standardized continuation mechanism for delegated RFC 8693 Token Exchange rather than as an extension of the OAuth Refresh Token grant. Their feedback helped sharpen the architectural distinction between ordinary OAuth OBO Token Exchange within a trust domain and ICTE-style cross-domain authorization-server interactions layered on top of Token Exchange.