Dear Larry, I think I understand the use-case you’re addressing but believe it can be solved with existing mechanisms.
Refresh tokens enable splitting a grant’s lifetime into several access tokens of shorter lifetime, and enable authorization servers to re-evaluate the access at refresh time and reject in case the grant has been revoked or in response to other negative signals. DPoP enables sender-constraining of both refresh and access tokens, preventing their misuse. Authorization servers may determine token lifetimes based on the access required, which can be employed to offer longer grant lifetimes when tokens for delegated work as described in the draft are needed, while keeping grant lifetimes shorter for other use cases. If in addition to these, human-in-the-loop approvals are required when the user is no longer online, OpenID Connect CIBA may be used to contact the end-user and request their approval. Why therefore, do you see a need for additional mechanisms? How is the delegation handle you propose different than a refresh token? It’s described attributes: “sender-constrained, audience-locked, scope-frozen” are all provided also by refresh tokens. Regards, Yaron Classification: GENERAL From: Larry Zhu <[email protected]> Sent: Tuesday, July 14, 2026 8:46 AM To: Rifaat Shekh-Yusef <[email protected]>; oauth <[email protected]> Subject: [OAUTH-WG] Re: Call for topics for Vienna You don't often get email from [email protected]<mailto:[email protected]>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> This message is from an external sender - be cautious, particularly with links and attachments. Hi Rifaat, Hannes, and OAuth WG, We would like to request 10+5 minutes of agenda time to present and discuss our new draft, Sender-Constrained Delegation Handle for Asynchronous OAuth 2.0 Identity Chaining<https://datatracker.ietf.org/doc/draft-zhu-oauth-async-delegation/>. The draft extends OAuth 2.0 Token Exchange and OAuth Identity Chaining to support asynchronous, “walk-away” workflows that must continue after the end user has gone offline. It defines a sender-constrained delegation handle that allows an acting client to obtain new short-lived chained access tokens without requiring the user to re-authenticate. We would particularly appreciate feedback on: 1. The problem statement and proposed delegation-handle model. 2. Its relationship to refresh tokens and OAuth Identity Chaining. 3. The proposed security boundaries, including sender constraint, audience and scope restrictions, lifetime and refresh limits, session validity, and revocation. Regards, Larry Zhu From: Rifaat Shekh-Yusef <[email protected]<mailto:[email protected]>> Date: Saturday, June 20, 2026 at 3:43 PM To: oauth <[email protected]<mailto:[email protected]>> Subject: [OAUTH-WG] Call for topics for Vienna All, As per the preliminary agenda, we have two OAuth sessions at: Thursday, 2:00-4:00pm Friday, 9:00-11:00am If you have not done so already, let us know, as soon as possible, if you have a topic that you would like to present and discuss in Vienna. Regards, Rifaat & Hannes 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]
