Merge branch 'master' of https://github.com/w3c/webappsec

Author: hillbrad

implementation_reports/CSP2_implementation_report.html

@@ -143,7 +143,7 @@ <h1>Implementation Report for <a href="http://w3.org/TR/csp2">Content Security P
 	<td>2</td>
 	<td class="feature">meta and header policy combination</td>
 	<td class="tests"><a href="http://w3c-test.org/content-security-policy/blink-contrib/combine-header-and-meta-policies.sub.html">http://w3c-test.org/content-security-policy/blink-contrib/combine-header-and-meta-policies.sub.html</a><br></td>
-	<td class="fail">FAIL</td>
+	<td class="pass">PASS</td>
 	<td class="fail">FAIL</td>
 </tr>
 

specs/credentialmanagement/index.html

@@ -71,7 +71,7 @@
    <h1 class="p-name no-ref" id="title">Credential Management Level 1</h1>
 
    <h2 class="no-num no-toc no-ref heading settled" id="subtitle"><span class="content">Editor’s Draft,
-    <time class="dt-updated" datetime="2015-09-07">7 September 2015</time></span></h2>
+    <time class="dt-updated" datetime="2015-09-15">15 September 2015</time></span></h2>
 
    <div data-fill-with="spec-metadata">
     <dl>
@@ -3267,10 +3267,17 @@ <h2 class="heading settled" data-level="9" id="future-work"><span class="secno">
   today.</p>
 
 
-    <p>The natural way to expose this information is to extend the
+    <p>A natural way to expose this information might be to extend the
   <code class="idl"><a data-link-type="idl" href="#federatedcredential">FederatedCredential</a></code> interface with properties like authentication tokens,
-  and to add some form of manifest format with properties that declare the
-  authentication type which the provider supports.</p>
+  and possibly to add some form of manifest format with properties that declare
+  the authentication type which the provider supports.</p>
+
+
+    <p>The API described here is designed to be extensible enough to support use
+  cases that require user interaction, perhaps with websites other than the one
+  which requested credentials. We hope that the Promise-based system we’ve
+  settled on is extensible enough to support these kinds of asynchronous flows
+  in the future without redesigning the API from the ground up.</p>
 
 
     <p>Baby steps.</p>
@@ -3288,7 +3295,8 @@ <h2 class="heading settled" data-level="9" id="future-work"><span class="secno">
     and
     <a href="http://opencreds.org/specs/source/use-cases/">Credentials CG Use Cases</a>,
     and anticipate extending the API in a separate document to solve a different
-    set of problems than WebAppSec is currently chartered to deal with.  </div>
+    set of problems than WebAppSec is currently chartered to deal with.
+  </div>
 </section>
 
 </main>

specs/credentialmanagement/index.src.html

@@ -2189,10 +2189,16 @@ <h2 id="future-work">Future Work</h2>
   authentication flows, users will be in a significantly better position than
   today.
 
-  The natural way to expose this information is to extend the
+  A natural way to expose this information might be to extend the
   {{FederatedCredential}} interface with properties like authentication tokens,
-  and to add some form of manifest format with properties that declare the
-  authentication type which the provider supports.
+  and possibly to add some form of manifest format with properties that declare
+  the authentication type which the provider supports.
+
+  The API described here is designed to be extensible enough to support use
+  cases that require user interaction, perhaps with websites other than the one
+  which requested credentials. We hope that the Promise-based system we've
+  settled on is extensible enough to support these kinds of asynchronous flows
+  in the future without redesigning the API from the ground up.
 
   Baby steps.
 
@@ -2208,5 +2214,6 @@ <h2 id="future-work">Future Work</h2>
     and
     <a href="http://opencreds.org/specs/source/use-cases/">Credentials CG Use Cases</a>,
     and anticipate extending the API in a separate document to solve a different
-    set of problems than WebAppSec is currently chartered to deal with.  </div>
+    set of problems than WebAppSec is currently chartered to deal with.
+  </div>
 </section>