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: 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.