Serialization#draft-ietf-httpbis-message-signatures-00

[Anders Rundgren <[e-mail]>]

Dear List,
Making signed HTTP requests serializable (in a reasonable way) is as far as I can tell not a part of the current agenda.

FWIW, here is a [very] raw proposal for how this could be accomplished:
- Build on JWS compact mode.
- Put a hash and attributes of the of signed HTTP header data (you're the experts on this part) in the JWS Protected Header as an extension.
- Put the payload in the JWS Payload element using the standard base64url encoding.
   Optionally use the JWS "typ" Protected Header element to specify MIME type of the payload
- Use the completed JWS compact string as the sole HTTP Body element

For JSON-formatted data there is yet another possibility: combine https://www.rfc-editor.org/rfc/rfc8785.html with "in-line/detached" JWS ( https://tools.ietf.org/html/rfc7515#appendix-F):
   {
      "anyJsonElement": "something",
          .
          .
      "signature":"eyJblahblahblah..blahblahblah"
   }

In both cases the HTTP Body element contains the serializable signed data.  Verifying signed HTTP header data is though not possible to perform after leaving the HTTP environment.  OTOH, for systems that actually depend on serialization, using HTTP headers as data carriers doesn't appear as a recommendable approach.  In my own work which heavily builds on counter-signatures for digital contracts, URL and current time are therefore represented in the JSON payload by "requestUrl" and "timeStamp" respectively.

Thanx,
Anders