Code change:
the covered components.  Single named parameters MAY occur in any order in the covered components. <del> The component value of a single named parameter is the "valueString" of the named query parameter defined by "application/x-www-form- urlencoded parsing" section of HTMLURL, which is the value after percent-encoded octets are decoded.  Note that this value does not include any leading "?" characters, equals sign "=", or separating "&" characters.  Named query parameters with an empty "valueString" are included with an empty string as the component value. </del> <ins> The component value of a single named parameter is calculated by the following process: Parse the "valueString" of the named query parameter defined by the "application/x-www-form-urlencoded parsing" section of HTMLURL, which is the value after percent-encoded octets are decoded Encode the "valueString" using the "percent-encode after encoding" process defined by the "application/x-www-form-urlencoded serializing" section of HTMLURL, which results in an ASCII string This ASCII string is the component value Note that this value does not include any leading "?" characters, equals sign "=", or separating "&" characters.  Named query parameters with an empty "valueString" have an empty string as the component value. </ins> If a query parameter is named as a covered component but it does not occur in the query parameters, this MUST cause an error in the

Related discussion:
text: Addresses encodings of signature component values for query parameters and field values.
: This seems to be inconsistent with Section 2.2.8 ("Query Parameters"), which could create non-ASCII component values.
FWIW, a query parameter (after application of URL) could contain CR, LF and other control characters.
So we likely need to serialize information extracted from query parameters using some kind of encoding; maybe an SF Byte Sequence.
This is tricky -- originally the query parameters were kept in percent-encoded form but from WG discussion we changed that to just use the unencoded value instead since several percent-encoded forms could be used. However it does look like the unencoded form could end up with problematic values here, so maybe we need to go back to that. I'd rather us use an encoding native to the value rather than inventing something to put on top of it, even trying to re-use the flag we've already got defined for headers.
And we did that because to extract query parameter values, we need a query parser, and that is defined the way it is. I believe that decision was good, we now just need to figure out out to transform the extracted values so that they can be used in the signature base. (And, FWIW, at the end we also should have an example for a case like that in the spec).
In 2.2.8, it might be good to mention that the referenced algorithm only supports query parameters using (percent-escaped) UTF-8 encoding (this came as a surprise to me because I assumed it works the same as the algorithm used for forms decoding).
in 2.1.3: What if the field value contains non-ASCII characters (from obs-text)? Of course that could be considered an error, but I believe the intention is to be able to represent anything here. So the text should refer to the field value as byte sequence, in which case the encoding step would not be needed.
This text was added in response to a comment about needing to know which encoding to put into the byte sequence input, and the commenter suggested ASCII as the base for it. If field values have a well-defined byte sequence that isn't ASCII characters only, then we should refer to whatever that is from the HTTP docs.
Well, field values in HTTP can be anything. It's obsolete, it's deprecated, but that's what it is.