I would express a mild preference for “invalid_token” taking priority in this case. It seems pointless for the client to generate a new DPoP proof (in response to invalid_dpop_proof) if they are then going to get an invalid_token on the next request anyway. If they get a new AT they will naturally generate a new proof too as the AT hash will no longer match.
— Neil > On 27 Oct 2021, at 16:20, Brian Campbell > <bcampbell=40pingidentity....@dmarc.ietf.org> wrote: > > It's really just an implementation choice, I think. > > On Wed, Oct 27, 2021 at 7:17 AM Dmitry Telegin > <dmitryt=40backbase....@dmarc.ietf.org > <mailto:40backbase....@dmarc.ietf.org>> wrote: > Any updates on this one? As of -04 we have a clear distinction between > "error=invalid_token" and "error=invalid_dpop_proof", so the question could > be reworded like this: > - if DPoP proof is used in combination with access token, and both are > invalid, which one of the "invalid_token" and "invalid_dpop_proof" should be > signaled? > > Regards, > Dmitry > Backbase > > On Fri, Jul 30, 2021 at 6:37 PM Dmitry Telegin <dmit...@backbase.com > <mailto:dmit...@backbase.com>> wrote: > Hello, > > When DPoP proof is used in conjunction with a token (protected resource > access; token refresh), what should be the order of validation of those? The > draft doesn't mention this, and it's hard to deduce logically which should > come first, since validation is mutual ("ath" DPoP claim vs. "cnf/jkt" token > claim) and there is a sort of circular dependency. Are we going to address > that in the spec, or intentionally leave as unspecified? > > Background: a developer asked me if it's guaranteed that the protected > resource return a 401 in the case of invalid access token; currently, the > answer seems to be "implementation specific". > > Regards, > Dmitry > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > <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
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
