Code change:
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.

Related discussion:
text: against the given keys, but newly-generated signature values are not expected to match the example.  See security-nondeterministic. <del> Since the signature component values from the request are not repeated in the response, the requester MUST keep the original message component values around long enough to validate the signature of the response that uses this component identifier.  In most cases, this means the requester needs to keep the original request message around, since the signer could choose to include any portions of the request in its response, according to the needs of the application. Since it is possible for an intermediary to alter a request message before it is processed by the server, applications need to take care not to sign such altered values as the client would not be able to validate the resulting signature. Applications needing this type of binding have to sign sufficient portion the request to ensure that it is uniquely tied to the response.  Signing the signature value of a signed request alone does not provide sufficient coverage in most cases, as discussed in security-sign-signature. The response signature can only cover what is included in the request.  Therefore, if an application needs to bind the message content of the request in its response, the client needs to include a means for covering that content, such as a Content-Digest field.  See the discussion in security-message-content for more information. The "req" parameter MUST NOT be used in a signature that targets a request message. </del> <ins> Since the component values from the request are not repeated in the response message, the requester MUST keep the original message component values around long enough to validate the signature of the response that uses this component identifier parameter.  In most cases, this means the requester needs to keep the original request message around, since the signer could choose to include any portions of the request in its response, according to the needs of the application.  Since it is possible for an intermediary to alter a request message before it is processed by the server, applications need to take care not to sign such altered values as the client would not be able to validate the resulting signature. It is additionally possible for a server to create a signed response in response to a signed request.  For example, this signed request: The server could choose to sign portions of this response, including several portions of the request resulting in this signature base: And the following signed response: Note that the ECDSA algorithm in use here is non-deterministic, meaning a different signature value will be created every time the algorithm is run.  The signature value provided here can be validated against the given keys, but newly-generated signature values are not expected to match the example.  See security-nondeterministic. Applications signing a response to a signed request SHOULD sign all of the components of the request signature value to provide sufficient coverage and protection against a class of collision attacks, as discussed in security-sign-signature.  The server in this example has included all components listed in the Signature-Input of the client's signature on the request in the response signature, in addition to components of the response. While it is syntactically possible to include the Signature and Signature-Input fields of the request message in the signature components of a response a message using this mechanism, this practice is NOT RECOMMENDED.  This is because signatures of signatures do not provide transitive coverage of covered components as one might expect and the practice is susceptible to several attacks as discussed in security-sign-signature.  An application that needs to signal successful processing or receipt of a signature would need to carefully specify alternative mechanisms for sending such a signal securely. The response signature can only ever cover what is included in the request message when using this flag.  Consequently, if an application needs to include the message content of the request under the signature of its response, the client needs to include a means for covering that content, such as a Content-Digest field.  See the discussion in security-message-content for more information. The "req" parameter MUST NOT be used for any component in a signature that targets a request message. </ins> 2.5.