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 <[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]
