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

[Dick Hardt <[e-mail]>]

Another dimension on SPA is that lots of 1P deployments use only SPA. For
them, there is only one type of deployment.

On Fri, Nov 22, 2019 at 4:50 PM Mike Jones <Michael.Jones=
[e-mail]> wrote:

> I hear you about the difference between Web apps and native apps,
> Torsten.  But using different mechanisms for different application types is
> a cost in and of itself.
>
> It's good to understand the tradeoffs.
>
> -- Mike
>
>
> ------------------------------
> *From:* OAuth <[e-mail]> on behalf of Torsten Lodderstedt
> <torsten=[e-mail]>
> *Sent:* Friday, November 22, 2019 4:20:58 PM
> *To:* Rob Otto <robotto=[e-mail]>
> *Cc:* oauth <[e-mail]>
> *Subject:* [EXTERNAL] Re: [OAUTH-WG] New Version Notification for
> draft-fett-oauth-dpop-03.txt
>
> Hi Rob,
>
> > On 22. Nov 2019, at 16:10, Rob Otto <robotto=
> [e-mail]> wrote:
> >
> > Hi Torsten - thanks for the reply..
> >
> > Responses in line.
> >
> > Grüsse
> > Rob
> >
> > On Fri, 22 Nov 2019 at 07:59, Torsten Lodderstedt <torsten=
> [e-mail]> wrote:
> > Hi Rob,
> >
> > > On 22. Nov 2019, at 15:52, Rob Otto <robotto=40pingidentity.com@dmarc.
> .ietf.org> wrote:
> > >
> > > Hi everyone
> > >
> > > I'd agree with this. I'm looking at DPOP as an alternative and
> ultimately simpler way to accomplish what we can already do with MTLS-bound
> Access Tokens, for use cases such as the ones we address in Open Banking;
> these are API transactions that demand a high level of assurance and as
> such we absolutely must have a mechanism to constrain those tokens to the
> intended bearer. Requiring MTLS across the ecosystem, however, adds
> significant overhead in terms of infrastructural complexity and is always
> going to limit the extent to which such a model can scale.
> >
> > I would like to unterstand why mTLS adds “significant overhead in terms
> of infrastructural complexity”. Can you please dig into details?
> >
> > I guess it's mostly that every RS-endpoint (or what sits in front of it)
> has to have a mechanism for accepting/terminating mTLS, managing roots of
> trust, validating/OCSP, etc
>
> You use a PKI then. We use mTLS with self-signed certs. That requires the
> RS to not check the X.509 trust chain, which requires a special setting
> (optionalNoCA).
>
> > and then passing the certificates downstream as headers. None of it is
> necessarily difficult or impossible to do in isolation, but I meet many
> many people every week who simply don't know how to do any of this stuff.
> And these are typically "network people", for want of a better word. There
> are quite a few SaaS API management and edge solutions out there that don't
> even support mTLS at all. You also have the difficulty in handling a
> combination of MTLS and non-MTLS traffic to the same endpoints.
>
> yep. You better split them, especially if that’s a user facing endpoint.
>
> > Again, it's possible to do, but far from straightforward.
> >
> >
> >
> > Our experience so far: It can be a headache to set up in a microservice
> architecture with TLS terminating proxies but once it runs it’s ok. On the
> other side, it’s easy to use for client developers and it combines client
> authentication and sender constraining nicely.
> >
> > I do think its an elegant solution, don't get me wrong. It's just that
> there are plenty of moving parts that you need to get right and that can be
> a challenge, particularly in large, complex environments.
>
> I agree. I also tend there is a tendency to think Client TLS
> authentication is bad. I understand that from historical and recent
> experience with PKI.
>
> But anybody considering to use a application level signing solution based
> on _raw_ public keys should directly move towards self-signed certificates.
> That brings you all the benefits of TLS without the (PKI) headache.
>
> >
> >
> >
> > >
> > > DPOP, to me, appears to be a rather more elegant way of solving the
> same problem, with the benefit of significantly reducing the complexity of
> (and dependency on) the transport layer. I would not argue, however, that
> it is meant to be a solution intended for ubiquitous adoption across all
> OAuth-protected API traffic. Clients still need to manage private keys
> under this model and my experience is that there is typically a steep
> learning curve for developers to negotiate any time you introduce a
> requirement to hold and use keys within  an application.
> >
> > My experience is most developer don’t even get the URL right (in the
> signature and the value used on the receiving end). So the total cost of
> ownership is increased by numerous support inquiries.
> > I'll not comment, at the risk of offending developers :)
>
> Alright. Ultimately, I just want to get in touch with those who respond :-)
>
> best regards,
> Torsten.
>
> >
> > best regards,
> > Torsten.
> >
> > >
> > > I guess I'm with Justin - let's look at DPOP as an alternative to
> MTLS-bound tokens for high-assurance use cases, at least initially, without
> trying to make it solve every problem.
> > >
> > > Best regards
> > > Rob
> > >
> > >
> > > On Fri, 22 Nov 2019 at 07: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.
> > >
> > > 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&amp;data=02%7C01%7CMichael.Jones%40microsoft.com%7C2ddae7c4050348d9405a08d76f24f315%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637100076834776598&amp;sdata=6x%2Fjtuo2qkObT8bAdMUmkHbvOYr8wZX7pngViwA4e0Q%3D&amp;reserved=0
> > >
> > > _______________________________________________
> > > OAuth mailing list
> > > [e-mail]
> > >
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&amp;data=02%7C01%7CMichael.Jones%40microsoft.com%7C2ddae7c4050348d9405a08d76f24f315%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637100076834776598&amp;sdata=6x%2Fjtuo2qkObT8bAdMUmkHbvOYr8wZX7pngViwA4e0Q%3D&amp;reserved=0
> > >
> > >
> > > --
> > >
> > > Rob Otto
> > > EMEA Field CTO/Solutions Architect
> > > [e-mail]
> > >
> > > c: [phone]
> > > Connect with
> us:
>
> > >
> > >
> > > 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
> > > [e-mail]
> > >
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&amp;data=02%7C01%7CMichael.Jones%40microsoft.com%7C2ddae7c4050348d9405a08d76f24f315%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637100076834776598&amp;sdata=6x%2Fjtuo2qkObT8bAdMUmkHbvOYr8wZX7pngViwA4e0Q%3D&amp;reserved=0
> >
> >
> >
> > --
> >
> > Rob Otto
> > EMEA Field CTO/Solutions Architect
> > [e-mail]
> >
> > c: [phone]
> > Connect with
> us:
>
> >
> >
> > 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>