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