Since 12.2. Successful Refresh Response says
If an ID Token is returned as a result of a token refresh request, the following requirements apply:
...
...
...
otherwise, the same rules apply as apply when issuing an ID Token at the time of the original authentication.
- It's not always required to issue an ID Token
- the
cnf claim should appear in ID tokens issued as a result of a refresh token grant too (asumming it's not downscoping w/o the "dpop" scope).
I think this interaction is problematic because only for public clients (for which the RT is bound to the initial request's DPoP private key) is the resulting cnf in the ID Token bound to always remain the same since confidential clients can rotate their dpop private keys at will when it comes to use with refresh tokens.
So the questions are - when a refresh token grant is used
- should this this interaction be profiled in this extension, i.e. require that refresh token grants do issue an ID Token if the scope (original or downscoped) includes "dpop"?
- the cnf in refresh token interactions MAY not be the same during refresh, is that okay?
Since 12.2. Successful Refresh Response says
cnfclaim should appear in ID tokens issued as a result of a refresh token grant too (asumming it's not downscoping w/o the "dpop" scope).I think this interaction is problematic because only for public clients (for which the RT is bound to the initial request's DPoP private key) is the resulting
cnfin the ID Token bound to always remain the same since confidential clients can rotate their dpop private keys at will when it comes to use with refresh tokens.So the questions are - when a refresh token grant is used