To clarify, I wasn’t suggesting we drop one or the other. Both have their merit and use cases, and both should be developed all the way to standard IMO. But from some preliminary exploration, it seems unlikely that services will adopt both at the same time. From the “pr” perspective, having a clear _default_ answer to the question “how do I add sender constraint capabilities to my service?” would greatly enhance the chances of getting something out in the real world quickly, make it possible to interop and iron out wrinkles, etc etc- For the general developer populace, at this point “sender constraint” remains something vaguely exotic and often decisions made on that (like the ones on the implicit deprecation) are poorly received. Even the ones who had exposure had been somewhat “burned” by how token binding is going, and we are in need for something easy to grok and actionable to rekindle interest IMO. The sooner we can get the concept mainstream the better.
On Tue, May 7, 2019 at 07:13 George Fletcher <gffletch= 40aol....@dmarc.ietf.org> wrote: > I don't see them the same at all. With MTLS, the token is bound to the > transport layer (and the key used to establish that encrypted connection).. > With DPOP, the token is bound to the private key known to the client. > > To compromise an MTLS bound token the attacker has to compromise the > private key. To compromise a DPOP bound token, depending on what HTTP > request elements are signed, and whether the DPOP is managed as > one-time-use etc, there are additional attacks. (Ducks head and waits for > all the real security experts to prove me wrong:) > > The deployment models are also different. With MTLS bound tokens the > clients don't really have to know about the binding because it is > established at the AS and the deployment of the service manages the cert > used for the MTLS connection. This is simpler for client development > (provided the environment is already set up for MTLS everywhere). > > I'd strong encourage us to continue supporting both methods. > > On 5/7/19 4:25 AM, Hannes Tschofenig 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 listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > 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
