Integrity protecting HTTP requests using DPoP and Client Attestations

[tplooker]

Note - I'm unsure of the best place to discuss this concept but I'm starting the conversation here, due to its potential relationship to this draft.

DPoP as defined in RFC9449 provides a mechanism for sender-constraining tokens issued in OAuth 2.0. By design however the mechanism for sender-constraining of tokens isn't intended to provide wider integrity guarantees over the HTTP message upon which a DPoP proof is attached to. The same problem exists for client attestations.

We've now encountered situations where DPoP (and potentially Client attestations) are (or going to be) used and integrity over the request body of the HTTP message is also desired. This leaves implementations with a couple of possible choices

1. To not have integrity over the request body (beyond what TLS already provides) - This is a difficult argument to make in some of the proposed applications where TLS isn't sufficiently trusted to provide the required integrity
2. To define a seperate mechanism to provide integrity over the request body seperate from DPoP or Client attestations
3. To devise a mechanism whereby a DPoP proof or Client Attestation PoP could also provide integrity over the request body

The remainder of this issue focuses on discussing a proposal for option 3.

HTTP defines a specific header called Content-Digest which provides a hash/digest over the HTTP message content. In essence, if the value of this header were included inside a DPoP proof / Client Attestation PoP, integrity over the HTTP message content could verified.

An example of a DPoP proof

{
  "typ":"dpop+jwt",
  "alg":"ES256",
  "jwk": {
    "kty":"EC",
    "x":"l8tFrhx-34tV3hRICRDY9zCkDlpBhF42UQUfWVAWBFs",
    "y":"9VE4jf_Ok_o64zbTTlcuNJajHmt6v9TDVrU0CdvGRDA",
    "crv":"P-256"
  }
}
.
{
  "jti":"-BwC3ESc6acc2lTc",
  "htm":"POST",
  "htu":"https://server.example.com/token",
  **"htcd": "sha-256=:47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=:",**
  "iat":1562262616
}

Note the new htcd JWT claim where the value is the value of the Content-Digest HTTP header.

The main advantage I can see to this proposal is that integrity is provided via DPoP without the need for an additional signature over the HTTP message content.

Alternative proposals could involve

1. Providing a seperate signature over the HTTP message using HTTP message signatures - this requires two signatures in the HTTP message
2. Providing a seperate signature over the HTTP message using JWS on the request body - awkward if the request body isn't JSON and also suffers from two signatures in the HTTP message