Code change:
We've been circling an answer to this for a while. The entire gamut of possible solutions is broad, and we haven't had much luck in reaching clarity here. One the one end of the scale, it should be perfectly OK to send a request for an origin over an authenticated TLS connection. But we still have the (entirely legitimate) concern there is that some servers might get themselves confused by this. The other end of the scale is the bells and whistles JSON stuff. NAME seemed OK with this based on his implementation experience, but it is a little complicated. We found too many corner cases for me to be happy that it implementations wouldn't end up busted. And now that we insist on authentication for the server, many of the features didn't make sense. We've also considered an HTTP/2 setting. That's appealing, but it does limit the applicability a little. This change aims more to the conservative end of that scale. It keeps the resource, but simplifies it, reducing it to a flat list of origins. The client only needs to acquire this from the authenticated server. This doesn't defend against Alt-Svc attacks mounted by attackers with the ability to both send header fields and run an authenticated server, but we're in a very strange place if this is the sort of capabilities we ascribe to our attackers in our threat models. I've explicitly added here. I believe that's reflective of consensus, but that part is easy to revert. The text about client certificates is now clearer.

Related discussion:
text: serving "http" URLs over TLS, clients are required to perform additional checks before directing "http" requests to it. <del> Clients MUST NOT send "http" requests over a connection with the "h2" protocol identifier, unless they have obtained a valid http- opportunistic response for an origin (as per well-known), and: </del> <ins> Clients MUST NOT send "http" requests over a secured connection, unless the chosen alternative service presents a certificate that is valid for the origin - as per RFC2818 (this also establishes "reasonable assurances" for the purposes of {RFC7838}}) - and they have obtained a valid http-opportunistic response for an origin (as per well-known). </ins> <del> The chosen alternative service presents a certificate that is valid for the origin, as per RFC2818 (this also establishes "reasonable assurances" for the purposes of {RFC7838}}), and The origin object of the http-opportunistic response has a `tls- ports' member, whose value is an array of numbers, one of which matches the port of the alternative service in question, and The chosen alternative service returns the same representation as the origin did for the http-opportunistic resource. For example, this request/response pair would allow reqeusts for the origin "http://www.example.com" to be sent to an alternative service on port 443 or 8000 of the host "www.example.com": </del> <ins> For example, assuming the following request is made over a TLS connection that is successfully authenticated for those origins, the following request/response pair would allow requests for the origins "http://www.example.com" or "http://example.com" to be sent using a secured connection: </ins> 2.2.