Tying signed responses to signed requests

I recently learned of a feature in a different HTTP-signing proposal[1] that allows a server to sign a response in a way that references the signature in the request that created that response. In the other proposal, they include a hash of the original signature’s JOSE object as a body claim in the response signature. I made an attempt to match that feature in HTTP Message Signatures. It works by creating a new “specialty identifier” that a server can use in its response. When present, the identifier references a signature from the request. This is different from the multi-signature function that’s already in there because the request signature is not present at all in the response (either in full or in hash form), and it’s assumed that the client that created the original request would have access to the signature it created.

Please take a look at the proposed text when you can:

https://github.com/httpwg/http-extensions/pull/1566 <https://github.com/httpwg/http-extensions/pull/1566>

Annabelle and I have a few open questions about this that we’d like feedback from the group:

 - Is this a feature that people care about? It obviously got invented to fill a need in another WG, but is this something people want?
 - Is this simple enough to keep in the core signatures spec? Specialty identifiers can be added via external documents, if we decide it doesn’t fit. 
 - Are there elements of HTTP/2 or HTTP/3 that could fill in this same role better? I know that responses are multiplexed to a single request, is there something that ties them together that this function should reference in those cases?
 - It’s assumed the original sender keeps the signature value around for later use, should this warning be stronger?
 - This would seem to really beg for a Want-Signature style header where the client can indicate that it wants a signed response to include this kind of link, among other things. Should we add this kind of negotiation now? (It’s tracked in a separate issue already)

Thanks
 — Justin



[1] https://bitbucket.org/openid/fapi/src/master/Financial_API_Simple_HTTP_Message_Integrity_Protocol.md