[OAUTH-WG] Certificate-bound refresh tokens and certificate expiration handling in case of the confidential clients

[[e-mail]]

Hi,

I have noticed is that some OAuth2 AS implementations use certificate
thumbprints to bind not only access tokens but also refresh tokens to client
certificates. This happens for both public and confidential clients. As a
result, when the certificate is replaced (e.g., it is about to expire soon),
both access and refresh tokens are drawn unusable. 

While RFC 8705 indeed requires binding refresh token to the certificate in
case of the public clients in Section 4 and Section 7.1, the wording is not
that explicit for the confidential clients. More specifically, Section 7.1
of the RFC 8705 is worded in a way which does not explicitly deny keeping
refresh tokens alive after certificate change: it talks about binding to
client ID, thus binding "indirectly" to the certificate. Also, Section 6.3
requires access tokens to be invalidated after certificate change and
mentions refresh tokens as typical tools for renewing them. 

>From the practical perspective, if the confidential client got a refresh
token for the offline access and sufficient time (e.g., for a month), this
would be quite impractical and not very user-friendly to ask a lot of users
to give consents again when the confidential client wants to upgrade its
certificate. But seems like software vendors did not interpret the RFC that
way.

So, the questions:
1) Is my assumption correct and it will not be a violation of the RFC if
refresh tokens issued to the confidential clients survive certificate change
(e.g., by binding them to Client ID, not the certificate thumbprint)? 
2) If the answer on the 1st question is “yes”, would it be better to provide
more clarification in the section 7.1 to avoid misinterpretations in the
future?

Best Regards,
Mikheil Kapanadze