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

[Larry Zhu <[e-mail]>]

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