Code change:
The "Refresh token binding" section requires "The client MUST also use the same Client Attestation." What is the intention of the requirement from the following options? The exactly same client attestation JWT. The refresh token becomes invalid after the client attestation JWT expires. Even if the attester issues a new client attestation JWT for the same client key, the new client attestation JWT would not work with the refresh token. If the requirement expects this behavior, AS implementations would simply use the hash of the client attestation JWT to judge whether the client attestation JWT presented in the refresh token flow is identical to the previous one. Any client attestation JWT for the same client key issued by the same attester. If this is the actual intention of the requirement, even after the original client attestation JWT expires, the refresh token can be used with a new client attestation JWT issued by the same attester. In this case, AS implementations would check the combination of the attester's identifier and the client key during the refresh token flow. Any client attestation JWT for the same client key issued by any attester the AS trusts. If this is the actual intention of the requirement, even after the original client attestation JWT expires and/or even after the attester ceases its service, the refresh token can be used with a new client attestation issued by any attester the AS trusts. In this case, AS implementations would check the JWK thumbprint of the client key only during the refresh token flow and would not check whether the attester is identical to the one of the previous client attestation JWT. FYI: defines a mechanism to bind an X.509 certificate to an access token. The specification states that a JWT access token should include (which represents the SHA-256 thumprint of an X.509 certificate) in its payload if the access token is bound to a certain X.509 certificate. It results in that certificate-bound access tokens and refresh tokens expire when their X.509 certificates expire and that renewing X.509 certificates for the same subject does NOT revive the access tokens and refresh tokens. Therefore, client applications have to go through an authorization flow again to get a new access token once the X.509 certificate bound to the previous access token expires. There are pros and cons. The requirement will need to be rephrased depending on what the "refresh token binding" wants to achieve.
Yeah, the statement "The client MUST also use the same Client Attestation that was used for authentication when the refresh token was issued." is problematic and needs to be removed or rephrased. The intent, as I understand it from previously discussing/pushing the issue of RT binding for this draft, is that the RT needs to be bound to the client instance. And that means binding the RT to the client instance's key. I think Tobias didn't want to go so far as saying that b/c he thought it was too inflexible. But the client instance's key is currently the only thing here that uniquely identifies the client instance.
NAME is correct around the intent here, I agree the wording makes it unclear so it should be clarified that the binding is to the client instance key used when the RT was issued.
Why not just use the same client attestation JWT? That would not require any client instance identification and is also not a privacy issue. urn:ietf:params:oauth:client-assertion-type:jwt-key-attestation -> urn:ietf:params:oauth:client-assertion-type:jwt-client-attestation Originally posted by NAME in URL
Related to . The problem with this model is that the refresh token if bound to the client attestation JWT then limits the RT lifetime.

Related discussion:
text: instance MUST authenticate itself to the authorization server when refreshing an access token using the "urn:ietf:params:oauth:client- assertion-type:jwt-client-attestation" authentication method.  The <del> client MUST also use the same Client Attestation that was used for authentication when the refresh token was issued. </del> <ins> client MUST also use the same key that was present in the "cnf" claim of the client attestation that was used for client authentication when the refresh token was issued. </ins> 6.