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: Adds an optional parameter to signatures, to allow applications to signal specific usage between the signer and verifier. This PR does not add this to any examples yet, but we probably should if accepted.
NAME NAME I've walked the language in the definition back a bit and added it to an example. I think this is sufficient to include as a new feature.
[This came up at the IETF-113 session, credit to Jonathan Hoyland] A signature context mitigates oracle attacks, where a sender can be made to sign data that’s partly controlled by the attacker, and the signed string is then used for unexpected purposes, either within the same protocol or outside it. The context includes the higher level protocol that utilizes the signature mechanism, as well as other information such as sender and receiver identities. Signature context is used in TLS 1.3 (see RFC 8446, Sec. 4.4.3, “context string”) as well as the similar parameter in . The simplest way to add context to Message Signatures is as an additional parameter. We suggest that the context value should NOT be defined by this draft, but it should be mandatory to send, and mandatory to validate upon receipt. This prevents cross-protocol attacks but assumes that the higher level protocol is able to protect itself e.g. by ensuring that the receiver’s identity is included in the signed components. The context is fully defined by the higher level protocol, and no IANA registry is established for it. cc: NAME
Thanks for writing this up. I want to make sure I understand the request for addition: Define a signature parameter "context" as a string, whose content is outside the scope of this spec Define the use for this field aligned with the above Add a security considerations on the use of this in outside protocols I think this is a relatively light weight add, and I am ok with those pieces. Where I don't think I agree is the "mandatory to send and interpret" portion, if we're not going to define anything to put into the field. In this case is becomes just another value, right? I can see a lot of confusion in people trying to apply this without clear guidance. I would be fine with this field being recommended to send by the signer and mandatory to interpret by the verifier if it's present, and applications can make the field required and even have required values, like the example above.