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

["Richard Backman, Annabelle" <[e-mail]>]

Agreed with keeping DPoP simple, which was why I was asking if the proposal could indicate it was targeting some of these other use cases.

It's clear from the feedback that the current draft does not clearly express these use cases. There is overlap with DPoP – on a technical level, Message Signatures ought to be able to handle DPoP's use cases, albeit complexity in different places. But not vice-versa.


The current draft being proposed for adoption I believe is fixed to the same HTTP properties that DPoP leverages, and thus appears to be targeting the same use cases with a different proof expression.

This is a misconception that should get clarified in the draft. One of the core concepts behind Message Signatures is that it defines a standard mechanism for signature components of an HTTP message and for communicating which components are signed, but it does not dictate which components need to be signed. That will vary from deployment to deployment, based on which components are semantically meaningful. E.g., an RS that accepts POST requests and receives parameters in the request body may require that the `Digest` header field be signed, whereas one that only accepts GET requests may only need the URL to be signed. The draft defines an `Accept-Signature` header field that can be included in a message to indicate which components need to be signed.

Justin's draft introduces a requirement that signatures intended to provide PoP for OAuth MUST sign the `Authorization` header field, since that's where the access token is. Beyond that, RSes can indicate their API-specific signing requirements via `Accept-Signature`. (And/or through out-of-band documentation)

The duplication within the token is also a trade-off: it allows an implementation to have a white list of acceptable internal values, if say the host and path are rewritten by reverse proxies.

I agree, there are trade-offs. For some, especially those already using JWTs all over the place, the simplicity of using a format and libraries they are already familiar with may outweigh the risk I described.

FWIW, the Message Signatures approach to the situation you described would be for the reverse proxy to add an `X-Forwarded-Host` or similar header field, and add a signature over that, the `Host` header field, and the client's signature. (Message Signatures supports multiple signatures on one message) I like this approach as the signatures are guaranteed to be validated against the same data the application uses. (Since there's only one copy of the data)

—
Annabelle Backman (she/her)
[e-mail]<mailto:[e-mail]>




On Oct 13, 2021, at 11:41 AM, David Waite <[e-mail]<mailto:[e-mail]>> wrote:

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.



On Oct 13, 2021, at 12:26 PM, Richard Backman, Annabelle <[e-mail]<mailto:[e-mail]>> wrote:

Those issues that could be addressed without completely redesigning DPoP have been discussed within the Working Group multiple times. (See quotes and meeting notes references in my previous message) The authors have pushed back on extending DPoP to cover additional use cases them due to a desire to keep DPoP simple and lightweight. I don't begrudge them that. I think it's reasonable to have a "dirt simple" solution, particularly for SPAs given the relative limitations of the browser environment.

Other issues are inherent to fundamental design choices, such as the use of JWS to prove possession of the key. E.g., you cannot avoid the data duplication issue since a JWS signature only covers a specific serialization of the JWT header and body.

Agreed with keeping DPoP simple, which was why I was asking if the proposal could indicate it was targeting some of these other use cases. The current draft being proposed for adoption I believe is fixed to the same HTTP properties that DPoP leverages, and thus appears to be targeting the same use cases with a different proof expression.

The duplication within the token is also a trade-off: it allows an implementation to have a white list of acceptable internal values, if say the host and path are rewritten by reverse proxies. It also allows an implementation to give richer diagnostic information when receiving unacceptable DPoP tokens, which may very well come at runtime from an independently-operating portion of an organization reconfiguring intermediaries.

-DW