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>