Refresh Token Rotation #574
Labels
issuance
security
standardization
Topics related to the standardization process in IETF/OIDF
wontfix
This will not be worked on
As @Sh-Amir pointed out, in our case, using a Refresh Token Rotation mechanism adds no benefits in terms of security.
In fact, Note1 of Section 5.3.2.1 of FAPI 2.0 Security Profile — Draft 04 states:
The use of refresh token rotation does not provide security benefits when used with confidential clients and sender-constrained access tokens. This specification prohibits the use of refresh token rotation for security reasons as it causes user experience degradation and operational issues whenever the client fails to store or receive the new refresh token and has no option to retry.
A confidential client is a client that can perform a client authentication. In our context, a Wallet Instance is able to authenticate to CI using its Wallet Attestation according to OAuth 2.0 Attestation-Based Client Authentication. The abstract of this specification states:
[...]This new method enables Client Instances involved in a client deployment that is traditionally viewed as a public client, to be able to utilize this key-bound attestation to authenticate.
So we think that Note 1 in FAPI applies to our context, making the token rotation no longer needed.
We changed PR #566 accordingly.
@peppelinux @giadas @m-basili ^^^
The text was updated successfully, but these errors were encountered: