Original text:
The mechanism for the intermediary to communicate this information to the upstream HTTP server is out of scope for this document. <del> 8. </del>  <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>  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>  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>  <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>  <del> Signature </del>  <del> HMAC </del>  <del> 9.3. </del>  This document, if approved, requests IANA to register the following <del> entries in the "TLS Exporter Labels" registry maintained at </del>  <<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>

Reviewer comments:
From Ilari Liusvaara on the : From NAME on the :
Maybe also consider for identification. That's not perfect, because of the "none" thing, but it might be a better fit. The TLS schemes are generally OK provided that you only use the recommended ones (of which there aren't many).
I don't love JWA since , but using TLS SignatureScheme with a requirement to only use the recommended ones sounds good to me.
NAME Doesn't it define the algorithm and then define the subkey types and in ?
NAME that could be made to work though it's quite clunky since it requires a separate string parameter for "alg". Overall I think the is a much better fit for signatures here. We already tightly integrate with TLS but not JWA. All that said, the closest option for hashes is the and that's been orphaned by RFC 8447. At this point I guess we should bite the bullet and define a new registry. Perhaps we include as current values: hmac-sha256 hmac-sha384 hmac-sha512 signature-rsapkcs1sha256 signature-rsapkcs1sha384 signature-rsapkcs1sha512 signature-ecdsasecp256r1sha256 signature-ecdsasecp384r1sha384 signature-ecdsasecp521r1sha512 signature-rsapssrsaesha256 signature-rsapssrsaesha384 signature-rsapssrsaesha512 signature-rsapsspsssha256 signature-rsapsspsssha384 signature-rsapsspsssha512 signature-ed25519 signature-ed448 Of course this requires to paint the bikeshed one of two colors: HMAC and Signatures in the same registry, using a single new auth scheme Separate registries, using separate auth schemes Thoughts? At this point I suspect this issue will need WG discussion at IETF 116.
I had to implement rsapsspss_shaX algorithms to produce test vectors for DCs, and unless there's a really compelling reason to include them, I'd really rather not. They're just such a pain to use, and the support for them is very poor (thus me needing to implement them).
FWIW, adding an entry in the registry doesn't mean it'll be mandatory to implement so there's not much of a cost. 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

Revised text:
The mechanism for the intermediary to communicate this information to the upstream HTTP server is out of scope for this document.  <ins> 7. </ins>  <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  <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  <ins> are specific to the individual origins using this scheme. </ins>  <ins> 8. </ins>  <ins> 8.1. </ins>  <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>  <ins> 8.2. </ins> This document, if approved, requests IANA to register the following  <ins> entry in the "TLS Exporter Labels" registry maintained at </ins> <<https://www.iana.org/assignments/tls-parameters#exporter-labels>>: