Re: Tying signed responses to signed requests

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> 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
>
> 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
>