CREDENTIAL: Remove some future-describing ISSUEs.

Author: mikewest

specs/credentialmanagement/index.html

@@ -921,12 +921,6 @@ <h4 class="heading settled" data-level="3.1.3" id="interfaces-credential-types-p
 
 
 
-      <p class="issue" id="issue-317aa5d1"><a class="self-link" href="#issue-317aa5d1"></a> Probably not something for v1, but an
-      interesting option would be to provide a hash function here that the user
-      agent would apply to the password before sending it over the wire. <a href="https://github.com/w3c/webappsec/issues/288">&lt;https://github.com/w3c/webappsec/issues/288></a></p>
-      
-
-
 
       <table class="argumentdef data definition-table">
 
@@ -1291,11 +1285,6 @@ <h3 class="heading settled" data-level="3.2" id="interfaces-credential-manager">
 
     </dl>
 
-
-    <p class="issue" id="issue-74489b21"><a class="self-link" href="#issue-74489b21"></a> We should support explicit sign-up via
-  <code class="idl"><a data-link-type="idl" href="#passwordcredential">PasswordCredential</a></code>s with generated passwords. Perhaps something similar to
-  iOS8’s <code>SecCreateSharedWebCredentialPassword</code>. <a href="https://github.com/w3c/webappsec/issues/250">&lt;https://github.com/w3c/webappsec/issues/250></a></p>
-
 
     <h4 class="heading settled" data-level="3.2.1" id="interfaces-request-options"><span class="secno">3.2.1. </span><span class="content">
     <code>get()</code> Parameters
@@ -1816,13 +1805,9 @@ <h4 class="heading settled" data-level="4.1.1" id="request-credential"><span cla
 
 
          <li>
-              If <var>request</var>’s <code class="idl"><a data-link-type="idl" href="#dom-credentialrequestoptions-suppressui">suppressUI</a></code>
+              If <var>options</var>’s <code class="idl"><a data-link-type="idl" href="#dom-credentialrequestoptions-suppressui">suppressUI</a></code>
               is <code>true</code>, resolve <var>promise</var> with
               <var>undefined</var>, and terminate this algorithm.
-
-
-          <p class="issue" id="issue-f7326a75"><a class="self-link" href="#issue-f7326a75"></a> Do something here. Maybe this should be part of options?</p>
-          
 
 
 
@@ -3585,19 +3570,12 @@ <h2 class="no-num heading settled" id="issues-index"><span class="content">Issue
    <div class="issue"> Anne suggests that this might be better modeled
       as an <code>ImageBitmap</code> or <code>blob:</code>. We also need to
       figure out responsiveness. Perhaps <a data-link-type="biblio" href="#biblio-manifest">[MANIFEST]</a>'s format? <a href="https://github.com/w3c/webappsec/issues/247">&lt;https://github.com/w3c/webappsec/issues/247></a><a href="#issue-c874d302"> ↵ </a></div>
-   <div class="issue"> Probably not something for v1, but an
-      interesting option would be to provide a hash function here that the user
-      agent would apply to the password before sending it over the wire. <a href="https://github.com/w3c/webappsec/issues/288">&lt;https://github.com/w3c/webappsec/issues/288></a><a href="#issue-317aa5d1"> ↵ </a></div>
-   <div class="issue"> We should support explicit sign-up via
-  <code class="idl"><a data-link-type="idl" href="#passwordcredential">PasswordCredential</a></code>s with generated passwords. Perhaps something similar to
-  iOS8’s <code>SecCreateSharedWebCredentialPassword</code>. <a href="https://github.com/w3c/webappsec/issues/250">&lt;https://github.com/w3c/webappsec/issues/250></a><a href="#issue-74489b21"> ↵ </a></div>
    <div class="issue"> Monkey-patching! Hooray! Talk with Anne, et al.<a href="#issue-020f94b2"> ↵ </a></div>
    <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"> This is terribly hand-wavey. The intent is
       clear, but I need to do the work to walk through the list of DOMStrings
       and convert them to interfaces and etc. Busywork for later. <a href="https://github.com/w3c/webappsec/issues/289">&lt;https://github.com/w3c/webappsec/issues/289></a><a href="#issue-6005a2a4"> ↵ </a></div>
-   <div class="issue"> Do something here. Maybe this should be part of options?<a href="#issue-f7326a75"> ↵ </a></div>
    <div class="issue"> How do we deal with a future in which
   <code class="idl"><a data-link-type="idl" href="#locallystoredcredential">LocallyStoredCredential</a></code> isn’t the only type? For example, how could an
   author pull some "RemoteCredential" that required interaction with a

specs/credentialmanagement/index.src.html

@@ -595,10 +595,6 @@ <h4 id="interfaces-credential-types-passwordcredential"><code>PasswordCredential
       The user agent MUST execute the algorithm described in
       [[#generate-formdata]] when this method is executed.
 
-      ISSUE(w3c/webappsec#288): Probably not something for v1, but an
-      interesting option would be to provide a hash function here that the user
-      agent would apply to the password before sending it over the wire.
-
       <pre class="argumentdef" for="PasswordCredential/toFormData(formDataOptions)">
         formDataOptions: A set of options governing the {{FormData}} object's construction.
       </pre>
@@ -780,10 +776,6 @@ <h3 id="interfaces-credential-manager">Credential Manager</h3>
     </dd>
   </dl>
 
-  ISSUE(w3c/webappsec#250): We should support explicit sign-up via
-  {{PasswordCredential}}s with generated passwords. Perhaps something similar to
-  iOS8's <code>SecCreateSharedWebCredentialPassword</code>.
-
   <h4 id="interfaces-request-options">
     <code>get()</code> Parameters
   </h4>
@@ -1145,11 +1137,9 @@ <h4 id="request-credential">
               algorithm.
             </li>
             <li>
-              If <var>request</var>'s {{CredentialRequestOptions/suppressUI}}
+              If <var>options</var>'s {{CredentialRequestOptions/suppressUI}}
               is <code>true</code>, resolve <var>promise</var> with
               <var>undefined</var>, and terminate this algorithm.
-
-              ISSUE: Do something here. Maybe this should be part of options?
             </li>
             <li>
               If this algorithm would not be <a>allowed to show a popup</a>,