Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

[Filip Skokan <[e-mail]>]

I agree with Torsten,

plus we're getting sender-constrained refresh tokens for said public
clients and SPAs so that the AS doesn't have to (according to the browser
based apps draft) rotate them, we all know the pain SPA developers have
with those.

S pozdravem,
*Filip Skokan*


On Fri, 22 Nov 2019 at 08:54, Torsten Lodderstedt <torsten=
[e-mail]> wrote:

>
>
> > On 22. Nov 2019, at 15:24, Justin Richer <[e-mail]> 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 <[e-mail]> wrote:
> >>
> >>
> >>
> >> On Fri, Nov 22, 2019 at 3:08 PM Neil Madden <[e-mail]>
> wrote:
> >> On 22 Nov 2019, at 01:42, Richard Backman, Annabelle <
> [e-mail]> 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
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/oauth
> >
> > _______________________________________________
> > OAuth mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>