Your draft focuses on delegated RFC 8693 Token Exchange, but I think it is applicable also when the client does not delegate to other actors. For example, the user asked an application to do something that requires more time, and meanwhile the user is offline.
[Larry Zhu] If an ordinary OAuth client is acting directly under a user grant, existing refresh-token mechanisms already support offline continuation. This draft addresses the narrower interoperability gap created when a refresh token is issued by a delegated RFC 8693 Token Exchange: preserving the user as the subject, the client as the actor, and the associated actor chain, resources, scopes, client binding, and lifetime constraints. If the application is represented as an actor through a delegated Token Exchange, then that case is already within the draft's scope. The draft would benefit from concrete examples of step-by-step delegation and how the profile is used and by whom. [Larry Zhu] Section 7 contains a multi-hop example covering an A -> B -> C call chain. Service B is the acting client that uses the profile: it authenticates to the authorization server, presents the access token addressed to B as the subject_token, exchanges it for a Service C access token, and requests a refresh token for asynchronous continuation. Later, B uses the refresh-token grant to continue the task. Draft -05 now explicitly defines the access token addressed to B as the delegation handle and uses that term in the profile overview and the example. It also explains the audience and sender-constraint checks that apply when B presents the handle. Client-initiated delegated Token Exchange: the client performs the Token Exchange before providing the resulting token to the actor. In the Token Exchange request, the client provides a subject_token and an actor_token. The resulting token includes the act claim for the actor, and the client securely provisions this token to the actor. How does the client obtain the actor token, and how can the token be sender-constrained to the actor without compromising the actor's keys? [Larry Zhu] That is not the pattern on which the draft focuses. The draft uses an actor-initiated exchange: the workload that will perform and continue the task authenticates directly to the authorization server and receives a refresh token bound to its own client identity and actor identity. In our experience, having A perform the exchange and provision the resulting credentials to B creates tighter coupling between the services and complicates credential binding, key ownership, rotation, and independent lifecycle management. Also, an actor_token is distinct from a private_key_jwt used for client authentication. Under this profile, the current actor is normally derived from the authenticated acting client. If an actor_token is supplied, its identity must match that client or an identity securely mapped to it. Actor-initiated delegated Token Exchange: the client calls the actor using an access token, and the actor performs Token Exchange using that token as the subject_token. How does the authorization server ensure that the actor is the legitimate holder of the subject token? One option is for the subject token's audience to identify the actor, which then uses client authentication or an actor token to prove its identity. [Larry Zhu] Yes, this is the pattern used by the draft. Draft -05 defines the access token addressed to Service B as the delegation handle. Its audience identifies B, or a resource-server identity securely mapped to B's OAuth client identity, and it carries the user subject and prior actor chain into the exchange. B authenticates to the authorization server and presents the delegation handle as the subject_token. The authorization server validates the handle and its audience, derives B as the new current actor from B's authenticated client identity, and preserves the prior actor chain from the handle. The delegation handle does not by itself authenticate B. If it is sender-constrained, B must be able to satisfy that sender constraint. Client authentication cannot satisfy a sender constraint bound to a different party, so a token constrained exclusively to A cannot simply be transferred to B and used in this exchange. For both options, I do not see how RFC 7009 revocation will be used. Who calls revocation, and using which token? The delegated actors possess refresh tokens stemming from the original grant. Without a global identifier, how is revocation possible and by whom? [Larry Zhu] Service B, as the acting client, calls the RFC 7009 revocation endpoint using its own client authentication and presents the current refresh token, not the delegation handle or another access token. Revoking that token invalidates the entire refresh-token family, including rotated descendants. This is illustrated in Section 7 and specified in Section 9. The authorization server also maintains internal state linking the family to the original Token Exchange and can revoke it when the underlying authorization or session ends, B's client credentials are revoked, replay is detected, or policy no longer permits continuation. The draft does not expose a global identifier that allows A to revoke a refresh token held by B directly. If cross-client or hierarchical revocation is required, that would need an additional authorization-server mechanism or profile. The draft's core mechanism provides grant-lifetime negotiation and extension. Perhaps this could be profiled using a scope such as OpenID Connect's offline_access, rather than defining new authorization-server metadata and a Token Exchange request parameter. [Larry Zhu] I would not characterize the mechanism as general grant-lifetime negotiation or extension. It provides bounded continuation of an already-authorized delegated task. The authorization server establishes the maximum lifetime and can terminate continuation earlier when policy no longer permits it. I do not think offline_access is sufficient as the protocol signal. It requests offline access in an OpenID Connect Authorization Request, but it does not indicate that the authorization server supports this delegated Token Exchange profile or its requirements for actor-chain preservation, client binding, resource confinement, rotation, revocation, and bounded lifetime. The metadata provides positive discovery of those semantics, while request_refresh_token explicitly requests the additional refresh token in a Token Exchange response. It also avoids using a scope, which normally describes access-token authority, as a protocol-capability signal. Would it be better to use the deferred token response draft when fresh authentication, step-up, or additional approval is required? [Larry Zhu] Deferred token response and this profile address complementary cases. This profile provides non-interactive continuation of an already-authorized task within its existing authority and lifetime bounds. The authorization server re-evaluates policy on every refresh request, but if fresh authentication or approval is required, the refresh request fails. DTR could be used separately to obtain a new authorization decision, particularly when human approval is required. Incorporating that interaction into this refresh-token profile would broaden its scope from bounded continuation to authorization negotiation. Rotation without extending the absolute delegation lifetime defeats the purpose. A long-running task might require the delegation lifetime to be extended, with the authorization server applying policy and obtaining additional approval if necessary. [Larry Zhu] The absolute lifetime is a ceiling established by the authorization server when the delegated refresh token is first issued. Rotation may continue the task up to that deadline, but it cannot move the deadline indefinitely. This prevents repeated rotation from converting a bounded delegation into permanent authority. If the task must continue beyond that ceiling, the client needs a new authorization decision. That could involve DTR or another approval mechanism, but it would create a new authorization rather than silently extend the existing refresh-token family. Why prevent the actor from requesting additional authority? It could request additional authority, and the authorization server could apply policy and use DTR to obtain approval if necessary. [Larry Zhu] Preventing authority expansion is an intentional security boundary. The profile allows an already-authorized task to continue; it does not allow possession of a refresh token to become a basis for obtaining additional resources or scopes. If the actor needs additional authority, it can initiate a new Token Exchange or authorization process. DTR may be appropriate if that process requires asynchronous human approval, but that is separate from continuing the existing authorization. Refresh tokens can also be used as subject tokens in RFC 8693 Token Exchange. Is that an option, or does the profile mandate use of the refresh-token grant? If so, why? [Larry Zhu] RFC 8693 permits a refresh token to be used as a subject_token. This profile nevertheless mandates the RFC 6749 refresh-token grant for continuation. That grant preserves the same acting client, current actor, actor chain, resource bounds, and refresh-token family. Using the refresh token in a new Token Exchange could establish a new exchange, actor relationship, resource, or token family. That use is not prohibited by RFC 8693, but it is outside this profile and does not inherit the continuation guarantees defined here. In the flow defined by this draft, the access token addressed to B is the delegation handle used as the subject_token during the initial delegated exchange; subsequent continuation uses the refresh-token grant. RFC 8693 defines the refresh-token subject-token identifier as urn:ietf:params:oauth:token-type:refresh_token in Section 3<https://www.rfc-editor.org/rfc/rfc8693.html#section-3>. Thanks Yaron. From: Yaron ZEHAVI <[email protected]> Date: Thursday, July 30, 2026 at 11:33 PM To: Larry Zhu <[email protected]>; oauth <[email protected]> Cc: Henrik KROLL <[email protected]>; Grese HYSENI <[email protected]>; Frederik Krogsdal Jacobsen <[email protected]>; Max Gerber <[email protected]> Subject: RE: [OAUTH-WG] Request for Review: Delegated Refresh Tokens for OAuth 2.0 Token Exchange (-04) Dear Larry, I think I understand better and acknowledge the challenge your draft tries to solve. Initially I proposed that the AS determines grant lifetime based on the requested authority, thus support long running tasks. But the dynamic nature of tasks which may require longer time to complete than anticipated, makes it valuable to allow requesting to extend token lifetimes. A few comments on that theme: * Your draft focuses on delegated RFC 8693 Token Exchange, but I think it’s applicable also when the client does not delegate to other actors. For example the user asked an application to do something which requires more time, meanwhile the user is offline. * Regarding delegated flows, I think the draft would benefit from concrete examples of step-by-step delegation and how the proposed token exchange profile is used and by whom. * I’m raising this point because I encountered some questions when thinking about the draft, regarding how delegation works in general and how it reconciles other security concerns and mechanisms. This impacts how the mechanism proposed in the draft will be used. I see 2 options for how an actor is delegated work, perhaps there are more: * Client-initiated delegated token exchange: * The client performs the token exchange before providing the resulting token to the actor. In the token exchange request client provides subject_token and actor token. The resulting token includes the act claim for the actor (e.g., a worker or agent). The client securely provisions this token to the actor, which then uses it to act. * Challenges arise when client and actor are separate systems: * How does the client obtain an actor_token? Considering such tokens are not just strings but private key JWTs or another token securely identifying the actor? * How to sender-constrain client-issued tokens to be used by actor, without compromising keys that should be under the sole control of the actor? * Actor-initiated delegated token exchange: * Client calls the actor using an access token. * Actor performs token exchange, presenting the subject_token it received from the client and an actor_token it issues. * The challenge here is when the subject_token is sender constrained to the client and not to the actor. How does the AS ensure the actor is the legitimate holder of the token? * One way could be audience restriction – the subject_token’s audience could explicitly name the actor, who then uses client authentication or actor_token to prove the request is coming from subject_token’s audience. * For both of these options, I don’t see how RFC 7009 token revocation will be used. Can you please explain, who would call the revocation and using which token? The challenge I see is that delegated actors will obtain refresh tokens which stem from an original grant but only they possess them. Without some global identifier, how is revocation possible and by whom? * Delegation concerns set aside, the draft’s core mechanism provides grant lifetime negotiation and extension. In this framing: * I’m not sure new AS metadata and token exchange request parameter are needed. Perhaps this could be profiled on a scope, such as OpenID’s “offline_access” to signal wish to extend grant lifetime. * You write “If current authorization-server policy requires fresh user authentication, step-up, or additional approval for a requested resource or operation, the refresh request must fail”. But perhaps it would be better to use in such cases the deferred token response draft? This would allow human-in-the loop decisions when new tasks are spawned or when task is extended. This is especially valuable in long-running offline tasks as the user’s original intent or mission may no longer be relevant and should therefore be terminated. * You write “refresh-token rotation without extending the absolute delegation lifetime” I think that defeats the draft’s purpose. If the user’s task requires long running offline processing, the delegation lifetime may need to be extended. This is okay so long as the authorization server is engaged whenever extending is required, can apply policies and reach out to the user or other approvers for consent. * You write “allows an already-authorized task to continue without expanding its authority”. Why limit the scope of the draft? Imagine a delegated actor needs additional authority, it can request it and AS may employ policies and if necessary, use DTR to asynchronously obtain approval. * You write in the draft “the same acting client uses the RFC 6749 refresh token grant”. Refresh tokens can also be used as subject tokens for rfc 8693 token exchange. Is this also an option in your view or do you mandate using the refresh token grant only? If so, why? Yaron Classification: GENERAL From: Larry Zhu <[email protected]> Sent: Friday, July 24, 2026 11:27 AM To: oauth <[email protected]> Subject: [OAUTH-WG] Request for Review: Delegated Refresh Tokens for OAuth 2.0 Token Exchange (-04) This message is from an external sender - be cautious, particularly with links and attachments. Hi OAuth WG, We have published draft-zhu-oauth-async-delegation-04, which is the reviewable version of the proposal. I also ran into Yaron in the hallway here in Vienna and gave him a quick heads-up on the current design. I would like to thank Arndt Schwenkschuster for his valuable feedback. In particular, his observation that RFC 8693 already permits refresh-token issuance for offline Token Exchange scenarios helped us frame this work as a profile of existing refresh tokens rather than a new continuation credential. The draft addresses a specific interoperability gap: although RFC 8693 permits an authorization server to return a refresh token from Token Exchange, it does not define how delegated authorization state—particularly the subject, complete actor chain, client binding, permitted resources, and scope restrictions—is preserved and enforced when that refresh token is subsequently used. The proposal profiles an RFC 8693-issued refresh token for asynchronous and long-running delegated workflows. In brief, it defines: * RFC 8414 authorization-server metadata for discovering support for the profile; * an explicit Token Exchange request signal for requesting delegated asynchronous continuation; * preservation of the original subject and complete actor chain; * binding of the refresh token to the acting client and current actor; * confinement to the originally authorized resources; * scope that can remain unchanged or narrow, but cannot expand; * authorization re-evaluation on every refresh; * refresh-token rotation without extending the absolute delegation lifetime; and * a one-to-one association between a refresh-token family and an asynchronous task, with RFC 7009 revocation when the task completes, is cancelled, or otherwise reaches a terminal state. Step-up authentication and new user authorization remain separate concerns. This profile allows an already-authorized task to continue without expanding its authority; it does not allow a refresh token to bypass authentication-context or step-up requirements. If current authorization-server policy requires fresh user authentication, step-up, or additional approval for a requested resource or operation, the refresh request must fail and that requirement must be satisfied through an appropriate, separate interaction. The profile uses the existing refresh_token response parameter, refresh-token grant, and resource parameter. It defines no new token format, token type, grant type, or token-response parameter. It also does not make refresh tokens portable across authorization servers; each refresh token remains bound to and usable only at its issuing authorization server. Under the clustering proposal presented at IETF 126, we suggest categorizing the draft as follows: Requested cluster: Same-Domain Chaining Related clusters: Token Lifecycle and Discovery We would greatly appreciate review of -04, particularly on: 1. Whether the interoperability gap is clear and sufficiently narrow. 2. Whether profiling RFC 8693-issued refresh tokens is the right approach. 3. Whether the discovery and request signals are appropriate. 4. Whether the subject and actor preservation, resource and scope confinement, bounded lifetime, rotation, authorization re-evaluation, and task-scoped revocation requirements are complete and implementable. 5. Whether the boundary between delegated continuation and separate step-up or user-authorization mechanisms is sufficiently clear. 6. Whether any part of this work should instead be incorporated into an existing OAuth specification. Draft -04: https://www.ietf.org/archive/id/draft-zhu-oauth-async-delegation-04.html Datatracker: https://datatracker.ietf.org/doc/draft-zhu-oauth-async-delegation/ Thank you, Larry Zhu This message and any attachment ("the Message") are confidential. If you have received the Message in error, please notify the sender immediately and delete the Message from your system, any use of the Message is forbidden. Correspondence via e-mail is primarily for information purposes. RBI neither makes nor accepts legally binding statements via e-mail unless explicitly agreed otherwise. Information pursuant to § 14 Austrian Companies Code: Raiffeisen Bank International AG; Registered Office: Am Stadtpark 9, 1030 Vienna, Austria; Company Register Number: FN 122119m at the Commercial Court of Vienna (Handelsgericht Wien).
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
