Original text:
4. <del> The "Signature" HTTP header provides a mechanism to attach a signature to the HTTP message from which it was generated.  The header field name is "Signature" and its value is a list of parameters and values, formatted according to the "signature" syntax defined below, using the Augmented Backus-Naur Form (ABNF) notation defined in RFC5234 notation, with extensions defined in HTTP. Each "sig-param" is the name of a parameter defined in the param- registry defined in this document.  The initial contents of this registry are described in params. </del>  4.1.  <del> RECOMMENDED.  The algorithm parameter contains the name of the signature's Algorithm, as registered in the HTTP Signature Algorithms Registry defined by this document.  Verifiers MUST determine the signature's Algorithm from the "keyId" parameter rather than from "algorithm".  If "algorithm" is provided and differs from or is incompatible with the algorithm or key material identified by "keyId" (for example, "algorithm" has a value of "rsa-sha256" but "keyId" identifies an EdDSA key), then implementations MUST produce an error.  Implementers should note that previous versions of this specification determined the signature's Algorithm using the algorithm parameter only, and thus could be utilized by attackers to expose security vulnerabilities. The default value for this parameter is "hs2019". RECOMMENDED.  The created parameter contains the signature's Creation Time, expressed as the canonicalized value of the "(created)" content identifier, as defined in Section 2.  If not specified, the signature's Creation Time is undefined.  This parameter is useful when signers are not capable of controlling the Date HTTP Header such as when operating in certain web browser environments. </del>  <del> OPTIONAL.  The expires parameter contains the signature's Expiration Time, expressed as the canonicalized value of the "(expires)" content identifier, as defined in Section 2.  If the signature does not have an Expiration Time, this parameter MUST be omitted.  If not specified, the signature's Expiration Time is undefined. </del>  <del> OPTIONAL.  The headers parameter contains the signature's Covered Content, expressed as a string containing a quoted list of the identifiers in the list, in the order they occur in the list, with a space " " between each identifier.  If specified, identifiers for header fields SHOULD be lowercased and all others MUST be lowercased.  The default value for this parameter is "(created)". </del>  <del> REQUIRED.  The "keyId" parameter is a US-ASCII string whose value can be used by a verifier to identify and/or obtain the signature's Verification Key Material.  The format and semantics of this value are out of scope for this document. </del>  <del> REQUIRED.  The signature parameter contains the signature value, as described in sign-sig-input. </del>  4.2. <del> The following is a non-normative example Signature header field representing the signature in example-sig-value: </del>  5.

Reviewer comments:
Replaced unstructured header with and Dictionary Structured Header Fields. Defined content identifiers for individual Dictionary members, e.g., . Defined content identifiers for first N members of a List, e.g., . A signature in a request now looks like this:
I like this PR! We just need some tweaks, but it greatly improves the way the spec can be used.
This PR also fixes . Should we remove that appendix in this PR?
Redefine the Signature header field to use . This will simplify both the definition and the parsing of this header field value.
The Covered Content list, Algorithm, and Verification Key identifier should all be part of the Signature Input, to protect against malicious changes.
The Covered Content list contains identifiers for more than just headers, so the parameter name is no longer appropriate. Some alternatives: "content", "signed-content", "covered-content".
I like the direction this PR is taking: spec is more focused because it outsources spec of field format to draft-kamp-httpbis-structure dictionary format is more flexible and allows multiple signatures (important)

Revised text:
4.  <ins> Message signatures can be included within an HTTP message via the "Signature-Input" and "Signature" HTTP header fields, both defined within this specification.  The "Signature" HTTP header field contains signature values, while the "Signature-Input" HTTP header field identifies the Covered Content and metadata that describe how each signature was generated. </ins> 4.1. <ins> The "Signature-Input" HTTP header field is a Dictionary Structured Header StructuredFields containing the metadata for zero or more message signatures generated from content within the HTTP message. Each member describes a single message signature.  The member's name is an identifier that uniquely identifies the message signature within the context of the HTTP message.  The member's value is the message signature's Covered Content, expressed as a List of Tokens. Further signature metadata is expressed in parameters on the member value, as described below. 4.1.1. </ins>  <ins> The parameters on each "Signature-Input" member value contain metadata about the signature.  Each parameter name MUST be a parameter name registered in the IANA HTTP Signatures Metadata Parameters Registry defined in param-registry of this document.  This document defines the following parameters, and registers them as the initial contents of the registry: </ins>  <ins> RECOMMENDED.  The "alg" parameter is a Token containing the name of the signature's Algorithm, as registered in the HTTP Signature Algorithms Registry defined by this document.  Verifiers MUST determine the signature's Algorithm from the "keyId" parameter rather than from "alg".  If "alg" is provided and differs from or is incompatible with the algorithm or key material identified by "keyId" (for example, "alg" has a value of "rsa-sha256" but "keyId" identifies an EdDSA key), then implementations MUST produce an error. </ins>  <ins> RECOMMENDED.  The "created" parameter is a Decimal containing the signature's Creation Time, expressed as the canonicalized value of the "*created" content identifier, as defined in Section 2.  If not specified, the signature's Creation Time is undefined.  This parameter is useful when signers are not capable of controlling the Date HTTP Header such as when operating in certain web browser environments. </ins>  <ins> OPTIONAL.  The "expires" parameter is a Decimal containing the signature's Expiration Time, expressed as the canonicalized value of the "*expires" content identifier, as defined in Section 2.  If the signature does not have an Expiration Time, this parameter MUST be omitted.  If not specified, the signature's Expiration Time is undefined. </ins>  <ins> REQUIRED.  The "keyId" parameter is a String whose value can be used by a verifier to identify and/or obtain the signature's Verification Key Material.  Further format and semantics of this value are out of scope for this document. </ins> 4.2.  <ins> The "Signature" HTTP header field is a Dictionary Structured Header StructuredFields containing zero or more message signatures generated from content within the HTTP message.  Each member's name is a signature identifier that is present as a member name in the "Signature-Input" Structured Header within the HTTP message.  Each member's value is a Byte Sequence containing the signature value for the message signature identified by the member name.  Any member in the "Signature" HTTP header field that does not have a corresponding member in the HTTP message's "Signature-Input" HTTP header field MUST be ignored. 4.3. The following is a non-normative example of "Signature-Input" and "Signature" HTTP header fields representing the signature in example- sig-value: Since "Signature-Input" and "Signature" are both defined as Dictionary Structured Headers, they can be used to easily include multiple signatures within the same HTTP message.  For example, a signer may include multiple signatures signing the same content with different keys and/or algorithms to support verifiers with different capabilities, or a reverse proxy may include information about the client in header fields when forwarding the request to a service host, and may also include a signature over those fields and the client's signature.  The following is a non-normative example of header fields a reverse proxy might add to a forwarded request that contains the signature in the above example: </ins> 5.