Re: [OAUTH-WG] DPoP followup I: freshness and coverage of signature

Vladimir Dzhuvinov <vladimir@connect2id.com> Sat, 19 December 2020 06:00 UTC

Return-Path: <vladimir@connect2id.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F4A03A0039 for <oauth@ietfa.amsl.com>; Fri, 18 Dec 2020 22:00:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.884
X-Spam-Level:
X-Spam-Status: No, score=-1.884 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l68wN-HIUREH for <oauth@ietfa.amsl.com>; Fri, 18 Dec 2020 22:00:06 -0800 (PST)
Received: from p3plsmtpa06-04.prod.phx3.secureserver.net (p3plsmtpa06-04.prod.phx3.secureserver.net [173.201.192.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E63813A046A for <oauth@ietf.org>; Fri, 18 Dec 2020 22:00:05 -0800 (PST)
Received: from [192.168.88.250] ([94.155.17.31]) by :SMTPAUTH: with ESMTPSA id qVHek4hBF5yf9qVHfkmzuc; Fri, 18 Dec 2020 23:00:05 -0700
X-CMAE-Analysis: v=2.4 cv=Hsqzp2fS c=1 sm=1 tr=0 ts=5fdd96e5 a=+I3yL00+yDwT8KNLgfs+4A==:117 a=+I3yL00+yDwT8KNLgfs+4A==:17 a=q0rX5H01Qin5IyBaTmIA:9 a=r77TgQKjGQsHNAKrUKIA:9 a=48vgC7mUAAAA:8 a=__SxRlIrAAAA:8 a=yCE9nInwAAAA:8 a=LS6YZpeZAAAA:8 a=8HkmfUwDAAAA:20 a=A1X0JdhQAAAA:8 a=EqWY0wPHZD226Ats2bUA:9 a=7iqzwzIrRm7UjGDk:21 a=9KIajQ8goozNkBwp:21 a=QEXdDO2ut3YA:10 a=gQCgc0Y2fpMQJdUt-vMA:9 a=sU31O2_n6s-T9CWt:21 a=zJjFe_JyFTxJsUlc:21 a=4Kqo9sdD7xrGZDUd:21 a=_W_S_7VecoQA:10 a=D8lnhvtxf0AONpHuB7QA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 a=w1C3t2QeGrPiZgrLijVG:22 a=H5r4HjhRfVyZ-DhAOYba:22 a=n6bEelttlQx3_n4Es6hb:22 a=IRr2vCDBpksuBOXhfkKu:22 a=Df3jFdWbhGDLdZNm0fyq:22
X-SECURESERVER-ACCT: vladimir@connect2id.com
To: Justin Richer <jricher@mit.edu>, Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>
Cc: oauth <oauth@ietf.org>
References: <CA+k3eCSyMWyLYorWH7KY+XR1syAQUi4tQXdUuevKz4Y6xNMheA@mail.gmail.com> <30D5F7BA-EA54-4E40-A2FC-222AA0C9AF8D@lodderstedt.net> <CALAqi_9AH5O6d2W+0UDz83=Csm9BbcU8j6qiRxz5rzLfzm6AQA@mail.gmail.com> <353E4494-2F80-44BC-9267-6FB8B37AA0FE@lodderstedt.net> <CE661132-5D86-4652-B115-E6089E39BC68@pragmaticwebsecurity.com> <1B663AA7-563D-4D25-A408-9ED10FD818AC@forgerock.com> <DE120562-2955-461B-9852-4F0B414B18FA@pragmaticwebsecurity.com> <CA+k3eCTnfYOFmZzu9j5XWbsZUj74f3UG54ZiWtqqyzAqRRj17Q@mail.gmail.com> <EA539A6E-3F9F-4569-95BF-AE3894CE3CA6@pragmaticwebsecurity.com> <CA+k3eCQSbCd0mAu+qFzsm+0runqdLf7GOC27UqR4KoLQGCF44A@mail.gmail.com> <EB24B092-BE32-483C-BE15-DDF2740735B5@pragmaticwebsecurity.com> <CA+k3eCQQO_i=9tzwFX52RyvpAdiRVBgMcubUWS9gpEUNNKA9HA@mail.gmail.com> <4c09c8d4-a7af-9bb9-0f72-9b524f0330d1@connect2id.com> <CA+k3eCQAc92mDHbtg-vf6PX_PY8De2cNAmEhy+S1vvqueSXBUw@mail.gmail.com> <E29477E2-D5D1-4041-A790-7B691C1B338E@mit.edu>
From: Vladimir Dzhuvinov <vladimir@connect2id.com>
Autocrypt: addr=vladimir@connect2id.com; prefer-encrypt=mutual; keydata= mQENBFQZaoEBCACnP2YMDex9fnf+niLglTHGKuoypUSVKPQeKDHHeFQVzhRke+HBEZBwmA9T kZ+kEhyrNqibDPkPYVPmo23tM8mbNcTVQqpmN7NwgMpqkqcAqNsIyBtt09DjWOQVm57A3K+y uXI7SdNErdt79p2xQseOhqSC9+LgWuyh+mZsl2oFD4glFFfKSCMp2jATXrAMeGzigTnW+Xe0 tRzrwFN9zqykKxhUq9oHg1cNvoDtfxgsc9ysVHbxM/PM8o9lgj3YTQwKMBcCFclTqohji7ML fQ08eQo+acKTwC1WRzeLt9PknGt3C4TmvdCl0c1BQTTTNiF96Hu4kbaiBIbsfxJOR8+VABEB AAG0LFZsYWRpbWlyIER6aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5jb20+iQE+BBMB AgAoBQJUGWqBAhsjBQkJZgGABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRAZ0vUyOqri Ql62B/wOO0s2JC/QvO6w9iSsRhCOa/JZi+wO+l01V7eGCQ1cYf1W26Y7iKiUlY4/Kz+cr69D pMtkv3UpDTGejKEfspLUxz5Vo3T4oAKbTtNtVIZL/XxH3/JhJ719Jj4eLoe9/djKkGYTX2O5 bMk8TpO1DDjbIw4r9XKI9ZIk96zlKnZvrg7Ho7oOl0ZIf8AzcvdqZEUogDwyr8uwOU+jIyux mOTthepBzXCNjjBjnc8I1//9YppAIaGJ5nnXelVVD1/dyOszogervzFNANEIOvNvCd9G5u4e s7qkDKWKY7/Lj1tF+tMrDTrOh6JqUKbGNeTUB8DlPvIoNyqHUYfBELdpw1Nd
Organization: Connect2id Ltd.
Message-ID: <0d69d968-16f4-9efb-7ebb-442c1bd1a28f@connect2id.com>
Date: Sat, 19 Dec 2020 08:00:02 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <E29477E2-D5D1-4041-A790-7B691C1B338E@mit.edu>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050301070505010702080606"
X-CMAE-Envelope: MS4xfEJE5LqJ13BvRfmeLLZaaABscE7Acx+2pQ5aKUZzBCK9k4lBlHoLWP30wBQFODbDc/N/IEsFDEuqKxhbHHFdR79V9zD1oWb66ssyUKsysIVXswLvd0rN n9Ptl119Nufdth3fMvxB/Hx6MkovU1uCEYjNral9xlaiRIGnPuXpGtjZSQ6dnBbbBw1qtZPtY1aLxAVz23pAyFsN+ScE0nbyfSOqamWuOYmMWDZBme1RMSl7 vhBH9Xya7XlFNPpGFrzpbY4hde7ltjaSK1Y/Zzx9W+Q=
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/yFxYI8iKf6hOSQB8kD3ZhtnKlx4>
Subject: Re: [OAUTH-WG] DPoP followup I: freshness and coverage of signature
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 19 Dec 2020 06:00:10 -0000

Thank you Justin for this honest account of your experience with DPoP.

To at_hash or not is maybe not solved yet, but at least it's clear
there's little enthusiasm about the OIDC style at_hash :)

Vladimir

On 15/12/2020 18:40, Justin Richer wrote:
> I went and implemented this proposal of including a token hash in both
> an AS (java) and client (javascript) on a system that was already
> using DPoP and OpenID Connect. What I did there was just use the
> existing code we had on the AS-side to calculate the “at_hash” in the
> ID Token from OIDC, which I also used to verify on the token-accepting
> portions. I had to implement the function on the client side, but that
> was only a couple lines using a crypto library to do the heavy hash lift.
>
> The most annoying part is dealing with the hash variability in the
> OIDC method. As Brian points out, this isn’t particularly robust, and
> it depends on the wrapper being JOSE. That’s not a huge deal because
> DPoP uses JOSE for its wrapper, but it’s still extra code to deal with
> — to the point where I just hardcoded the hash algorithm in my test so
> that I didn’t have to put together the switch case over the algorithm. 
>
> So in at least my own experience, the addition is minimal on both
> client and server, and whatever we would decide for the hash algorithm
> would be simple enough to manage. I have a slight preference for just
> picking something like SHA256 and calling it a day (and defining other
> hashes in the future when SHA256 is broken), but that’s not a hill I
> care to die on.
>
>  — Justin
>
>> On Dec 14, 2020, at 4:27 PM, Brian Campbell
>> <bcampbell=40pingidentity.com@dmarc.ietf.org
>> <mailto:bcampbell=40pingidentity.com@dmarc.ietf.org>> wrote:
>>
>>
>>
>> On Sat, Dec 12, 2020 at 1:22 AM Vladimir Dzhuvinov
>> <vladimir@connect2id.com <mailto:vladimir@connect2id.com>> wrote:
>>
>>     If the current DPoP has code complexity "X", the relative
>>     additional complexity to include access token hashes doesn't seem
>>     like very much. An app choosing DPoP means accepting the code
>>     complexity that comes with dealing with keys, composing the
>>     signing inputs for the proofs, signing, the necessary changes to
>>     the token and RS requests. On the other hand, for some people
>>     that additional access token hash may become the straw that
>>     breaks the camel's back, causing them to quit their jobs
>>     developing web apps and never look back :)
>>
>> Yeah, the relative additional complexity to include an access token
>> hash maybe isn't too much but it's also not not nothing. It's a
>> different kind of operation than the other things you listed (yes, I
>> know there's a hash as part of the signing but it's abstracted away
>> from the developer in most cases) and something that can be quite
>> difficult to troubleshoot when different parties arrive at different
>> hash values. Hence my lack of conviction on this one way or the other. 
>>  
>>
>>
>>     Have you thought about letting deployments decide about the
>>     access token hash? To say look, there is also the option to bind
>>     an access token to the DPoP proof, the security benefits can be
>>     such an such, and this is how it can be done.
>>
>>     What I don't like about that proposal: 
>>
>>       * It will complicate the spec
>>
>>       * The current spec doesn't require implementers / deployments
>>         to make any decisions, apart from adopt / not DPoP (okay,
>>         also choose a JWS alg) - which is actually a great feature to
>>         have
>>
>>
>> I also don't like it for basically the same reasons. I've definitely
>> aimed to keep it simple from that perspective of not having a lot of
>> optionality or switches. It is a nice feature to have, when possible. 
>>
>>  
>>
>>     Vladimir
>>
>>
>>     On 12/12/2020 01:58, Brian Campbell wrote:
>>>     Any type of client could use DPoP and (presumably) benefit from
>>>     sender-constrained access tokens. So yeah, adding complexity
>>>     specifically for browser-based applications (that only mitigates
>>>     one variation of the attacks possible with XSS anyway)  has
>>>     'cost' impact to those clients as well. And should be considered
>>>     in the cost/benefit. Including the AT hash isn't terribly
>>>     complicated but it's not trivial either. I'm honestly still
>>>     unsure but am leaning towards it not being worth adding. 
>>>
>>>     On Fri, Dec 11, 2020 at 2:14 AM Philippe De Ryck
>>>     <philippe@pragmaticwebsecurity.com
>>>     <mailto:philippe@pragmaticwebsecurity.com>> wrote:
>>>
>>>         The scenario you describe here is realistic in browser-based
>>>         apps with XSS vulnerabilities, but it is pretty complex.
>>>         Since there are worse problems when XSS happens, it’s hard
>>>         to say whether DPoP should mitigate this. 
>>>
>>>         I’m wondering what other types of clients would benefit from
>>>         using DPoP for access tokens? Mobile apps? Clients using a
>>>         Client Credentials grant?
>>>
>>>         How are they impacted by any change made specifically for
>>>         browser-based applications?
>>>
>>>         Philippe
>>>
>>>
>>>>         On 9 Dec 2020, at 23:57, Brian Campbell
>>>>         <bcampbell@pingidentity.com
>>>>         <mailto:bcampbell@pingidentity.com>> wrote:
>>>>
>>>>         Thanks Philippe, I very much concur with your line of
>>>>         reasoning and the important considerations. The scenario I
>>>>         was thinking of is: browser based client where XSS is used
>>>>         to exfiltrate the refresh token along with pre-computed
>>>>         proofs that would allow for the RT to be exchanged for new
>>>>         access tokens and also pre-computed proofs that would work
>>>>         with those access tokens for resource access. With the
>>>>         pre-computed proofs that would allow prolonged (as long as
>>>>         the RT is valid) access to protected resources even when
>>>>         the victim is offline. Is that a concrete attack scenario?
>>>>         I mean, kind of. It's pretty convoluted/complex. And while
>>>>         an access token hash would reign it in somewhat (ATs
>>>>         obtained from the stolen RT wouldn't be usable) it's hard
>>>>         to say if the cost is worth the benefit.
>>>>
>>>>
>>>>
>>>>         On Tue, Dec 8, 2020 at 11:47 PM Philippe De Ryck
>>>>         <philippe@pragmaticwebsecurity.com
>>>>         <mailto:philippe@pragmaticwebsecurity.com>> wrote:
>>>>
>>>>             Yeah, browser-based apps are pure fun, aren’t they? :)
>>>>
>>>>             The reason I covered a couple of (pessimistic) XSS
>>>>             scenarios is that the discussion started with an
>>>>             assumption that the attacker already successfully
>>>>             exploited an XSS vulnerability. I pointed out how, at
>>>>             that point, finetuning DPoP proof contents will have
>>>>             little to no effect to stop an attack. I believe it is
>>>>             important to make this very clear, to avoid people
>>>>             turning to DPoP as a security mechanism for
>>>>             browser-based applications.
>>>>
>>>>
>>>>             Specifically to your question on including the hash in
>>>>             the proof, I think these considerations are important:
>>>>
>>>>             1. Does the inclusion of the AT hash stop a concrete
>>>>             attack scenario?
>>>>             2. Is the “cost” (implementation, getting it right, …)
>>>>             worth the benefits?
>>>>
>>>>
>>>>             Here’s my view on these considerations (*/specifically
>>>>             for browser-based apps, not for other types of
>>>>             applications/*):
>>>>
>>>>             1. The proof precomputation attack is already quite
>>>>             complex, and short access token lifetimes already
>>>>             reduce the window of attack. If the attacker can steal
>>>>             a future AT, they could also precompute new proofs then. 
>>>>             2. For browser-based apps, it seems that doing this
>>>>             complicates the implementation, without adding much
>>>>             benefit. Of course, libraries could handle this, which
>>>>             significantly reduces the cost. 
>>>>
>>>>
>>>>             Note that these comments are specifically to
>>>>             complicating the spec and implementation. DPoP’s
>>>>             capabilities of using sender-constrained access tokens
>>>>             are still useful to counter various other scenarios
>>>>             (e.g., middleboxes or APIs abusing access tokens). If
>>>>             other applications would significantly benefit from
>>>>             having the hash in the proof, I’m all for it.
>>>>
>>>>             On a final note, I would be happy to help clear up the
>>>>             details on web-based threats and defenses if necessary.
>>>>
>>>>             —
>>>>             *Pragmatic Web Security*
>>>>             /Security for developers/
>>>>             https://pragmaticwebsecurity.com/
>>>>
>>>>
>>>>>             On 8 Dec 2020, at 22:47, Brian Campbell
>>>>>             <bcampbell@pingidentity.com
>>>>>             <mailto:bcampbell@pingidentity.com>> wrote:
>>>>>
>>>>>             Danial recently added some text to the working copy of
>>>>>             the draft
>>>>>             with https://github.com/danielfett/draft-dpop/commit/f4b42058 that
>>>>>             I think aims to better convey the "nutshell: XSS =
>>>>>             Game over" sentiment and maybe dissuade folks from
>>>>>             looking to DPoP as a cure-all for browser based
>>>>>             applications. Admittedly a lot of the initial impetus
>>>>>             behind producing the draft in the first place was born
>>>>>             out of discussions around browser based apps. But it's
>>>>>             neither specific to browser based apps nor a panacea
>>>>>             for them. I hope the language in the document and how
>>>>>             it's recently been presented is reflective of that
>>>>>             reality. 
>>>>>
>>>>>             The more specific discussions/recommendations around
>>>>>             in-browser apps are valuable (if somewhat over my
>>>>>             head) but might be more appropriate in the OAuth 2.0
>>>>>             for Browser-Based Apps
>>>>>             <https://datatracker.ietf.org/doc/draft-ietf-oauth-browser-based-apps/> draft. 
>>>>>
>>>>>             With respect to the contents of the DPoP draft, I am
>>>>>             still keen to try and flush out some consensus around
>>>>>             the question posed in the start of this thread, which
>>>>>             is effectively whether or not to include a hash of the
>>>>>             access token in the proof.  Acknowledging that "XSS =
>>>>>             Game over" does sort of evoke a tendency to not even
>>>>>             bother with such incremental protections (what I've
>>>>>             tried to humorously coin as "XSS Nihilism" with no
>>>>>             success). And as such, I do think that leaving it how
>>>>>             it is (no AT hash in the proof) is not unreasonable.
>>>>>             But, as Filip previously articulated, including the AT
>>>>>             hash in the proof would prevent potentially prolonged
>>>>>             access to protected resources even when the victim is
>>>>>             offline. And that seems maybe worthwhile to have in
>>>>>             the protocol, given that it's not a huge change to the
>>>>>             spec. But it's a trade-off either way and I'm
>>>>>             personally on the fence about it.
>>>>>
>>>>>             Including an RT hash in the proof seems more niche.
>>>>>             Best I can tell, it would guard against prolonged
>>>>>             offline access to protected resources when access
>>>>>             tokens are bearer and the RT was DPoP-bound and also
>>>>>             gets rotated. The trade-off there seems less worth it
>>>>>             (I think an RT hash would be more awkward in the
>>>>>             protocol too). 
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>             On Fri, Dec 4, 2020 at 5:40 AM Philippe De Ryck
>>>>>             <philippe@pragmaticwebsecurity.com
>>>>>             <mailto:philippe@pragmaticwebsecurity.com>> wrote:
>>>>>
>>>>>
>>>>>>                 The suggestion to use a web worker to ensure that
>>>>>>                 proofs cannot be pre-computed is a good one I
>>>>>>                 think. (You could also use a sandboxed iframe for
>>>>>>                 a separate sub/sibling-domain - dpop.example.com
>>>>>>                 <http://dpop.example.com/>).
>>>>>
>>>>>                 An iframe with a different origin would also work
>>>>>                 (not really sandboxing, as that implies the use of
>>>>>                 the sandbox attribute to enforce behavioral
>>>>>                 restrictions). The downside of an iframe is the
>>>>>                 need to host additional HTML, vs a script file for
>>>>>                 the worker, but the effect is indeed the same.
>>>>>
>>>>>>                 For scenario 4, I think this only works if the
>>>>>>                 attacker can trick/spoof the AS into using their
>>>>>>                 redirect_uri? Otherwise the AC will go to the
>>>>>>                 legitimate app which will reject it due to
>>>>>>                 mismatched state/PKCE. Or are you thinking of XSS
>>>>>>                 on the redirect_uri itself? I think probably a
>>>>>>                 good practice is that the target of a
>>>>>>                 redirect_uri should be a very minimal and locked
>>>>>>                 down page to avoid this kind of possibility.
>>>>>>                 (Again, using a separate sub-domain to handle
>>>>>>                 tokens and DPoP seems like a good idea).
>>>>>
>>>>>                 My original thought was to use a silent flow with
>>>>>                 Web Messaging. The scenario would go as follows:
>>>>>
>>>>>                 1. Setup a Web Messaging listener to receive the
>>>>>                 incoming code
>>>>>                 2. Create a hidden iframe with the DOM APIs
>>>>>                 3. Create an authorization request such as
>>>>>                 “//authorize?response_type=code&client_id=...&redirect_uri=https%3A%2F%example.com
>>>>>                 <http://example.com/>&state=...&code_challenge=7-ffnU1EzHtMfxOAdlkp_WixnAM_z9tMh3JxgjazXAk&code_challenge_method=S256&prompt=none&response_mode=web_message/”
>>>>>                 4. Load this URL in the iframe, and wait for the
>>>>>                 result
>>>>>                 5. Retrieve code in the listener, and use PKCE (+
>>>>>                 DPoP if needed) to exchange it for tokens
>>>>>
>>>>>                 This puts the attacker in full control over every
>>>>>                 aspect of the flow, so no need to manipulate any
>>>>>                 of the parameters.
>>>>>
>>>>>
>>>>>                 After your comment, I also believe an attacker can
>>>>>                 run the same scenario without the
>>>>>                 “/response_mode=web_message/”. This would go as
>>>>>                 follows:
>>>>>
>>>>>                 1. Create a hidden iframe with the DOM APIs
>>>>>                 2. Setup polling to read the URL (this will be
>>>>>                 possible for same-origin pages, not for
>>>>>                 cross-origin pages)
>>>>>                 3. Create an authorization request such as
>>>>>                 “//authorize?response_type=code&client_id=...&redirect_uri=https%3A%2F%example.com
>>>>>                 <http://example.com/>&state=...&code_challenge=7-ffnU1EzHtMfxOAdlkp_WixnAM_z9tMh3JxgjazXAk&code_challenge_method=S256/”
>>>>>                 4. Load this URL in the iframe, and keep polling
>>>>>                 5. Detect the redirect back to the application
>>>>>                 with the code in the URL, retrieve code, and use
>>>>>                 PKCE (+ DPoP if needed) to exchange it for tokens
>>>>>
>>>>>                 In step 5, the application is likely to also try
>>>>>                 to exchange the code. This will fail due to a
>>>>>                 mismatching PKCE verifier. While noisy, I don’t
>>>>>                 think it affects the scenario. 
>>>>>
>>>>>
>>>>>>                 IMO, the online attack scenario (i.e., proxying
>>>>>>                 malicious requests through the victim’s browser)
>>>>>>                 is quite appealing to an attacker, despite the
>>>>>>                 apparent inconvenience:
>>>>>>
>>>>>>                  - the victim’s browser may be inside a corporate
>>>>>>                 firewall or VPN, allowing the attacker to
>>>>>>                 effectively bypass these restrictions
>>>>>>                  - the attacker’s traffic is mixed in with the
>>>>>>                 user’s own requests, making them harder to
>>>>>>                 distinguish or to block
>>>>>>
>>>>>>                 Overall, DPoP can only protect against XSS to the
>>>>>>                 same level as HttpOnly cookies. This is not
>>>>>>                 nothing, but it means it only prevents relatively
>>>>>>                 naive attacks. Given the association of public
>>>>>>                 key signatures with strong authentication, people
>>>>>>                 may have overinflated expectations if DPoP is
>>>>>>                 pitched as an XSS defence.
>>>>>
>>>>>                 Yes, in the cookie world this is known as “Session
>>>>>                 Riding”. Having the worker for token isolation
>>>>>                 would make it possible to enforce a coarse-grained
>>>>>                 policy on outgoing requests to prevent total abuse
>>>>>                 of the AT.
>>>>>
>>>>>                 My main concern here is the effort of doing DPoP
>>>>>                 in a browser versus the limited gains. It may also
>>>>>                 give a false sense of security. 
>>>>>
>>>>>
>>>>>
>>>>>                 With all this said, I believe that the AS can lock
>>>>>                 down its configuration to reduce these attack
>>>>>                 vectors. A few initial ideas:
>>>>>
>>>>>                 1. Disable silent flows for SPAs using RT rotation
>>>>>                 2. Use the sec-fetch headers to detect and reject
>>>>>                 non-silent iframe-based flows
>>>>>
>>>>>                 For example,  an OAuth 2.0 flow in an iframe in
>>>>>                 Brave/Chrome carries these headers:
>>>>>                 /
>>>>>                 sec-fetch-dest: iframe
>>>>>                 sec-fetch-mode: navigate
>>>>>                 sec-fetch-site: cross-site
>>>>>                 sec-fetch-user: ?1
>>>>>                 /
>>>>>
>>>>>
>>>>>                 Philippe
>>>>>
>>>>>
>>>>>             /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./
>>>>
>>>>
>>>>         /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./
>>>
>>>
>>>
>>>
>>>
>>>     /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
>>>     OAuth@ietf.org <mailto:OAuth@ietf.org>
>>>     https://www.ietf.org/mailman/listinfo/oauth
>>
>>     -- 
>>     Vladimir Dzhuvinov
>>
>>     _______________________________________________
>>     OAuth mailing list
>>     OAuth@ietf.org <mailto:OAuth@ietf.org>
>>     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
>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth