[OAUTH-WG] Re: Request for Review: Delegated Refresh Tokens for OAuth 2.0 Token Exchange (-04)

[Thi Nguyen-Huu <[e-mail]>]

Hi Yaron,

To your question, 8693 anticipated something close to your construction: may_act in §4.4 lets the subject token name the party eligible to act for the subject. You got there through the audience claim instead. What CIMD adds is the part 8693 left out - how the AS learns the keys of an actor it never enrolled.

Which is most of the answer to your mystery, I think. Read 8693 as assuming pre-registration. The actor is an OAuth client, known to the AS, authenticating the ordinary way: client_secret, private_key_jwt from RFC 7523 in 2015, or mTLS from RFC 8705, published a month after 8693. Inside one administrative domain with a handful of enrolled services, that is interoperable and secure enough. Delegation was between things you had deployed yourself. This is me reading the RFC's assumptions rather than claiming to know what its authors intended.

So what was added is the population. An actor used to be a service you enrolled. Now it is an instance that may not exist tomorrow, and pre-registration does not reach it. Hence CIMD.

One thing your construction gives you that you did not claim for it: a stable actor identifier. If the actor is https://agents.acme.com/booking_agent, the AS can revoke by actor instead of hunting for token families. That answers part of my earlier point better than I gave you credit for.

What still isn't reached is the question underneath: is this the authentic actor, on the authorized platform, with its conditions still holding, right at this moment? I understand in OAuth vocabulary identity is treated as the actor. We take it to be the actor, the platform, and the conditions together - one identity, not three checks. The platform's software builds the credential from all three; that is what we call a condition-bound credential.

That is the gap our work addresses. The credential stops working when any one of the three fails - no message to deliver, nothing for the user to do. I'll write it up for the delegated case; happy to go into it here if it's useful to your review.

Cheers

Thi Nguyen-Huu

From: Yaron ZEHAVI <yaron.zehavi=[e-mail]>
Sent: Friday, July 31, 2026 1:57 PM
To: Thi Nguyen-Huu <[e-mail]>; Larry Zhu <[e-mail]>; oauth <[e-mail]>
Cc: Henrik KROLL <[e-mail]>; Grese HYSENI <[e-mail]>; Frederik Krogsdal Jacobsen <[e-mail]>
Subject: RE: [OAUTH-WG] Re: Request for Review: Delegated Refresh Tokens for OAuth 2.0 Token Exchange (-04)

CAUTION:This email originated from outside of the organization. Do not click links, open attachments or respond unless you recognize the sender and know that the content is safe.

Dear Thi,
Thanks for your detailed response.

I'm no expert on delegation, was rather trying to work it out step by step, to understand and review Larry's draft.
However, I think with actor-initiated delegated token exchange an AS can ensure the request is coming from a legitimate holder:

  *   If the token is audienced to the actor, e.g "aud": "https://agents.acme.com/booking_agent"
  *   And the actor uses CIMD with a published jwks or jwks_uri and provides a signed actor_token or client_assertion with client identifier matching token's aud claim ("https://agents.acme.com/booking_agent")
  *   Then AS can validate the call is coming from the token's audience

But there's a mystery here...
Since RFC 8693 supported delegation flows since 2020 but DPoP came out in 2023 and CIMD is still in draft status...
How did those who envisioned token exchange for delegation intended it to work interoperably and securely?

Regards,
Yaron



Classification: GENERAL
From: Thi Nguyen-Huu <thi.nh=[e-mail]<mailto:thi.nh=[e-mail]>>
Sent: Friday, July 31, 2026 1:01 PM
To: Yaron ZEHAVI <[e-mail]<mailto:[e-mail]>>; Larry Zhu <[e-mail]<mailto:[e-mail]>>; oauth <[e-mail]<mailto:[e-mail]>>
Cc: Henrik KROLL <[e-mail]<mailto:[e-mail]>>; Grese HYSENI <[e-mail]<mailto:[e-mail]>>; Frederik Krogsdal Jacobsen <[e-mail]<mailto:[e-mail]>>
Subject: RE: [OAUTH-WG] Re: 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.

Yaron, Larry,
I described this key in the Call for topics thread on 19 July, and on 15 July, in the agent-authorization use-cases thread, pointed at your exchange as the live form of the lifetime problem. In short, and as a property of the client key under DPoP or 8705 rather than a new way of proving possession: the key carries the user verification and the device conditions, requires no user interaction at the moment of use, and exists only while those conditions hold - when they lapse it is gone, so nothing has to expire and no message has to be sent.

Yaron's revocation question is the part I have not covered, and it is Larry's review question 4 as well. Larry, your draft gives the AS a refresh-token family to revoke and a terminal state to revoke it in, and that works at the next refresh. Between refreshes there is nothing. The actor holds a credential whose validity is a matter of record at the authorization server, not of anything observable where the action is actually running. Yaron's question is the same point from the other side: the token sits in the actor's sole possession, so the party who would want it stopped is not the party holding it, and has no identifier for it.

Yaron, both of your delegation options break in the same place. Client-initiated needs something standing in for the actor's key, and a key under the actor's sole control is exactly what cannot be handed over. Actor-initiated leaves the AS unable to tell that the presenter is the legitimate holder. What is being transferred is authority; what should be transferred is permission to mint.
Mint consumes the user's approval once, and the actor's key is built at that moment. The actor then exercises it per use with no user involved, which covers the long-running offline case in your first bullet. Any one condition failing erases it. (Mint / exercise / erase is Morgan LR's naming, from the WIMSE discussion.)

Revocation then has nothing to look for, and nothing to wait for. The user stops the task, or logs out, or the device leaves an allowed posture: the key is erased where it lives, every access depending on it ends at that moment, and no message is in transit to go stale. An externally decided revocation is one signal to one platform instead of notifications to every relying party holding state, and an offline endpoint fails closed. What it does not cover is a bearer token already issued, which runs to its expiry - where a short lifetime still earns its keep.

This is also why the extension disagreement in this thread need not be settled on lifetime terms. Subject, actor, audience and scope stay with the authorization server at every refresh, exactly as you have them, Larry; what moves off the timer is whether the actor's standing survived the interval.

draft-winmagic-wimse-condition-bounded-credentials has the detail. If it helps the draft, I can write up the delegated case.

Thi Nguyen-Huu
WinMagic

From: Yaron ZEHAVI <yaron.zehavi=[e-mail]<mailto:yaron.zehavi=[e-mail]>>
Sent: Friday, July 31, 2026 2:33 AM
To: Larry Zhu <lzhu3=[e-mail]<mailto:lzhu3=[e-mail]>>; oauth <[e-mail]<mailto:[e-mail]>>
Cc: Henrik KROLL <[e-mail]<mailto:[e-mail]>>; Grese HYSENI <[e-mail]<mailto:[e-mail]>>; Frederik Krogsdal Jacobsen <[e-mail]<mailto:[e-mail]>>
Subject: [OAUTH-WG] Re: Request for Review: Delegated Refresh Tokens for OAuth 2.0 Token Exchange (-04)

You don't often get email from yaron.zehavi=[e-mail]<mailto:yaron.zehavi=[e-mail]>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>
CAUTION:This email originated from outside of the organization. Do not click links, open attachments or respond unless you recognize the sender and know that the content is safe.

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 <lzhu3=[e-mail]<mailto:lzhu3=[e-mail]>>
Sent: Friday, July 24, 2026 11:27 AM
To: oauth <[e-mail]<mailto:[e-mail]>>
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).
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).