> On 22. Nov 2019, at 15:24, Justin Richer <jric...@mit.edu> wrote: > > I’m going to +1 Dick and Annabelle’s question about the scope here. That was > the one major thing that struck me during the DPoP discussions in Singapore > yesterday: we don’t seem to agree on what DPoP is for. Some (including the > authors, it seems) see it as a quick point-solution to a specific use case. > Others see it as a general PoP mechanism. > > If it’s the former, then it should be explicitly tied to one specific set of > things. If it’s the latter, then it needs to be expanded.
as a co-author of the DPoP draft I state again what I said yesterday: DPoP is a mechanism for sender-constraining access tokens sent from SPAs only. The threat to be prevented is token replay. The general mechanism for sender constrained access token should be TLS-based as recommended by the Security BCP (see https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-3.2). Why: that’s the easiest way from a client developer's perspective. Application level signatures, on the other hand, are inherently more fragile as illustrated by the OAuth 1 experience. They also require additional effort (and state) on the server side to implement replay detection. As kind of an entertaining read I added two posts/threads from 2010, when this WG discussed whether TLS/SSL should be the primary OAuth 2.0 security mechanism. https://mailarchive.ietf.org/arch/msg/oauth/crVvDNtbdN0E0ccmk5fLdNS66v0 https://mailarchive.ietf.org/arch/browse/oauth/?gbt=1&index=xvlxuly1DjQiZgWZpHwgj7q2k0g The decision to go with TLS only was, in my opinion, one of the key success factors that made OAuth 2 so incredibly successful. To re-state: From my perspective, DPoP is intended to be used by SPA developers only for token replay detection (or better put to provide RSs with the pre-requisites to do so). Why? Because we unfortunately currently lack a TLS-based mechanism for sender-constraining. Building it on asymmetrical crypto only makes it easier to implement and to handle than methods based on shared secrets. I also think we must look for alternative methods to enable TLS-based methods in the browser. > > I’ll repeat what I said at the mic line: My take is that we should explicitly > narrow down DPoP so that it does exactly one thing and solves one narrow use > case. And for a general solution? Let’s move that discussion into the next > major revision of the protocol where we’ll have a bit more running room to > figure things out. > > — Justin > >> On Nov 22, 2019, at 3:13 PM, Dick Hardt <dick.ha...@gmail.com> wrote: >> >> >> >> On Fri, Nov 22, 2019 at 3:08 PM Neil Madden <neil.mad...@forgerock.com> >> wrote: >> On 22 Nov 2019, at 01:42, Richard Backman, Annabelle <richa...@amazon.com> >> wrote: >>> There are key distribution challenges with that if you are doing validation >>> at the RS, but validation at the RS using either approach means you’ve lost >>> protection against replay by the RS. This brings us back to a core >>> question: what threats are in scope for DPoP, and in what contexts? >> >> Agreed, but validation at the RS is premature optimisation in many cases. >> And if you do need protection against that the client can even append a >> confirmation key as a caveat and retrospectively upgrade a bearer token to a >> pop token. They can even do transfer of ownership by creating copies of the >> original token bound to other certificates/public keys. >> >> While validation at the RS may be an optimization in many cases, it is still >> a requirement for deployments. >> >> I echo Annabelle's last question: what threats are in scope (and out of >> scope) for DPoP? >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
