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: Yes, you have it right. This is analogous to the JWT claim whose goal is to prevent cross-protocol (or really, cross-usage) attacks. So making this mandatory is important. I think mandating verification is nice in theory but I'm not sure it would be effective in practice. Instead, we could give guidance that makes it trivial to use, like in my example: include the protocol's name and possibly version. Just doing that would narrow the "blast radius" of cross-protocol attacks significantly. A "nonce" () is a well defined term. This is not a nonce. The on is weaker than I would like, but it's still a SHOULD for new types of JWTs. Here we have an opportunity to get it right from day one.
I appreciate the position, but what if the application is literally just "I am signing this message"? What would we put in that mandatory field that isn't either a random value or just "http"?
Then put the application/service name there, instead of a protocol name.
What's the application or service name, then? I don't think it's always as well defined as you're assuming it to be in practice.
It's guidance, not interoperable normative text. Whether people use "myapp" or "myapp/1" or even "myfile.c" doesn't matter all that much. Basically anything is better than a missing context.
If it's not interoperable normative text, then it has no business being a MUST here.
Existence and verification of the parameter are both normative. Its content is not.
NAME Could you provide an example attack scenario that cannot be mitigated by signing additional semantically relevant message components, and is mitigated by the addition of a parameter? The JWT claim is necessary because often there is nothing in a JWT that ties it to a particular message. This is a feature of JWTs, as it allows things like reusing JWT-formatted access tokens across multiple requests. I'm not familiar enough with TLS internals to say whether the same concept applies to the TLS "context string" parameter. In contrast, reuse across messages is not a use case for HTTP Message Signatures. If a signature is reusable across two semantically different messages, that would suggest to me that the signature is not covering the right message components.