Brian, Neil, thanks for the answers, Now if we consider Token endpoint instead of UserInfo, in your opinion, what should take priority in case both DPoP proof and provided credentials are invalid? Should it be "invalid_grant" or "invalid_dpop_proof"?
The DPoP draft says: To sender-constrain the access token, *after* checking the validity of the > DPoP proof, the authorization server associates the issued access token > with the public key from the DPoP proof > But it doesn't specify whether the credentials should be validated before or after DPoP proof validation. - Dmitry On Wed, Oct 27, 2021 at 6:24 PM Neil Madden <[email protected]> wrote: > 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 < > [email protected]> wrote: > > It's really just an implementation choice, I think. > > On Wed, Oct 27, 2021 at 7:17 AM Dmitry Telegin <dmitryt= > [email protected]> 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 <[email protected]> >> 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 >> [email protected] >> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > > >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
