Original text:
origin server, changing the target host and adding the Forwarded header field defined in RFC7239. <del> While the proxy is in a position to validate the client's signature, the changes the proxy makes to the message will invalidate the existing signature when the message is seen by the origin server. While it is possible for the origin server to have additional information in its signature context to account for the change in authority, this practice requires additional configuration and extra care (see further discussion in security-context-multiple- signatures).  The proxy is in a position to make its own statement to the origin server about the nature of the request that it is forwarding by adding its own signature over the new message before passing it along to the origin server.  The proxy includes the new "@authority" derived component and the Forwarded header, which the proxy has added to the message.  The proxy also includes elements from the original message that are relevant to the origin server's processing, such as the "@method", "@path", and "@query" in this example, even if those components were covered by the original signature.  The proxy additionally includes the client's signature value and signature input from the original message in the new signature's covered components.  In our example application, this is used as a way for the proxy to indicate to the origin server that the proxy has read and verified these values in their original context. While the origin server may not be able to directly verify this original signature, it can verify that the proxy has vouched for the signature's validity.  The origin server also has assurance that the message has been forwarded intact from the trusted proxy. The proxy identifies its own key and algorithm and, in this example, includes an expiration for the signature to indicate to downstream systems that the proxy will not vouch for this signed message past this short time window.  This results in a signature base of: </del>  And a signature output value of:

Reviewer comments:
Reframe use cases that had previously signed signature values to avoid problems with this approach.
This looks good to me! Summary of the changes: Explicitly flagging that the application / implementer must specify how request-response binding is to be achieved (if desired). Removed all references to request-response binding in the main body. Removed all signatures of signatures from the examples Added guidance that applications SHOULD sign all signed components of a request when generating a signed response. Added guidance that generating signatures of signatures is NOT RECOMMENDED when generating responses. Added guidance that generating signatures of signatures is NOT RECOMMENDED when acting as a proxy between a request / response.

Revised text:
origin server, changing the target host and adding the Forwarded header field defined in RFC7239.  <ins> The proxy is in a position to validate the incoming client's signature and make its own statement to the origin server about the nature of the request that it is forwarding by adding its own signature over the new message before passing it along to the origin server.  The proxy also includes all the elements from the original message that are relevant to the origin server's processing.  In many cases, the proxy will want to cover all the same components that were covered by the client's signature, which is the case in this example. Note that in this example, the proxy is signing over the new authority value, which it has changed.  The proxy also adds the Forwarded header to its own signature value.  The proxy identifies its own key and algorithm and, in this example, includes an expiration for the signature to indicate to downstream systems that the proxy will not vouch for this signed message past this short time window.  This results in a signature base of: </ins> And a signature output value of: