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
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 natural
It's really just an implementation choice, I think.
On Wed, Oct 27, 2021 at 7:17 AM Dmitry Telegin 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 pr
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_dpo
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/j
