Dick included the browser-swapping attack in the thread, so I interpreted “Do people agree there is a problem to be solved?” in the context of that attack.
The Browser-Based Apps BCP’s model for authorization-code interception is essentially that PKCE makes an intercepted code unusable to an attacker: the code is bound to the PKCE challenge, and only the client instance that initiated the flow has the verifier. Browser swapping exposes a case that falls outside that model. There are two browser contexts: the victim’s browser, where the victim authenticates to the authorization server, and the attacker’s browser, where the attacker wants the resulting application session. The attacker initiates the OAuth transaction, including the PKCE challenge, and gets the victim to authenticate as part of that flow. The resulting code represents the victim’s authorization. If the attacker can obtain that code from the authorization response and use it to complete the transaction in their browser, the legitimate client performs the token exchange with the correct PKCE verifier and establishes the victim’s application session in the attacker’s browser. So PKCE is doing exactly what the BCP says: the attacker cannot take the code and redeem it themselves. But they don’t need to; the legitimate client redeems it. state similarly provides transaction/CSRF correlation, not continuity of the browser that performed the authorization. What appears to be missing from the current model is a binding between the browser context in which the user authenticated/authorized and the browser context in which the resulting application session is established. Authorization-code exfiltration matters here because the code can become the mechanism for crossing that boundary even though PKCE and state are both working as intended. That was what I understood the “problem to be solved” to mean, rather than agreement on any particular solution. -Karl On Tue, Sep 22, 2026 at 9:19 AM Dick Hardt <[email protected]> wrote: > Hi Emilia > > The poll text was "Do people agree there is a problem to be solved" > > https://datatracker.ietf.org/doc/polls-interim-2026-oauth-05-202609211300/ > > Slide 4 of the presentation was presented during the poll. > > The poll was not adoption of the draft by the WG. > > /Dick > > On Tue, Sep 22, 2026 at 5:02 PM Emelia S. <[email protected]> wrote: > >> Hi Dick, >> >> My interpretation from yesterday was that we were asked "Do we want to >> adopt this specific solution" and the answer was "no, because it's unclear >> if this actually solves the problem or not based on reading the draft text >> alone" >> >> There's no clear definition of the problem, therefore there can't be a >> solution, yet. >> >> — Emelia >> >> On 22 Sep 2026, at 17:05, Dick Hardt <[email protected]> wrote: >> >> Hey >> >> >> At the September 21 interim [1], the chairs asked if there authorization >> code exfiltration is a problem to be solved. 3 said yes, 5 said no. >> >> >> The authorization code is a credential that we deliver in the redirect >> URL. From there it can be exfiltrated through history, logs, Referer, page >> JavaScript and extensions. Based on the Browser-Swapping thread [2] and the >> support for Redirect Headers in December [3], I had thought there was >> consensus that this is a problem. >> >> >> Do you think exfiltration of the authorization code is a problem this WG >> should solve? >> >> >> /Dick >> >> >> [1] >> https://datatracker.ietf.org/meeting/interim-2026-oauth-05/session/oauth >> >> [2] >> https://mailarchive.ietf.org/arch/msg/oauth/K8Wnw08GzPstyAQAh0JmSB47pOQ/ >> >> [3] >> https://mailarchive.ietf.org/arch/msg/oauth/FFkUlOiz7I4K03pqjMfIFkxAwA8/ >> _______________________________________________ >> OAuth mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> >> >> _______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
