Original text:
2. <del> This document only defines the Signature and HMAC authentication schemes for uses of HTTP with TLS TLS.  This includes any use of HTTP over TLS as typically used for HTTP/2 H2, or HTTP/3 H3 where the transport protocol uses TLS as its authentication and key exchange mechanism QUIC-TLS. </del>  <del> The user agent leverages a TLS keying material exporter KEY-EXPORT to generate a nonce which can be signed using the chosen key.  The keying material exporter uses a label that starts with the characters "EXPORTER-HTTP-Unprompted-Authentication-" (see schemes for the labels and contexts used by each scheme).  The TLS keying material exporter is used to generate a 32-byte key which is then used as a nonce. </del>  Because the TLS keying material exporter is only secure for authentication when it is uniquely bound to the TLS session RFC7627, <del> the Signature and HMAC authentication schemes require either one of the following properties: </del>  The TLS version in use is greater or equal to 1.3 TLS. <del> The TLS version in use is greater or equal to 1.2 and the Extended Master Secret extension RFC7627 has been negotiated. </del>  <del> Clients MUST NOT use the Signature and HMAC authentication schemes on </del>  connections that do not meet one of the two properties above.  If a <del> server receives a request that uses these authentication schemes on a </del>  connection that meets neither of the above properties, the server MUST treat the request as malformed. 3. <del> The "Unprompted-Authentication" header field allows a user agent to authenticate with an origin server.  The authentication is scoped to the HTTP request associated with this header field.  The value of the Unprompted-Authentication header field is a credentials object, as defined in HTTP.  Credentials contain an authentication scheme followed by optional authentication parameters. </del>  4. <del> This specification defines the following authentication parameters, they can be used by the authentication schemes defined in schemes. </del>  4.1. <del> The OPTIONAL "k" (key ID) parameter is a byte sequence that </del>  identifies which key the user agent wishes to use to authenticate. This can for example be used to point to an entry into a server-side database of known keys. 4.2. <del> The OPTIONAL "p" (proof) parameter is a byte sequence that specifies </del>  the proof that the user agent provides to attest to possessing the credential that matches its key ID. 4.3. <del> The OPTIONAL "s" (signature) parameter is an integer that specifies the signature algorithm used to compute the proof transmitted in the "p" directive.  Its value is an integer between 0 and 255 inclusive from the IANA "TLS SignatureAlgorithm" registry maintained at <<https://www.iana.org/assignments/tls-parameters#tls-parameters- 16>>. 4.4. The OPTIONAL "h" (hash) parameter is an integer that specifies the hash algorithm used to compute the proof transmitted in the "p" directive.  Its value is an integer between 0 and 255 inclusive from the IANA "TLS HashAlgorithm" registry maintained at <<https://www.iana.org/assignments/tls-parameters#tls-parameters- 18>>. 5. This document defines the "Signature" and "HMAC" HTTP authentication schemes. 5.1. The "Signature" HTTP Authentication Scheme uses asymmetric cryptography.  User agents possess a key ID and a public/private key pair, and origin servers maintain a mapping of authorized key IDs to their associated public keys.  When using this scheme, the "k", "p", and "s" parameters are REQUIRED.  The TLS keying material export label for this scheme is "EXPORTER-HTTP-Unprompted-Authentication- Signature" and the associated context is empty.  The nonce is then signed using the selected asymmetric signature algorithm and transmitted as the proof directive. </del>  For example, the key ID "basement" authenticating using Ed25519 ED25519 could produce the following header field (lines are folded to fit): <del> 5.2. The "HMAC" HTTP Authentication Scheme uses symmetric cryptography. User agents possess a key ID and a secret key, and origin servers maintain a mapping of authorized key IDs to their associated secret key.  When using this scheme, the "k", "p", and "h" parameters are REQUIRED.  The TLS keying material export label for this scheme is "EXPORTER-HTTP-Unprompted-Authentication-HMAC" and the associated context is empty.  The nonce is then HMACed using the selected HMAC algorithm and transmitted as the proof directive. For example, the key ID "basement" authenticating using HMAC-SHA-512 SHA could produce the following header field (lines are folded to fit): 5.3. The HTTP Authentication Scheme registry maintained by IANA at <<https://www.iana.org/assignments/http-authschemes/http- authschemes.xhtml>> contains entries not defined in this document. Those entries MAY be used with Unprompted Authentication. 6. </del>  Servers that wish to introduce resources whose existence cannot be probed need to ensure that they do not reveal any information about

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:
2.  <ins> This document defines the "Signature" HTTP authentication scheme.  It uses asymmetric cryptography.  User agents possess a key ID and a public/private key pair, and origin servers maintain a mapping of authorized key IDs to their associated public keys. </ins>  <ins> This authentication scheme is only defined for uses of HTTP with TLS TLS.  This includes any use of HTTP over TLS as typically used for HTTP/2 H2, or HTTP/3 H3 where the transport protocol uses TLS as its authentication and key exchange mechanism QUIC-TLS. </ins> Because the TLS keying material exporter is only secure for authentication when it is uniquely bound to the TLS session RFC7627,  <ins> the Signature authentication scheme requires either one of the following properties: </ins> The TLS version in use is greater or equal to 1.3 TLS.  <ins> The TLS version in use is 1.2 and the Extended Master Secret extension RFC7627 has been negotiated. </ins>  <ins> Clients MUST NOT use the Signature authentication scheme on </ins> connections that do not meet one of the two properties above.  If a  <ins> server receives a request that uses this authentication scheme on a </ins> connection that meets neither of the above properties, the server MUST treat the request as malformed. 3.  <ins> 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. </ins> 4.  <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.  <ins> The REQUIRED "k" (key ID) parameter is a byte sequence that </ins> identifies which key the user agent wishes to use to authenticate. This can for example be used to point to an entry into a server-side database of known keys. 4.2.  <ins> The REQUIRED "p" (proof) parameter is a byte sequence that specifies </ins> the proof that the user agent provides to attest to possessing the credential that matches its key ID. 4.3.  <ins> The REQUIRED "s" (signature) parameter is an integer that specifies the signature scheme used to compute the proof transmitted in the "p" directive.  Its value is an integer between 0 and 65535 inclusive from the IANA "TLS SignatureScheme" registry maintained at <<https://www.iana.org/assignments/tls-parameters/tls- parameters.xhtml#tls-signaturescheme>>. </ins> For example, the key ID "basement" authenticating using Ed25519 ED25519 could produce the following header field (lines are folded to fit):  <ins> 5. </ins> Servers that wish to introduce resources whose existence cannot be probed need to ensure that they do not reveal any information about