Code change:
<del> HTTP Unprompted Authentication </del> <ins> The Signature HTTP Authentication Scheme </ins> draft-ietf-httpbis-unprompted-auth-latest Abstract <del> Existing HTTP authentication mechanisms are probeable in the sense that it is possible for an unauthenticated client to probe whether an </del> <ins> Existing HTTP authentication schemes are probeable in the sense that it is possible for an unauthenticated client to probe whether an </ins> origin serves resources that require authentication.  It is possible for an origin to hide the fact that it requires authentication by not generating Unauthorized status codes, however that only works with <del> non-cryptographic authentication schemes: cryptographic schemes (such as signatures or message authentication codes) require a fresh nonce to be signed, and there is no existing way for the origin to share such a nonce without exposing the fact that it serves resources that require authentication.  This document proposes a new non-probeable cryptographic authentication scheme. </del> <ins> non-cryptographic authentication schemes: cryptographic signatures require a fresh nonce to be signed, and there is no existing way for the origin to share such a nonce without exposing the fact that it serves resources that require authentication.  This document proposes a new non-probeable cryptographic authentication scheme. </ins> 1. <del> Existing HTTP authentication mechanisms (see HTTP) are probeable in the sense that it is possible for an unauthenticated client to probe </del> <ins> Existing HTTP authentication schemes (see HTTP) are probeable in the sense that it is possible for an unauthenticated client to probe </ins> whether an origin serves resources that require authentication.  It is possible for an origin to hide the fact that it requires authentication by not generating Unauthorized status codes, however that only works with non-cryptographic authentication schemes: <del> cryptographic schemes (such as signatures or message authentication codes) require a fresh nonce to be signed, and there is no existing way for the origin to share such a nonce without exposing the fact that it serves resources that require authentication.  This document proposes a new non-probeable cryptographic authentication scheme. Unprompted Authentication serves use cases in which a site wants to offer a service or capability only to "those who know" while all others are given no indication the service or capability exists.  The conceptual model is that of a "speakeasy".  "Knowing" is via an externally-defined mechanism by which keys are distributed.  For example, a company might offer remote employee access to company </del> <ins> cryptographic signatures require a fresh nonce to be signed, and there is no existing way for the origin to share such a nonce without exposing the fact that it serves resources that require authentication.  This document proposes a new non-probeable cryptographic authentication scheme. The Signature HTTP authentication scheme serves use cases in which a site wants to offer a service or capability only to "those who know" while all others are given no indication the service or capability exists.  The conceptual model is that of a "speakeasy".  "Knowing" is via an externally-defined mechanism by which keys are distributed. For example, a company might offer remote employee access to company </ins> services directly via its website using their employee credentials, or offer access to limited special capabilities for specific employees, while making discovering (probing for) such capabilities

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