Change:
The definition of how you determine a certificate matches an origin isn't specific to reuse, so it belongs in the description of establishing a connection. 3.4 now just says that the certificate needs to also be authoritative for any other origins you want to reuse the connection for. The issue also suggested making this easier to understand, so I'd appreciate suggestions for greater clarity without losing the specifics.
Hilarie Orman wrote: >The only problem that I have is that the authentication model for QUIC-HTTP is not explicitly spelled out. The only discussion is in section 3.4 Connection Reuse, and although that section may be technically correct, I find it hard to understand.
For server authentication, which I think is what you're getting at here, 3.2 also mentions the concept of establishing authority, but doesn't go into much detail. I suspect the specifics of comparing a certificate should move to 3.2. I'd appreciate suggestions for making it easier to understand.
Seems fine.This LGTM. It's clear.

Discussion:
The "https" scheme associates authority with possession of a certificate that the client considers to be trustworthy for the host <del> identified by the authority component of the URL.  If a server presents a certificate and proof that it controls the corresponding private key, then a client will accept a secured TLS session with that server as being authoritative for all origins with the "https" scheme and a host identified in the certificate. </del> <ins> identified by the authority component of the URL. If a server presents a valid certificate and proof that it controls the corresponding private key, then a client will accept a secured TLS session with that server as being authoritative for all origins with the "https" scheme and a host identified in the certificate. The host must be listed either as the CN field of the certificate subject or as a dNSName in the subjectAltName field of the certificate; see RFC6125.  For a host that is an IP address, the client MUST verify that the address appears as an iPAddress in the subjectAltName field of the certificate. If the hostname or address is not present in the certificate, the client MUST NOT consider the server authoritative for origins containing that hostname or address.  See Section 4.3 of SEMANTICS for more detail on authoritative access. </ins> A client MAY attempt access to a resource with an "https" URI by resolving the host identifier to an IP address, establishing a QUIC

Once a connection exists to a server endpoint, this connection MAY be reused for requests with multiple different URI authority components. <del> In general, a server is considered authoritative for all URIs with the "https" scheme for which the hostname in the URI is present in the authenticated certificate provided by the server, either as the CN field of the certificate subject or as a dNSName in the subjectAltName field of the certificate; see RFC6125.  For a host that is an IP address, the client MUST verify that the address appears as an iPAddress in the subjectAltName field of the certificate.  If the hostname or address is not present in the certificate, the client MUST NOT consider the server authoritative for origins containing that hostname or address.  See Section 4.3 of SEMANTICS for more detail on authoritative access. </del> Clients SHOULD NOT open more than one HTTP/3 connection to a given host and port pair, where the host is derived from a URI, a selected alternative service (ALTSVC), or a configured proxy.  A client MAY