@techreport{zhu-oauth-async-delegation-05,
    number =    {draft-zhu-oauth-async-delegation-05},
    type =      {Internet-Draft},
    institution =   {Internet Engineering Task Force},
    publisher = {Internet Engineering Task Force},
    note =      {Work in Progress},
    url =       {https://datatracker.ietf.org/doc/draft-zhu-oauth-async-delegation/05/},
    author =    {Larry Zhu and Zate Berg},
    title =     {{Delegated Refresh Tokens for OAuth 2.0 Token Exchange}},
    pagetotal = 23,
    year =      2026,
    month =     aug,
    day =       3,
    abstract =  {OAuth 2.0 Token Exchange permits an authorization server to issue a refresh token when a client needs continued access after the original credential is no longer valid. However, RFC 8693 does not define how a refresh token issued by a delegated Token Exchange preserves the subject, actor chain, resource restrictions, or other delegated authorization state. This specification profiles refresh tokens issued by delegated OAuth 2.0 Token Exchange for asynchronous and long-running workflows. It defines authorization-server metadata advertising profile support and a Token Exchange request signal by which a client requests delegated continuation, together with preservation of subject and actor relationships, client and actor binding, resource confinement, scope monotonicity, authorization re-evaluation, rotation, task-scoped revocation, and a bounded delegation lifetime. The common discovery signal, request signal, and semantics enable autonomous agents and other product components to interoperate with independently implemented authorization servers across trust domains. Because a client generally cannot determine the effective lifetime of an opaque refresh token, this profile requires the client to request continuation only for an identified asynchronous task and to promptly revoke the refresh-token family when that task reaches a terminal state. These requirements reduce unnecessary issuance and limit the period in which residual delegated authority can be abused. The profile uses the existing OAuth refresh token response and grant and introduces no new token type or grant type.},
}