Original text:
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>  4. <del> This specification defines the following authentication parameters: </del>  4.1.

Reviewer comments:
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). That latter depends on how heavily people intend to lean on the intermediation case.
Discussed at IETF 116, sense of the room appeared to be that adding the key identifier and algorithm to the context made sense. We can skip URL and instead add realm, see
OK wrote up to address this
signatures are computed in a way that binds them to the origin which accepts the authenticator. While it's true that the nonce is a per-session concept, and the session is bound to a specific origin (by virtue of the TLS SNI), it seems possible for bugs to be introduced in settings where a TLS-terminating server supports more than one origin. Maybe the server accidentally sends an authenticator computed in a session for one origin to another, or something. I would follow in WebAuthn's footsteps here and sign something that's specific to the origin.
HTTPS sessions are not bound to a specific origin. There is no requirement for client to only use one origin on connection, and even if there was, TLS SNI is not fine-grained enough, as e.g. https://foo.example and https://foo.example:8443 are different origins, but have the same TLS SNI. Extending the idea of throwing some stuff into the context from httpwg/http-extensions, one could throw the origin (host/:authority) in as well (the contexts can be up to 65535 bytes, so there is plenty of space). This would bind the signatures to origin, would still work if host gets remapped somewhere, and could mitigate some tracking vectors. And it would still retain the no explicit configuration / no algorithm support property.
Oh, right, duh. We have connection coalescing! Throwing in the origin as you suggest seems like it work, and as in httpwg/http-extensions perhaps doing it above nonce generation is best.
Discussed at IETF 116, it seemed like the proposal most likely to succeed was to add the to the context
Regarding the question on , asking if origin and also URL should be part of the context. says, quote "unless specifically allowed by the authentication scheme, a single protection space cannot extend outside the scope of its server." So as NAME points out, we should include the origin. discusses the danger of using the same context for different URLs belonging to the same origin, pointing out that it is an problem that already exists and explaining the mitigations (such as not forwarding the Authorization header to the application running on top of HTTP). Assuming that we would switch to using the Authorization header, I think we can rely on that. To paraphrase, there is no need to include URL in the context. In addition, we can1 include "realm" in the Context, so that there can be multiple "protection spaces" inside one origin. In the Unprompted Authentication scheme, there is no way for a server to signal the realm to be used. Therefore, as NAME pointed out, there has to be a default value that would be defined by the specification. Clients and servers can agree out-of-band to use a different value. 1: During the meeting, I asked as a pure question how Realm is to be used. In the follow-on discussion at least assumed that "realm" has to be part of the Unprompted Authentication as it is to use the Authorization header. However, reading RFC 9110 I realize that not all authentication schemes are required to support realms (i.e., having multiple protection spaces within an origin). Hence the "can."
OK wrote up to address this
This is a good change, but to avoid future nit picking I might clarify what are the types of each field in the context. For example, is the port an integer in network byte order? What is the format of the host string? We just went through a whole kerfuffle in Privacy Pass on this point, and my advice would be to address it early.

Revised text:
3.  <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.  <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.