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]
