Code change:
response that they would have used for non-existent resources.  For example, this can mean using HTTP status code 404 (Not Found) instead of 401 (Unauthorized).  Such authentication failures can be caused <del> for example by: * absence of the Unprompted-Authentication field * failure to parse the Unprompted-Authentication field * use of Unprompted Authentication with an unknown key ID * failure to validate the signature or MAC. </del> <ins> for example by: * absence of the Authorization field * failure to parse the Authorization field * use of the Signature authentication scheme with an unknown key ID * failure to validate the signature. </ins> Such servers MUST also ensure that the timing of their request handling does not leak any information.  This can be accomplished by delaying responses to all non-existent resources such that the timing of the authentication verification is not observable. <del> 7. </del> <ins> 6. </ins> <del> Since the Signature and HMAC HTTP Authentication Schemes leverage TLS keying material exporters, their output cannot be transparently forwarded by HTTP intermediaries.  HTTP intermediaries that support this specification have two options: </del> <ins> Since the Signature HTTP authentication scheme leverages TLS keying material exporters, its output cannot be transparently forwarded by HTTP intermediaries.  HTTP intermediaries that support this specification have two options: </ins> The intermediary can validate the authentication received from the client, then inform the upstream HTTP server of the presence of

Related discussion:
text: 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.