For what it’s worth, if we think of things a little bit differently, we can support both types of key presentation and possession proofs in parallel. My thinking was that in both the MTLS and DPoP cases, the client proves that it has access to a key and then uses that key with the RS in the same way it uses it with the AS. The format of the key and its presentation mechanism differ, but otherwise there really are a lot of parallels. This is how I’ve been thinking of it in the XYZ project:
https://oauth.xyz/keys/ It’s still very-drafty at the moment, but it follows as an abstraction to this thinking. In XYZ this is a bit simplified because the client always starts at the backchannel endpoint (equivalent to the token endpoint). In OAuth2, this would happen during the call to the token endpoint, as in the DPoP and MTLS drafts. — Justin On May 7, 2019, at 4:25 AM, Hannes Tschofenig <hannes.tschofe...@arm.com<mailto:hannes.tschofe...@arm.com>> wrote: Hi all, In the OAuth conference call today Vittorio mentioned that some folks are wondering whether DPOP is essentially a superset of MTLS and whether it makes sense to only proceed with one solution rather potentially two. I was wondering whether others in the group have a few about this aspect? Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
