...as one who had authority
[This post was started at IETF 104, and since IETF 105 is in a few weeks, I figure I'd better finish it.]
There's an ongoing discussion in the HTTP community over what constitutes authority for an origin. The URI identifies a resource using a scheme (https), host (www.evequefou.be), port (:443) and path (/about). For a long time, HTTP authority was simple: That host, at that TCP port, using that protocol was authoritative.
Different hosts clearly aren't authoritative. Different ports aren't authoritative, even on the same host. Perhaps surprising to some, different protocols aren't authoritative, even on the same port. (That is, https://www.example.com:8080/ and http://www.example.com:8080/ are different authorities.)
But the question of authority is misleading. Any client can ask any server for any resource. That's supported by the "absolute-form" in an HTTP/1.x request line, or any HTTP/2 or HTTP/3 request. It can ask the server for something on a different host, or port, or even scheme. That's not just sending a request for http://www.example.com over TLS to TCP port 443, as described in RFC 8164; you can technically send a request for any scheme -- even xboxliveapp-1297287741:// -- and see whether the server wants to play a game. (Try it on Windows 10.)
It's worth noting that HTTP explicitly uses URLs, not just URIs. RFC 3986 describes URLs as "the subset of URIs that, in addition to identifying a resource, provide a means of locating the resource by describing its primary access mechanism (e.g., its network "location")." (Emphasis added.) That is, from an HTTP URL, you can determine at least some of the ways you might retrieve that resource. Perhaps not all – but some.
Authority is really a two-fold question. First, and simpler: Does the server know how to handle the request? An HTTP proxy will take a request that isn't for its own resources, act as a client, and fetch the resource in question on behalf of the client. If it has a cache, it might return a cached resource to the client. But more complicated, does the client trust the server? That is, if the server does return a response, does the client think the server's response is an accurate representation of the resource at the URI it requested? Given that the content of requests can be sensitive, how does the client feel confident that it's sending the request only to the authorized party?
For a long time, this answer has been simple – you connect to the specified host over TCP on the specified port, and if using HTTPS, check the resulting certificate in the TLS handshake. The certificate check helps protect you against a corruption of DNS or IP routing; the DNS check helps protect you against a misissued or compromised certificate.
But we've been stretching the definition of authority in recent years. RFC 7838 enables one authoritative server to delegate to others via Alt-Svc – and perhaps more disturbingly, enables those other authoritative servers to delegate further if they desire. RFC 8336 enables a server to assert its authority over other origins based solely on its certificate via the ORIGIN frame, without any DNS or IP verification (though you are cautioned to require stricter verification on the certificate first). All of these are ways that other access methods to the same resource might be discovered, and the client has to make a judgement call about whether to trust these new sources.
And HTTP/3? Well, that's UDP. All bets are off, now aren't they?
An HTTP/3-only client might not even have a TCP stack, though this is an unlikely hypothetical in the near-term. So, given that the origin for an https URI is "governed by a potential HTTP origin server listening to a given TCP port for TLS-secured connections," such a client would be entirely unable to reach the "primary access mechanism" specified by the URL. An HTTP/3-only server gets even uglier.
So far, the answer seems to be stricter verification on certificates (SCT to verify Certificate Transparency publication; OCSP stapling) and a declaration that all authority in TCP and on UDP has been given unto whoever holds that certificate.