Hi Brian, Thanks for the prompt response. We will work with our vendors to get this done according to the RFC.
Best Regards, Mikheil Kapanadze From: Brian Campbell <bcampb...@pingidentity.com> Sent: ხუთშაბათი, 11 აგვისტო, 2022 21:04 To: mikh...@association.ge Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Certificate-bound refresh tokens and certificate expiration handling in case of the confidential clients Hi Mikheil, Your assumption is the correct reading of the RFC. Or the intent of the RFC anyway. For confidential clients, refresh tokens are bound to the client id (not the certificate thumbprint or anything else for that matter). RFCs can't be changed after publication so adding more clarification isn't really possible. On Thu, Aug 11, 2022 at 9:11 AM <mailto:mikh...@association.ge> wrote: 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 _______________________________________________ OAuth mailing list mailto:OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
