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? 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. > > 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. 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://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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
