Re: [OAUTH-WG] MTLS vs. DPOP

[Hannes Tschofenig <[e-mail]>]

Hi Ben,

> I've forgotten the details of those two documents, but in the general case, if there's a WG document that is no longer actively being worked on (or is now believed to be a bad idea), the chairs can pretty easily get a new rev posted that has a "tombstone" notice, like "this document is no longer being worked on" or similar, which may help clarify the situation to external parties without much investment on time or tooling.

When we started the work on the PoP tokens we were ahead of the OAuth deployment because many developers didn't see the need to switch from the bearer tokens to the proof-of-possession tokens. Hence, the work progressed very slowly.

Now, the situation has changed with OAuth being used in use cases where there are higher security concerns, for example in the financial sector.

There are, however, also technical challenges with the PoP token approach and we ran into one of them with the HTTP signing and also deployment challenges (see token binding). I believe many people want such a PoP solution but there are just cases where it does not work. For HTTP signing we have at least two solutions in the IETF right now, namely  https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-03 and https://tools.ietf.org/html/draft-cavage-http-signatures-11

DPoP does not address the issue of how the request from the Client to the RS is actually protected. It only hints to it. If you want to get this to work you have to use one of the above documents or come up with yet another method.

Additionally, DPoP overlaps an already existing working group item, which we had planned to sent to the IESG soon: https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-07
One of the differences between DPoP and PoP key distribution is the question whether the client always needs to demonstrate possession of the private to the AS. As you remember I took the action item to work on a formal analysis, which I posted to the list.

Why the extra DPoP functionality has not been incorporated into the already chartered working group item is not entirely clear to me.

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.