Taking a bash at what it means to be authoritative for #405.

draft-ietf-httpbis-http2.xml

@@ -3055,12 +3055,11 @@ HTTP2-Settings    = token68
           </t>
 
           <t>
-            Clients receiving a pushed response MUST validate that the server is authorized to push
-            it using the same-origin policy (<xref target="RFC6454" x:fmt=","
-            x:sec="3"/>).  For example, an HTTP/2 connection to <spanx
-            style="verb">example.com</spanx> is generally <cref>Ed: weaselly use of "generally",
-            needs better definition</cref> not permitted to push a response for <spanx
-            style="verb">www.example.org</spanx>.
+            Clients receiving a pushed response MUST validate that the server is authorized to
+            provide the response, see <xref target="authority"/>.  For example, an server that
+            offers a certificate for only the <spanx style="verb">example.com</spanx> DNS-ID or
+            Common Name is not permitted to push a response for <spanx
+            style="verb">https://www.example.org/doc</spanx>.
           </t>
         </section>
 
@@ -3223,20 +3222,19 @@ HTTP2-Settings    = token68
     </section>
 
     <section anchor="security" title="Security Considerations">
-      <section title="Server Authority and Same-Origin" anchor="authority">
+      <section title="Server Authority" anchor="authority">
         <t>
-          This specification uses the same-origin policy (<xref target="RFC6454" x:fmt=","
-          x:sec="3"/>) to determine whether an origin server is permitted to provide content.
+          A client is only able to accept HTTP/2 responses from servers that are authoritative for
+          those resources.  This is particularly important for <xref target="PushResources">server
+          push</xref>, where the client validates the <x:ref>PUSH_PROMISE</x:ref> before accepting
+          the response.
         </t>
         <t>
-          A server that is contacted using TLS is authenticated based on the certificate that it
-          offers in the TLS handshake (see <xref target="RFC2818" x:fmt="," x:sec="3"/>).  A server
-          is considered authoritative for an "https" resource if it has been successfully
-          authenticated for the uri-host of the origin of the resource that it is providing.
-        </t>
-        <t>
-          A server is considered authoritative for an "http" resource if the connection is
-          established to a resolved IP address for the uri-host of the origin of the resource.
+          HTTP/2 relies on the HTTP/1.1 definition of authority for determining whether a server is
+          authoritative in providing a given response, see <xref target="HTTP-p1" x:fmt=","
+          x:rel="#establishing.authority"/>).  This relies on local name resolution for the "http"
+          URI scheme, and the offered server identity for the "https" scheme (see <xref
+          target="RFC2818" x:fmt="," x:sec="3"/>).
         </t>
         <t>
           A client MUST NOT use, in any way, resources provided by a server that is not