I couldn't agree more. I think we should, again, try to find a way to utilise TLS in the browser as well.
> On 22. Nov 2019, at 16:50, Mike Jones > <Michael.Jones=40microsoft....@dmarc.ietf.org> 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 <oauth-boun...@ietf.org> on behalf of Torsten Lodderstedt > <torsten=40lodderstedt....@dmarc.ietf.org> > Sent: Friday, November 22, 2019 4:20:58 PM > To: Rob Otto <robotto=40pingidentity....@dmarc.ietf.org> > Cc: oauth <oauth@ietf.org> > 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=40pingidentity....@dmarc.ietf.org> wrote: > > > > Hi Torsten - thanks for the reply.. > > > > Responses in line. > > > > Grüsse > > Rob > > > > On Fri, 22 Nov 2019 at 07:59, Torsten Lodderstedt > > <torsten=40lodderstedt....@dmarc.ietf.org> wrote: > > Hi Rob, > > > > > On 22. Nov 2019, at 15:52, Rob Otto > > > <robotto=40pingidentity....@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 <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. > > > > > > 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jones%40microsoft.com%7C2ddae7c4050348d9405a08d76f24f315%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637100076834776598&sdata=6x%2Fjtuo2qkObT8bAdMUmkHbvOYr8wZX7pngViwA4e0Q%3D&reserved=0 > > > > > > _______________________________________________ > > > OAuth mailing list > > > OAuth@ietf.org > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jones%40microsoft.com%7C2ddae7c4050348d9405a08d76f24f315%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637100076834776598&sdata=6x%2Fjtuo2qkObT8bAdMUmkHbvOYr8wZX7pngViwA4e0Q%3D&reserved=0 > > > > > > > > > -- > > > > > > Rob Otto > > > EMEA Field CTO/Solutions Architect > > > roberto...@pingidentity.com > > > > > > c: +44 (0) 777 135 6092 > > > 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 > > > OAuth@ietf.org > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jones%40microsoft.com%7C2ddae7c4050348d9405a08d76f24f315%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637100076834776598&sdata=6x%2Fjtuo2qkObT8bAdMUmkHbvOYr8wZX7pngViwA4e0Q%3D&reserved=0 > > > > > > > > -- > > > > Rob Otto > > EMEA Field CTO/Solutions Architect > > roberto...@pingidentity.com > > > > c: +44 (0) 777 135 6092 > > 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 > 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
