Subject: Re: [OAUTH-WG] [DPoP] Order of validation for DPoP proofs and access tokens

From: Dmitry Telegin <[email-masked]>
Date: Wed, 27 Oct 2021 16:16:31 +0300

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-masked]> 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
>
>
>
>

---

From: Brian Campbell <[email-masked]>
Date: Wed, 27 Oct 2021 09:20:19 -0600

It's really just an implementation choice, I think.

On Wed, Oct 27, 2021 at 7:17 AM Dmitry Telegin <dmitryt=
[email-masked]> wrote:

>> _______________________________________________
> OAuth mailing list
> [email-masked]
> 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._

---

From: Neil Madden <[email-masked]>
Date: Wed, 27 Oct 2021 16:24:12 +0100

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=[email-masked]> wrote:
> 
> On Wed, Oct 27, 2021 at 7:17 AM Dmitry Telegin <dmitryt=[email-masked] <mailto:[email-masked]>> 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-masked] <mailto:[email-masked]>> 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
> 
> 
> 
> [email-masked] <mailto:[email-masked]>
> 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
> [email-masked]