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

Author: hillbrad

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-03">3 September 2015</time></span></h2>
+    <time class="dt-updated" datetime="2015-09-04">4 September 2015</time></span></h2>
 
    <div data-fill-with="spec-metadata">
     <dl>
@@ -3108,12 +3108,18 @@ <h3 class="heading settled" data-level="7.2" id="privacy-chooser-leakage"><span
   cache them for the lifetime of the <code class="idl"><a data-link-type="idl" href="#credential">Credential</a></code>.</p>
 
 
-    <p>Further, these images MUST be fetched with the <code>credentials</code> mode
-  set to "<code>omit</code>", the <code>skip-service-worker flag</code> set, the
+    <p>These images MUST be fetched with the <code>credentials</code> mode set to
+  "<code>omit</code>", the <code>skip-service-worker flag</code> set, the
   <code>client</code> set to <code>null</code>, the <code>initiator</code> set
   to the empty string, and the <code>destination</code> set to
   <code>subresource</code>.</p>
 
+
+    <p>Moreover, if the user agent allows the user to change either the name or icon
+  associated with the credential, the alterations to the data SHOULD NOT be
+  exposed to the website (consider a user who names two credentials for an
+  origin "My fake account" and "My real account", for instance).</p>
+
 
     <h3 class="heading settled" data-level="7.3" id="locally-stored-data"><span class="secno">7.3. </span><span class="content">Locally Stored Data</span><a class="self-link" href="#locally-stored-data"></a></h3>
 
@@ -3277,7 +3283,7 @@ <h2 class="heading settled" data-level="9" id="future-work"><span class="secno">
     <p>Baby steps.</p>
 
 
-    <div class="issue" id="issue-9c0b1540"><a class="self-link" href="#issue-9c0b1540"></a>
+    <div class="note" role="note">
     Groups like the
     <a href="http://www.w3.org/Payments/IG/">Web Payments IG</a>
     and the
@@ -3289,21 +3295,7 @@ <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.  We
-    should keep track of this work as it progresses and make appropriate
-    references to any technical reports which may assist in understanding and
-    implementing this report, as appropriate, when this document is ready to
-    transition to Recommendation status.
-
-
-     <p>It’s not yet clear whether the API proposed in this document allows these
-    and other groups to elegantly address the problems they’re interested in
-    solving. We may wish to adjust portions of the API before advancing this
-    document to REC in order to ensure clean extensibility into these other
-    areas.</p>
-     
-  
-    </div>
+    set of problems than WebAppSec is currently chartered to deal with.  </div>
 </section>
 
 </main>
@@ -3683,32 +3675,5 @@ <h2 class="no-num heading settled" id="issues-index"><span class="content">Issue
    <div class="issue"> Currently, we’re not protecting requests with opaque bodies from
   Service Worker interception. Should we?<a href="#issue-be0db764"> ↵ </a></div>
    <div class="issue"> Add some thoughts here about when and how the API
-  should be used, especially with regard to <code class="idl"><a data-link-type="idl" href="#dom-credentialrequestoptions-suppressui">suppressUI</a></code>. <a href="https://github.com/w3c/webappsec/issues/290">&lt;https://github.com/w3c/webappsec/issues/290></a><a href="#issue-e1d9f1af"> ↵ </a></div>
-   <div class="issue">
-    Groups like the
-    <a href="http://www.w3.org/Payments/IG/">Web Payments IG</a>
-    and the
-    <a href="https://www.w3.org/community/credentials/">Credentials CG</a>
-    have expressed interest in extending the API defined in this document in
-    order to address use cases beyond those outlined in <a href="#use-cases">§1.1 Use Cases</a>. They’ve
-    documented these use cases in detail in
-    <a href="http://www.w3.org/TR/web-payments-use-cases/">Web Payments Use Cases 1.0</a>
-    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.  We
-    should keep track of this work as it progresses and make appropriate
-    references to any technical reports which may assist in understanding and
-    implementing this report, as appropriate, when this document is ready to
-    transition to Recommendation status.
-
-
-    <p>It’s not yet clear whether the API proposed in this document allows these
-    and other groups to elegantly address the problems they’re interested in
-    solving. We may wish to adjust portions of the API before advancing this
-    document to REC in order to ensure clean extensibility into these other
-    areas.</p>
-    
-  <a href="#issue-9c0b1540"> ↵ </a>
-   </div></div></body>
+  should be used, especially with regard to <code class="idl"><a data-link-type="idl" href="#dom-credentialrequestoptions-suppressui">suppressUI</a></code>. <a href="https://github.com/w3c/webappsec/issues/290">&lt;https://github.com/w3c/webappsec/issues/290></a><a href="#issue-e1d9f1af"> ↵ </a></div></div></body>
 </html>

specs/credentialmanagement/index.src.html

@@ -2051,12 +2051,17 @@ <h3 id="privacy-chooser-leakage">Chooser Leakage</h3>
   the images in the background when saving or updating a {{Credential}}, and to
   cache them for the lifetime of the {{Credential}}.
 
-  Further, these images MUST be fetched with the <code>credentials</code> mode
-  set to "<code>omit</code>", the <code>skip-service-worker flag</code> set, the
+  These images MUST be fetched with the <code>credentials</code> mode set to
+  "<code>omit</code>", the <code>skip-service-worker flag</code> set, the
   <code>client</code> set to <code>null</code>, the <code>initiator</code> set
   to the empty string, and the <code>destination</code> set to
   <code>subresource</code>.
 
+  Moreover, if the user agent allows the user to change either the name or icon
+  associated with the credential, the alterations to the data SHOULD NOT be
+  exposed to the website (consider a user who names two credentials for an
+  origin "My fake account" and "My real account", for instance).
+
   <h3 id="locally-stored-data">Locally Stored Data</h3>
 
   This API offers an <a>origin</a> the ability to store data persistently along
@@ -2198,7 +2203,7 @@ <h2 id="future-work">Future Work</h2>
 
   Baby steps.
 
-  <div class="issue">
+  <div class="note">
     Groups like the
     <a href="http://www.w3.org/Payments/IG/">Web Payments IG</a>
     and the
@@ -2210,16 +2215,5 @@ <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.  We
-    should keep track of this work as it progresses and make appropriate
-    references to any technical reports which may assist in understanding and
-    implementing this report, as appropriate, when this document is ready to
-    transition to Recommendation status.
-
-    It's not yet clear whether the API proposed in this document allows these
-    and other groups to elegantly address the problems they're interested in
-    solving. We may wish to adjust portions of the API before advancing this
-    document to REC in order to ensure clean extensibility into these other
-    areas.
-  </div>
+    set of problems than WebAppSec is currently chartered to deal with.  </div>
 </section>