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

2020-12-11 Thread Neil Madden
Not directly related to DPoP or OAuth, but I wrote some notes to help recovering XSS Nihilists: https://neilmadden.blog/2020/12/10/xss-doesnt-have-to-be-game-over/ — Neil > On 12 Dec 2020, at 00:02, Brian Campbell > wrote: > >  > I think that puts Jim in the XSS Nihilism camp :) > >

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

2020-12-11 Thread Brian Campbell
I think that puts Jim in the XSS Nihilism camp :) Implicit type flows are being deprecated/discouraged. But keeping tokens out of browsers doesn't seem likely. There is some menton of CSP in https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-07#section-9.7 On Wed, Dec 9, 2020 at

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

2020-12-11 Thread Brian Campbell
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

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

2020-12-11 Thread Philippe De Ryck
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