Re: Tying signed responses to signed requests

Hi Roberto,

What you are describing seems to be a more general mechanism, not specific to the signature mechanism. That might in fact be an interesting discussion to have here in HTTPWG, and if such a mechanism would exist it would make sense to sign it.

However, by having the server sign the signature from the request, we are functionally letting the server indicate that the response is tied to whatever parts are signed in the initial request. This is going to be fairly application specific as, for example, the server might not know its own target URI as known by the client, meaning that would be a portion generally not signed for that application.

 — Justin

> On Jul 1, 2021, at 2:29 PM, Roberto Polli <roberto@teamdigitale.governo.it> wrote:
> 
> Hi Justin,
> 
> I think the discussion is interesting and this kind of flow is usually implemented adding  specific headers to the signature. 
> 
> Surely conveying information such as the target Uri in the response can be valuable as long as the server knows the public uri.
> 
> I am planning some time for next week for a more detailed reply.
> 
> Have a nice day
> R
> 
> 
> 
> Il gio 1 lug 2021, 16:48 Justin Richer <jricher@mit.edu <mailto:jricher@mit.edu>> ha scritto:
> 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 <https://bitbucket.org/openid/fapi/src/master/Financial_API_Simple_HTTP_Message_Integrity_Protocol.md>