As usual, one thing led to another and I didn't actually make any updates until the draft deadline forced my hand. :)
I believe I've addressed your comments in the latest draft <https://datatracker.ietf.org/doc/draft-ietf-oauth-refresh-token-expiration>, as well as George Fletcher's. I won't be able to attend the meeting in Shenzhen, but I've asked Rifaat for an interim. In the meantime, I'd love a few more reviews from people on the list! Nick On Fri, Jan 9, 2026 at 4:48 PM Nick Watson <[email protected]> wrote: > Hi Dan, thanks for the review! You're correct it hasn't changed between > adoption. Comments in line. > > I will likely incorporate your suggestions and George's next week, and > then update the list. > > On Thu, Jan 8, 2026 at 4:41 PM Dan Moore <dan= > [email protected]> wrote: > >> Hi folks, >> >> Reviewed this draft when it was >> https://datatracker.ietf.org/doc/draft-watson-oauth-refresh-token-expiration/ >> but my understanding is that nothing changed between the documents. >> >> Comments. >> >> Section 6.1: >> >> "If finite, the authorization server" >> >> ... is that another way of saying this RFC is optional? >> > > Well all RFCs are optional I guess. :) But "if finite" means that even > spec implementers can still have tokens without expiration. They're only > obligated to return a value if the refresh token expires. > >> >> how do you typically say "if this rfc is implemented?" >> >> Section 6.1.2 >> >> I find the term "Infinite Expiration" a bit confusing. Maybe >> Non-Expiring, Indefinite or Perpetual would be clearer? >> > > I like "indefinite" as it goes nicely with the concept of manual user > revocation – indefinite but can still be invalidated through other means. > I'll update the wording similarly to your suggestion. > >> >> So the section title could be changed to "Indefinite Expiration" >> >> and >> >> omitted response fields could indicate >> either indefinite validity or simply lack of support for this >> specification. However, infinite expiration and lack of information >> about expiration should be handled by the client in the same way. >> That is to say, the client must always handle refresh token >> invalidation not caused by expiration, such as by explicit user >> revocation. >> >> becomes >> omitted response fields could indicate >> either perpetual refresh token validity or simply lack of support for >> this >> specification. However, lack of expiration and lack of information >> about expiration should be handled by the client in the same way. >> That is to say, the client must always handle refresh token >> invalidation not caused by expiration, such as by explicit user >> revocation. >> >> Section 6.3 >> >> Would it be more precise to change "An exchange" to "A refresh token >> grant" throughout the examples? >> > > Maybe I can just use "a refresh"? "Refresh token grant" always sounds odd > to me as my ear hears it more like "granting a refresh token". Maybe others > have thoughts here? > >> >> What if a refresh token has expired but we are within the authorization >> window? That might be a good example to add. >> > > Will do. It must be rejected by the AS if presented. > >> >> Section 7 >> >> I didn't understand refresh_token_expiration_types_supported and the >> different types of expiration offered. What is the difference between >> expiration of type "credential" vs type "authorization"? >> > > Definitely open to better names here, but those correspond to support for > the refresh_token_timeout and authorization_expires_in parameters, > respectively. > >> >> What did I miss? >> >> Section 9 >> >> I see [OAuth 2.1 Sec 4.3.1] referenced, but it is not in the Normative >> references section. >> >> Or would it be better to point to the published BCP 9700 instead of the >> unpublished OAuth2.1 draft? >> https://www.rfc-editor.org/rfc/rfc9700.html#refresh_token_protection >> talks about refresh token rotation (4.14.2). >> > > I'll point to 9700 until such time as 2.1 is published. > >> >> Thanks, >> Dan >> >> _______________________________________________ >> 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]
