Code change:
Signatures, an application or profile of this specification MUST specify all of the following items: <del> The set of covered-content that are expected and required to be included in the covered components list.  For example, an authorization protocol could mandate that the Authorization field be covered to protect the authorization credentials and mandate the signature parameters contain a "created" parameter, while an API expecting semantically relevant HTTP message content could require the Content-Digest header to be present and covered. </del> <ins> The set of covered-content and signature-params that are expected and required to be included in the covered components list.  For example, an authorization protocol could mandate that the Authorization field be covered to protect the authorization credentials and mandate the signature parameters contain a "created" parameter, while an API expecting semantically relevant HTTP message content could require the Content-Digest header to be present and covered as well as mandate a value for "context" that is specific to the API being protected. </ins> A means of retrieving the key material used to verify the signature.  An application will usually use the "keyid" parameter

Related discussion:
text: So cross-protocol attacks where the signature is presented as a message signature for a different message are mitigated by signing the semantically relevant components. (e.g., , or parts thereof, etc.) Attacks where the signature is presented as some other type of signature (i.e., not an HTTP message signature) are partially mitigated by the fact that the signature base includes the signature parameters, which is likely to distinguish it from content that may be signed in other contexts. For example, the format of the signature base means that an HTTP message signature cannot be passed off as a signature for a JWS. If the overall format and the footer is not already enough for this, I don't see how adding an additional parameter would help. If an attacker can mold the signature input in another context to match the HTTP message signature format as it is, it seems unlikely to me that adding to the end would help.
Hi NAME I'll start with your last paragraph. I agree what we have now is only partial mitigation. This kind of attacks is never fully mitigated, because you need to make assumptions on what implementations of a different, unknown protocol would do. But in general IMHO a unique prefix is a much better way to distinguish between signatures, because something further down in the signature base may be ignored by verifiers. Concretely, having a mandatory as the first line of the signature base would be a much better mitigation. Now back to the : again, we are talking about two different protocols, each of which may have both spec and implementation errors. Of course if both protocols are defined and implemented perfectly, the right fields would be covered and validated, and would also define unique semantics. Life is not perfect - people are lazy and will sign too few fields - and a context protects some protocols/implementations from others.
I'm not sure I buy this. If a non-HTTPSig consumer of signed content can be tricked into accepting as a valid message then I don't see why we should assume it would be any harder to get it to accept Okay, can we walk through the failure modes? An API that exposes multiple operations on different paths could fail to require callers to sign the target URI's path. In order for to help, it would have to be set to a unique value per operation, e.g., "ExampleApp.doExampleThing".