Re: [OAUTH-WG] Call for Adoption - OAuth Proof of Possession Tokens with HTTP Message Signature

[David Waite <[e-mail]>]

I do not support adopting this work as proposed, with the caveat that I am a co-editor of the DPoP work.

We unfortunately do not have a single approach for PoP which works for all scenarios and deployments, why we have had several proposals and standards such as Token Binding, mutual TLS, and DPoP. There have been other less generalized approaches as well, such as forming signed request and response objects on the channel when one needs end-to-end message integrity or confidentiality.

Each of these has their own capabilities and trade-offs, and their applicability to scenarios where the others falter is why multiple approaches is justified.

The preferred solution for HTTPS resource server access is to leverage MTLS. However, browsers have both poor/nonexistent API to manage ephemeral client keys and poor UX around mutual TLS in general.

DPoP was proposed to attempt a “lightest lift” to provide cryptographic evidence of the sender being involved, so that browsers could protect their tokens from exfiltration by non-exportable, ephemeral keys. In that way, we keep from having to define a completely separate security posture for resource-constraining browser apps.

The motivations for the HTTPSig specification don’t clearly state why it is essential to have another promoted PoP approach. I would expect more prescriptive text about the use case that this is proposed for. In particular, I would love to see an additional use case, outside of DPoP, not solved by MTLS but solved by this proposal.

If it turns out the target between a HTTP Message Signatures and DPoP overlap completely, I suspect we would have the issue of two competing adopted drafts in the working group. I personally do not know the ramifications of such an event. I do not believe there would be consensus on eliminating one, nor would there be a significant reduction in complexity by combining them.

Deferring until HTTPSig is interoperably implemented in the industry gives us concrete motivation in the future to support both.

-DW