> I'm not convinced that authorization_expires_in solves a real problem - what is the client supposed to do with this information?
I think the naming can be debated some more, but the two pieces of metadata give clients different pieces of information regarding refresh token expiry. - refresh_token_timeout is the time the client has to use the current refresh token before it expires, which will be shorter for clients that need to periodically rotate tokens. Some ASs also require refresh tokens to be used every X days to remain active. - authorization_expires_in is the total time the client has to use all refresh tokens that could originate from this grant, since some ASs place an additional total maximum lifetime requirement on the grant itself For example, if my AS requires a refresh token to be used once a month up to a maximum of 1 year, then the AS will return a refresh_token_timeout of 1 month and authorization_expires_in of 1 year, and the client can schedule background token rotation jobs as necessary. The client can also schedule a notification to the user to renew the grant in 11 months. On Fri, Nov 14, 2025 at 4:24 AM Neil Madden <[email protected]> wrote: > I support adoption. The refresh token expiry indication seems reasonable. > I'm not convinced that authorization_expires_in solves a real problem - > what is the client supposed to do with this information? > > -- Neil > > > On 13 Nov 2025, at 20:02, Rifaat Shekh-Yusef via Datatracker < > [email protected]> wrote: > > > > > > Subject: Call for adoption: > draft-watson-oauth-refresh-token-expiration-01 > > (Ends 2025-11-27) > > > > This message starts a 2-week Call for Adoption for this document. > > > > Abstract: > > This specification extends OAuth 2.0 [RFC6749] by adding new token > > endpoint response parameters to specify refresh token expiration and > > user authorization expiration. > > > > File can be retrieved from: > > > https://datatracker.ietf.org/doc/draft-watson-oauth-refresh-token-expiration/ > > > > Please reply to this message keeping [email protected] in copy by > indicating > > whether you support or not the adoption of this draft as a WG document. > > Comments to motivate your preference are highly appreciated. > > > > Authors, and WG participants in general, are reminded of the Intellectual > > Property Rights (IPR) disclosure obligations described in BCP 79 [2]. > > Appropriate IPR disclosures required for full conformance with the > provisions > > of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any. > > Sanctions available for application to violators of IETF IPR Policy can > be > > found at [3]. > > > > Thank you. > > [1] https://datatracker.ietf.org/doc/bcp78/ > > [2] https://datatracker.ietf.org/doc/bcp79/ > > [3] https://datatracker.ietf.org/doc/rfc6701/ > > > > > > > > _______________________________________________ > > OAuth mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > > _______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
