Any updates on this one? The missing certificate case looks more like
"invalid_request" to me:
invalid_request
> The request is missing a required parameter, includes an
> unsupported parameter or parameter value, repeats the same
> parameter, uses more than one method f
This is just my interpretation, but this feels more like invalid token, because
you’re not presenting all of the material required for the token itself. The
DPoP draft has added “invalid_dpop_proof” as an error code, which I think is
even better, but the MTLS draft is missing such an element and
Thanks for the reply. That makes sense.
Given that MTLS is not a draft but rather a proposed standard (RFC 8705),
do you think there is a chance the changes you proposed could land in MTLS
one day?
On Wed, Nov 10, 2021 at 6:24 PM Justin Richer wrote:
> This is just my interpretation, but this f
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
Only if this working group wanted to take up the work of making a new revision
of the standard, but I haven't seen any indication of desire to do that here.
One possibility is for you to propose an update as an individual draft to the
group here.
-Justin
___
