Hi Brock :) The term "credential rotation" there was meant (to me anyway when writing the text) to refer to the client authentication credential - meaning the client config/metadata about its authentication credentials can be updated without invalidating the RT (as is the case already in 'plain' OAuth). However, to the point of your question, the sentiment also applies to the DPoP key - not binding the RT to the DPoP key for confidential clients does allow for a new DPoP proof to be used for new access tokens requested from the same refresh token.
On Wed, Mar 1, 2023 at 7:51 AM Brock Allen <brockal...@gmail.com> wrote: > Hi -- another DPoP question :) > > In the very last paragraph, in the very last sentence of section "5. DPoP > Access Token Request", draft-ietf-oauth-dpop-13 says: > > "This existing sender-constraining mechanism is more flexible (e.g., it > allows credential rotation for the client without invalidating refresh > tokens) than binding directly to a particular public key." > > Can someone clarify if the term "credential rotation" refers to the > client authentication credential, or the PPoP credential? > > I'm pretty sure it means the PPoP credential, since that would allow for > a new DPoP proof to be used for new access tokens generated from the same > refresh token. Is this correct? > > Thanks, as always! > > -Brock > > _______________________________________________ > OAuth mailing list > 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
