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 list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
