Merge pull request #248 from w3c/issue-80-security-reqs

Update security requirements for resolution around mixed content.

index.html

@@ -332,11 +332,13 @@ <h2>
         "http://www.w3.org/TR/html5/browsers.html#session-history">session
         history</a></dfn>, <dfn><a href=
         "http://www.w3.org/TR/html5/browsers.html#sandboxed-auxiliary-navigation-browsing-context-flag">
-        sandboxed auxiliary navigation browsing context flag</a></dfn>, and
+        sandboxed auxiliary navigation browsing context flag</a></dfn>,
         <dfn><a href=
         "http://www.w3.org/TR/html5/browsers.html#sandboxed-top-level-navigation-browsing-context-flag">
-        sandboxed top-level navigation browsing context flag</a></dfn> are
-        defined in [[!HTML5]].
+        sandboxed top-level navigation browsing context flag</a></dfn>, and
+        <dfn><a href=
+        "http://www.w3.org/TR/html5/webappapis.html#settings-object">settings
+        object</a></dfn> are defined in [[!HTML5]].
       </p>
       <p>
         The term <dfn><a href=
@@ -374,6 +376,9 @@ <h2>
         <li>
           <dfn><code>OperationError</code></dfn>
         </li>
+        <li>
+          <dfn><code>SecurityError</code></dfn>
+        </li>
         <li>
           <dfn><code>SyntaxError</code></dfn>
         </li>
@@ -423,6 +428,14 @@ <h2>
         "http://www.w3.org/TR/webstorage/#the-sessionstorage-attribute"><code>sessionStorage</code></a></dfn>
         are defined in [[WEBSTORAGE]].
       </p>
+      <p>
+        The terms <dfn><a href=
+        "https://w3c.github.io/webappsec-mixed-content/#a-priori-authenticated-url">
+        a priori unauthenticated URL</a></dfn> and <dfn><a href=
+        "https://w3c.github.io/webappsec-mixed-content/#categorize-settings-object">
+        prohibits mixed security contexts algorithm</a></dfn> are defined in
+        [[!MIXED-CONTENT]].
+      </p>
     </section>
     <section>
       <h2>
@@ -818,8 +831,8 @@ <h4>
           </dl>
           <ol>
             <li>Resolve <var>url</var> relative to the API base URL specified
-            by the entry settings object, and let <var>presentationUrl</var> be
-            the resulting absolute URL, if any.
+            by the entry <a>settings object</a>, and let
+            <var>presentationUrl</var> be the resulting absolute URL, if any.
             </li>
             <li>If the resolve a URL algorithm failed, then throw a
             <a>SyntaxError</a> exception and abort the remaining steps.
@@ -862,6 +875,14 @@ <h4>
             <a>Promise</a> rejected with an <a>InvalidAccessError</a> exception
             and abort these steps.
             </li>
+            <li>Using the document's <a>settings object</a>, run the
+            <a>prohibits mixed security contexts algorithm</a>.
+            </li>
+            <li>If the result of the algorithm is <code>"Prohibits Mixed
+            Security Contexts"</code> and <var>presentationUrl</var> is an <a>
+              a priori unauthenticated URL</a>, then return a <a>Promise</a>
+              rejected with a <a>SecurityError</a>.
+            </li>
             <li>If there is already an unsettled <a>Promise</a> from a previous
             call to <code>start</code> for the same <a>controlling browsing
             context</a>, return a <a>Promise</a> rejected with an
@@ -1001,6 +1022,14 @@ <h4>
           <ol>
             <li>Let <var>P</var> be a new <a>Promise</a>.
             </li>
+            <li>Using the document's <a>settings object</a>, run the
+            <a>prohibits mixed security contexts algorithm</a>.
+            </li>
+            <li>If the result of the algorithm is <code>"Prohibits Mixed
+            Security Contexts"</code> and the <a>presentation request URL</a>
+            of <var>presentationRequest</var> is an <a>a priori unauthenticated
+            URL</a>, then reject <var>P</var> with a <a>SecurityError</a>.
+            </li>
             <li>Return <var>P</var>, but continue running these steps in
             parallel.
             </li>
@@ -1221,8 +1250,8 @@ <h4>
             <li>Return <var>P</var>, but continue running these steps <a>in
             parallel</a>.
             </li>
-            <li>If the user agent is unable to <a>monitor the list of of
-            available presentation displays</a> for the entire duration of the
+            <li>If the user agent is unable to <a>monitor the list of available
+            presentation displays</a> for the entire duration of the
             <a>controlling browsing context</a> (e.g., because the user has
             disabled this feature), then:
               <ol>
@@ -2284,17 +2313,23 @@ <h3>
         presentation.
       </p>
       <p>
-        This specification does not prohibit a user agent from publishing
-        information about its <a>set of presentations</a>. The group envisions
-        a user agent on another device (distinct from the controller or
-        presentation) becoming authorized to reconnect to the presentation,
-        either by user action or by discovering the presentation's URL and id.
+        This specification allows a user agent to publish information about its
+        <a>set of presentations</a>, and allows a browsing context on another
+        user agent to connect to a running presentation via <code><a for=
+        "PresentationRequest">reconnect</a>()</code>. To connect, the
+        additional browsing context must discover the presentation URL and
+        presentation ID of the presentation, either provided by the user, or
+        via a shared service.
+      </p>
+      <p>
+        However, this specification makes no guarantee as to the identity of
+        the connecting party. Once connected, the receiving application may
+        wish to further verify the identity of the connecting party through
+        application-specific means. For example, the connecting application
+        could provide a token via <code><a for=
+        "PresentationConnection">send</a>()</code> that the receiving
+        application could verify corresponds an authorized entity.
       </p>
-      <div class="issue">
-        This section should provide informative guidance as to what constitutes
-        a reasonable context for a Web page to become authorized to control a
-        presentation connection.
-      </div>
       <h3>
         Device Access
       </h3>
@@ -2313,9 +2348,6 @@ <h3>
         presentation from another browsing context. They can be intercepted if
         an attacker can inject content into the controlling page.
       </p>
-      <div class="issue">
-        Should we restrict the API to some extent in non secure contexts?
-      </div>
       <h3>
         Incognito mode and clearing of browsing data
       </h3>