Rob, I agree that managing roots of trust, validating/OCSP etc is not "easy" per se, but the MTLS setup gets really simple with the Self-Signed Certificate Mutual-TLS Method <https://tools.ietf.org/html/draft-ietf-oauth-mtls-17#section-2.2> and we made sure combined traffic is simple to signal by the AS and simple to detect and use by clients using the mtls_endpoint_aliases discovery metadata.
S pozdravem, *Filip Skokan* On Fri, 22 Nov 2019 at 09: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 <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 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. 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. > > > >> >> > >> > 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 :) > >> >> 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 >> <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 >> > >> > >> > -- >> > >> > 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 >> >> > > -- > <https://www.pingidentity.com>[image: Ping Identity] > <https://www.pingidentity.com> > Rob Otto > EMEA Field CTO/Solutions Architect > roberto...@pingidentity.com > > c: +44 (0) 777 135 6092 > Connect with us: [image: Glassdoor logo] > <https://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm> > [image: > LinkedIn logo] <https://www.linkedin.com/company/21870> [image: twitter > logo] <https://twitter.com/pingidentity> [image: facebook logo] > <https://www.facebook.com/pingidentitypage> [image: youtube logo] > <https://www.youtube.com/user/PingIdentityTV> [image: Google+ logo] > <https://plus.google.com/u/0/114266977739397708540> [image: Blog logo] > <https://www.pingidentity.com/en/blog.html> > <https://www.google.com/url?q=https://www.pingidentity.com/content/dam/ping-6-2-assets/Assets/faqs/en/consumer-attitudes-post-breach-era-3375.pdf?id%3Db6322a80-f285-11e3-ac10-0800200c9a66&source=gmail&ust=1541693608526000&usg=AFQjCNGBl5cPHCUAVKGZ_NnpuFj5PHGSUQ> > <https://www.pingidentity.com/en/events/d/identify-2019.html> > > *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 >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
