Original text:
2.2.  The signature's Creation Time (signature-metadata) is identified by <del> the "(created)" identifier. </del>  Its canonicalized value is an Integer String containing the signature's Creation Time expressed as the number of seconds since

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:
2.2. <ins> An individual member in the value of a Dictionary Structured Field is identified by the lowercased field name, followed by a semicolon "":"", followed by the member name.  An individual member in the value of a Dictionary Structured Field is canonicalized by applying the serialization algorithm described in Section 4.1.2 of StructuredFields on a Dictionary containing only that member. 2.2.1. This section contains non-normative examples of canonicalized values for Dictionary Structured Field Members given the following example header field, whose value is assumed to be a Dictionary: The following table shows example canonicalized values for different content identifiers, given that field: 2.3. A prefix of a List Structured Field consisting of the first N members in the field's value (where N is an integer greater than 0 and less than or equal to the number of members in the List) is identified by the lowercased field name, followed by a semicolon "":"", followed by N expressed as an Integer String.  A list prefix is canonicalized by applying the serialization algorithm described in Section 4.1.1 of StructuredFields on a List containing only the first N members as specified in the list prefix, in the order they appear in the original List. 2.3.1. This section contains non-normative examples of canonicalized values for list prefixes given the following example header fields, whose values are assumed to be Dictionaries: The following table shows example canonicalized values for different content identifiers, given those fields: 2.4. </ins> The signature's Creation Time (signature-metadata) is identified by  <ins> the "*created" identifier. </ins> Its canonicalized value is an Integer String containing the signature's Creation Time expressed as the number of seconds since