[OAUTH-WG] Re: review of draft-ietf-oauth-refresh-token-expiration-00.txt

[Nick Watson <[e-mail]>]

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=[e-mail]>
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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
>