Code change:
3. <del> The user agent leverages a TLS keying material exporter KEY-EXPORT with the label "EXPORTER-HTTP-Signature-Authentication" to generate a 32-byte symmetric key.  That symmetric key is then used as nonce which can be signed using the client's chosen asymmetric private key. The resulting signature is then transmitted to the server using the Authorization field. </del> <ins> The user agent computes the authentication proof using a TLS keying material exporter KEY-EXPORT with the following parameters: the label is set to "EXPORTER-HTTP-Signature-Authentication" the context is set to the structure described in the exporter output length is set to 32 bytes (see output) 3.1. The TLS key exporter context is described in fig-context, using the notation from QUIC: The key exporter context contains the following fields: The Signature Algorithm and Port fields are encoded as unsigned 16-bit integers in network byte order.  The Key ID, Scheme, Host, and Real fields are length prefixed strings; they are preceded by a Length field that represents their length in bytes.  These length fields are encoded using the variable-length integer encoding from QUIC and MUST be encoded in the minimum number of bytes necessary. 3.2. The output of the exporter is a 32-byte symmetric key.  That symmetric key is then used as nonce which can be signed using the client's chosen asymmetric private key.  The resulting signature is then transmitted to the server using the Authorization field. </ins> 4. <del> This specification defines the following authentication parameters: </del> <ins> This specification defines the following authentication parameters. These parameters use structured fields (STRUCTURED-FIELDS) in their definition, even though the Authorization field itself does not use structured fields. </ins> 4.1.

Related discussion:
text: NAME that should already be covered by the last paragraph in this section. In particular the format is the Port is quite explicit there. Are you saying we should mention that strings are in ASCII?
No, sorry, I'm talking about the host name in particular. There was a long back and forth with Paul about the format of this field (is it the thing that appears in the HTTP request authority header, the thing that appears in the TLS SNI, etc), and we ended up being explicit. Just trying to save you some trouble down the road.
Oh, thanks. I agree we should be explicit. Could you point me to the specific text in Privacy Pass for this please?
Found the suggested Privacy Pass text and added to this PR.
I would recommend making the TLS exporter labels specific to the type of algorithm in use. For example, rather than use "EXPORTER-HTTP-Unprompted-Authentication-Signature" for signature-based authenticators, I might use "EXPORTER-HTTP-Unprompted-Authentication-Signature-Ed25519" for authenticators using Ed25519.
This would seem to have the drawback of making it complicated for intermediates to forward the authentication nonce. The alternative being for intermediary to implement the validation itself, which has its own drawbacks. Thinking why would one want to do something like this, I came up with vague ideas about possible cross-key tracking vectors. However, making labels algorithm-specific would not help if both keys happen to have the same type. One idea would be to mix the key id as context input, which would make the nonces be pretty much per-key in a way that is feasible for the first intermediary to calculate with no explicit algorithm support nor configuration.
An alternative proposal would be to just use a single context string for exporting the nonce but then somehow bind additional information into the signature computation at a higher layer. This would address the issue without complicating the intermediary story, I think.
Any case that involves intermediaries forwarding tokens will necessarily involve some amount of trust in the intermediary. The intermediary can provide the exporter output when it forwards the token, which would allow the signature to be verified, but the recipient is going to have to trust that this isn't copied from some other request. I definitely think that the context string is the right place to include origin, key identifier, algorithm choice, and maybe even some context from the request (URL).