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: That seems like way more work than just signing the right things. An app could fail to require all of an operation's inputs to be signed. In this case, the only way helps is if it is unique per request, e.g., a hash of all the operation inputs. This is definitely way more work than just signing the right things. Two apps could fail to require the request audience (e.g., the target URI authority) to be signed, allowing signatures to be replayed across them. Here only helps if it is set to something that is app specific. That rules out the use of standardized values based on protocol (e.g., ) or intent (e.g., ). And if is being set to something app-specific, why not just sign the app-specific thing that is already in the request? Are there other failure modes that I'm not considering, where would prove more useful? So far this leaves me feeling that is more likely to encourage bad habits and give implementers a false sense of security than it is to address any actual security risks.
I do not see how having a fixed signature prefix will solve any security issues with signature base generation. All the same problems with bad implementations occur internally in the signature base, the only difference is that you've got MAYBE a good first line -- and as NAME mentioned this is not stopping people from doing different bad things like having newlines in the content identifier. We can add a security or implementation considerations section on newlines in the signature base. Even then, I am failing to see how this prefix idea is related to the signature context concept. And as NAME said, apps failing to sign enough is an issue for the app. Having a signature context isn't going to magically get that necessary content signed, nor will it make a badly written verifier reject unsigned required content. Again, I'm fine with adding context as an optional parameter for applications that want to make use of it for signaling, but I don't think it solves things in the way that is being presented here.
Works for me. Thanks!