Code change:
empty "valueString" are included with an empty string as the component value. <del> If a parameter name occurs multiple times in a request, all parameter values of that name MUST be included in separate signature input lines in the order in which the parameters occur in the target URI. </del> <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 signature input string generation. </ins> For example for the following request: Indicating the "baz", "qux" and "param" named query parameters in would result in the following "@query-param" value: <ins> If a parameter name occurs multiple times in a request, all parameter values of that name MUST be included in separate signature input 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 RECOMMENDED to sign the entire query string using the "@query" component identifier defined in content-request-query. </ins> If used in a related-response, the "@query-params" component identifier refers to the associated component value of the request that triggered the response message being signed.

Related discussion:
text: Includes several document cleanups for signatures, to publish as -09
Also: If there is no query string should the corresponding signing text be or ie. should the query value be empty or just consist of one Should we return with this request and return on this request This is what I opted for in my implementation. See shows that http4s makes the distinction between blank queries and empty queries is simpler I think this is a corner case that is worth explicating very clearly, perhaps even with a test.
There are quite a few occurrences of the header in the draft. From an implementation point of view, Go "swallows" the header and it is not part of the standard Request structure. There's a good reason for the Go library to do it, and in fact the draft recommends to use NAME instead. Can we remove from examples, e.g. Sec. 2.1, so we don't train people to do the wrong thing?
There are only a couple instances of the "host" header in the current draft left, and one of them (section 2.1) is specifically about how to format headers. It could be removed from the other example signature input strings without affecting anything negatively. Same with the "date" header, which could be confused with the "created" parameter, see
This sentence is correct: But it's true for most reasonable uses of , and people will still be using this parameter. So why not add:
No, we explicitly did not want to conflate this with the jwa registry. We also didn't want to have a second tier choice like having "alg=jose" and then having the actual algorithm elsewhere, since a big problem with late editions of the Cavage draft were exactly that process. (See the mess around "hs2019"). The editors discussed this at length and decided the best compromise was to define a way that jwa algorithms could be used in an interoperable fashion, but not to allow runtime signaling with them. Better to have the choice of jwa be signaled within the application level. Additionally, it's preferable to not use the runtime parameter to signal the algorithm any way, which is discussed at length in the security considerations.
All good, so why aren't you using normative language?
It's not normative because this section defines the algorithms, not the parameter.