Code change:
: "value" <del> And the following signature base lines: </del> <ins> And the following signature base lines, with (SP) indicating a single trailing space character before the empty component value: </ins> <del> If a parameter name occurs multiple times in a request, all parameter values of that name MUST be included in separate signature base lines in the order in which the parameters occur in the target URI.  Note that in some implementations, the order of parsed query parameters is not stable, and this situation could lead to unexpected results.  If multiple parameters are common within an application, it is </del> <ins> This derived component has some limitations.  Specifically, the algorithm in HTMLURL only supports query parameters using percent- escaped UTF-8 encoding.  Other encodings are not supported. Additionally, multiple instances of a named parameter are not reliably supported in the wild.  If a parameter name occurs multiple times in a request, the named query parameter MUST NOT be included. If multiple parameters are common within an application, it is </ins> RECOMMENDED to sign the entire query string using the "@query" component identifier defined in content-request-query. <ins> The encoding process allows query parameters that include newlines or other problematic characters in their values, or with alternative encodings such as using the plus character to represent spaces.  For the query parameters in this message: The resulting values are encoded as follows: If the encoding were not applied, the resultant value would be: This base string violates the constraints on component values, and is therefore invalid. </ins> 2.2.9. The "@status" derived component refers to the three-digit numeric

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.