Yes.
The root problem isn’t the mix-use of PKCE and nonce, it’s PKCE implementation
bug.
Yeah, all PKCE implementation MUST reject such requests, regardless it’s OAuth
2.1 or 2.0.
(and it’s probably because of PKCE spec’s ambiguity..)
> 2020/05/20 1:13、Mike Jones のメール:
>
> So it sounds me lik
So it sounds me like the fix is to have servers reject PKCE requests with
incomplete parameter sets: requests that only contains one of code_challenge
and code_verified. Will that eliminate the attack, Nov?
-- Mike
From: OAuth On Behalf O
This is a RE: to yesterday's interim meeting discussion, largely related to
the first rollout step where we want to constrain refresh tokens but leave
protected resource access intact.
I'll start off with a case that I hope we can agree is absolutely necessary
for DPoP to solve - that is constrain
Hi,
This has been brought up before - but no response.
Either I can’t find it - or it is missing. But is the setting the JWT typ
explicitly mentioned somewhere?
I think it should to prevent cross JWT confusion.
Thanks
———
Dominick Baier
___
OAuth mail
Hi Filip,
I have uploaded the slides to the materials page here:
https://datatracker.ietf.org/meeting/interim-2020-oauth-09/materials/slides-interim-2020-oauth-09-sessa-dpop
Regards,
Rifaat
On Tue, May 19, 2020 at 5:39 AM Filip Skokan wrote:
> Hello Brian,
>
> can you share the slide deck f
Hello Brian,
can you share the slide deck from yesterday so that we may continue
the discussion on the mentioned open questions here on the list?
Thank you,
Best,
*Filip*
On Wed, 13 May 2020 at 20:43, Brian Campbell wrote:
> Just wanted to note that there is a newer -01 revision of the docum
