Code change:
3.3. <del> A templated TCP proxy has an unambiguous origin of its own.  Origin- scoped HTTP header fields such as "Alt-Svc" RFC7838 and "Strict- Transport-Security" RFC6797 apply to this origin when they are associated with a templated TCP proxy request or response. </del> <ins> 3.3.1. Ordinary HTTP headers apply only to the single resource identified in the request or response.  An origin-scoped HTTP header is a special response header that is intended to change the client's behavior for subsequent requests to any resource on this origin. Unlike classic HTTP CONNECT proxies, a templated TCP proxy has an unambiguous origin of its own.  Origin-scoped headers apply to this origin when they are associated with a templated TCP proxy response. Here are some origin-scoped headers that could potentially be sent by a templated TCP proxy: "Alt-Svc" "Strict-Transport-Security" "Public-Key-Pins" "Accept-CH" "Set-Cookie" RFC6265, which has configurable scope. "Clear-Site-Data" 3.3.2. Authentication to a templated TCP proxy normally uses ordinary HTTP authentication via the "401 (Unauthorized)" response code, the "WWW- Authenticate" response header field, and the "Authorization" request header field (RFC9110).  A templated TCP proxy does not use the "407 (Proxy Authentication Required)" response code and related header fields (RFC9110) because they do not traverse HTTP gateways (see operational-considerations). Clients SHOULD assume that all proxy resources generated by a single template share a protection space (i.e., a realm) (RFC9110).  For many authentication schemes, this will allow the client to avoid waiting for a "401 (Unauthorized)" response before each new connection through the proxy. </ins> 4.

Related discussion:
text: Related to and HTTP request proxies use "Proxy-Authenticate" in order to distinguish proxy authentication from destination authentication ("WWW-Authenticate") in the mixed bag of headers that is presented to the proxy. Classic HTTP CONNECT proxies don't have that problem, but they still use "Proxy-Authenticate", probably just for consistency. The MASQUE RFCs don't say anything about which authentication headers to use. "connect-tcp" and MASQUE should definitely follow the same rules, whatever they are. NAME noted that RFC 9110 says "the Proxy-Authenticate header field applies only to the next outbound client on the response chain". This implies that a general-purpose gateway is not expected to forward Proxy-Authenticate headers. However, there is actually no such thing as a general-purpose gateway for Extended CONNECT, so this seems somewhat moot. Personally, I think that our guidance should probably also line up with what we want to say for which is (in my view, despite some authors' protestations) a modernized HTTP request proxy.
An interesting related question is whether MASQUEish resources can be authenticated with other methods, like cookies and bearer tokens. If so, I think they are essentially "content-like" and should probably use WWW-Authenticate. If not, they are essentially distinct, and could conveniently be marked as such with "Proxy-Authenticate". Or perhaps they are both, depending on the context...
I somewhat think it's both — it's content and the proxy.
NAME Thank you for opening the issue. If we are to consider extended CONNECT gateways as proxies, then the question would be what the URI of the connect-tcp request means. RFC 9110 says that target URI specifies the origin. It is only because all the existing extended CONNECT family deals with origins that the TLS handshakes to those servers implementing the extended CONNECT family can be validated using certificates issued for that origin. To conclude, to me in seems that the use of WWW-Authenticate is mandated by the using URI as the target. PS. Note also that RFC 8441 specifically explains how proxies can be used between the client and the extended CONNECT target, see .
I don't think anything is really mandated. Within the current language of RFC 9110, I think we are free to choose either interpretation.