Code change:
The mechanism for the intermediary to communicate this information to the upstream HTTP server is out of scope for this document. <del> 8. </del> <ins> 7. </ins> <del> Unprompted Authentication allows a user agent to authenticate to an origin server while guaranteeing freshness and without the need for the server to transmit a nonce to the user agent.  This allows the server to accept authenticated clients without revealing that it supports or expects authentication for some resources.  It also allows authentication without the user agent leaking the presence of authentication to observers due to clear-text TLS Client Hello extensions. </del> <ins> The Signature HTTP authentication scheme allows a user agent to authenticate to an origin server while guaranteeing freshness and without the need for the server to transmit a nonce to the user agent.  This allows the server to accept authenticated clients without revealing that it supports or expects authentication for some resources.  It also allows authentication without the user agent leaking the presence of authentication to observers due to clear-text TLS Client Hello extensions. </ins> The authentication proofs described in this document are not bound to individual HTTP requests; if the key is used for authentication <del> proofs on multiple requests they will all be identical.  This allows for better compression when sending over the wire, but implies that client implementations that multiplex different security contexts over a single HTTP connection need to ensure that those contexts cannot read each other's header fields.  Otherwise, one context would be able to replay the unprompted authentication header field of another.  This constraint is met by modern Web browsers.  If an attacker were to compromise the browser such that it could access another context's memory, the attacker might also be able to access the corresponding key, so binding authentication to requests would not provide much benefit in practice. Key material used for authentication in unprompted authentication, whether symmetric or asymmetric MUST NOT be reused in other protocols.  Doing so can undermine the security guarantees of the authentication. Origins offering Unprompted Authentication are able to link requests that use the same key for the Authentication Schemes provided. </del> <ins> proofs on multiple requests on the same connection, they will all be identical.  This allows for better compression when sending over the wire, but implies that client implementations that multiplex different security contexts over a single HTTP connection need to ensure that those contexts cannot read each other's header fields. Otherwise, one context would be able to replay the Authorization header field of another.  This constraint is met by modern Web browsers.  If an attacker were to compromise the browser such that it could access another context's memory, the attacker might also be able to access the corresponding key, so binding authentication to requests would not provide much benefit in practice. Key material used for the Signature HTTP authentication scheme MUST NOT be reused in other protocols.  Doing so can undermine the security guarantees of the authentication. Origins offering this scheme can link requests that use the same key. </ins> However, requests are not linkable across origins if the keys used <del> are specific to the individual origins using Unprompted Authentication. 9. 9.1. </del> <ins> are specific to the individual origins using this scheme. </ins> <del> This document will request IANA to register the following entry in the "HTTP Field Name" registry maintained at <<https://www.iana.org/assignments/http-fields>>: 9.2. This document, if approved, requests IANA to add two new entries to the "HTTP Authentication Schemes" Registry maintained at <<https://www.iana.org/assignments/http-authschemes>>.  Both entries have the Reference set to this document, and the Notes empty.  The Authentication Scheme Name of the entries are: </del> <ins> 8. </ins> <del> Signature </del> <ins> 8.1. </ins> <del> HMAC </del> <ins> This document, if approved, requests IANA to register the following entry in the "HTTP Authentication Schemes" Registry maintained at <<https://www.iana.org/assignments/http-authschemes>>: </ins> <del> 9.3. </del> <ins> 8.2. </ins> This document, if approved, requests IANA to register the following <del> entries in the "TLS Exporter Labels" registry maintained at </del> <ins> entry in the "TLS Exporter Labels" registry maintained at </ins> <<https://www.iana.org/assignments/tls-parameters#exporter-labels>>: <del> EXPORTER-HTTP-Unprompted-Authentication-Signature EXPORTER-HTTP-Unprompted-Authentication-HMAC Both of these entries are listed with the following qualifiers: </del>

Related discussion:
text: But I don't feel strongly about this one so I'm happy to not include it if it's the WG's preference.
Just saying here's a registry that you might could co-opt: URL Defined by URL
This is an existing registry of hash algorithms with string identifiers: URL Defined by URL
Discussed at IETF 116, sense of the room appeared to be that removing the HMAC feature entirely and switching to the TLS SignatureScheme registry for signatures was the simplest solution here.
OK wrote up to address this
Is there a technical reason why the header was not chosen for this draft? That can be sent without a corresponding challenge (in an unprompted way), as we note in the . It seems like that would work in this context, too.
Is this rather about using the Authorization header?
Yep!
NAME can you elaborate on "as we note in the "? I skimmed through that draft and it seems to clearly require a TokenChallenge before sending a Token.
I thought we had text that described it, but I can't find it. In any case, I think one can send the Authorization header unsolicited, so I think this draft ought to do that instead of rolling a new auth header.
Fair enough, let's discuss this at 116.
FWIW, I agree that unprompted "Authorization" is permissible in this context, but I think "Unprompted-Authorization" could be useful for clarity when reading logs, etc.
Discussed at IETF 116, sense of the room appeared to be that switching to Authorization made sense.
OK wrote up to address this