CREDENTIAL: Soften the language in 'Request a credential'.

Author: mikewest

specs/credentialmanagement/index.html

@@ -1855,13 +1855,11 @@ <h4 class="heading settled" data-level="4.1.1" id="request-credential"><span cla
     </ol>
 
 
-    <p class="issue" id="issue-a3de5bfb"><a class="self-link" href="#issue-a3de5bfb"></a> How do we deal with a future in which
-  <code class="idl"><a data-link-type="idl" href="#originboundcredential">OriginBoundCredential</a></code> isn’t the only type? For example, how could an
-  author pull some "RemoteCredential" that required interaction with a
-  third-party, but fall back to a <code class="idl"><a data-link-type="idl" href="#passwordcredential">PasswordCredential</a></code>? For the moment, we’re
-  resolving this by rejecting the promise if the types listed in
-  <code class="idl"><a data-link-type="idl" href="#dom-credentialcontainer-get">get()</a></code>'s <code class="idl"><a class="idl-code" data-link-type="argument" href="#dom-credentialcontainer-get-options-options">options</a></code> aren’t all instances of
-  the same type, but that seems like something we’d want to fix. <a href="https://github.com/w3c/webappsec/issues/256">&lt;https://github.com/w3c/webappsec/issues/256></a></p>
+    <p class="note" role="note">Note: Currently, we reject a call to <code class="idl"><a data-link-type="idl" href="#dom-credentialcontainer-get">get()</a></code> if the
+  <var>options</var> provided specify a set of <code class="idl"><a data-link-type="idl" href="#credential">Credential</a></code> types that don’t
+  play well together (e.g. some future "NeedsLotsOfUserInteractionCredential"
+  type in the same request as an <code class="idl"><a data-link-type="idl" href="#passwordcredential">PasswordCredential</a></code>). We may wish to define
+  a more graceful fallback mechanism if/when new credential types are defined.</p>
 
 
     <h4 class="heading settled" data-level="4.1.2" id="store-credential"><span class="secno">4.1.2. </span><span class="content">
@@ -3652,13 +3650,6 @@ <h2 class="no-num heading settled" id="issues-index"><span class="content">Issue
    <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"> How do we deal with a future in which
-  <code class="idl"><a data-link-type="idl" href="#originboundcredential">OriginBoundCredential</a></code> isn’t the only type? For example, how could an
-  author pull some "RemoteCredential" that required interaction with a
-  third-party, but fall back to a <code class="idl"><a data-link-type="idl" href="#passwordcredential">PasswordCredential</a></code>? For the moment, we’re
-  resolving this by rejecting the promise if the types listed in
-  <code class="idl"><a data-link-type="idl" href="#dom-credentialcontainer-get">get()</a></code>'s <code class="idl"><a class="idl-code" data-link-type="argument" href="#dom-credentialcontainer-get-options-options">options</a></code> aren’t all instances of
-  the same type, but that seems like something we’d want to fix. <a href="https://github.com/w3c/webappsec/issues/256">&lt;https://github.com/w3c/webappsec/issues/256></a><a href="#issue-a3de5bfb"> ↵ </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">

specs/credentialmanagement/index.src.html

@@ -1167,13 +1167,11 @@ <h4 id="request-credential">
     </li>
   </ol>
 
-  ISSUE(w3c/webappsec#256): How do we deal with a future in which
-  {{OriginBoundCredential}} isn't the only type? For example, how could an
-  author pull some "RemoteCredential" that required interaction with a
-  third-party, but fall back to a {{PasswordCredential}}? For the moment, we're
-  resolving this by rejecting the promise if the types listed in
-  {{CredentialContainer/get()}}'s {{options!!argument}} aren't all instances of
-  the same type, but that seems like something we'd want to fix.
+  Note: Currently, we reject a call to {{CredentialContainer/get()}} if the
+  <var>options</var> provided specify a set of {{Credential}} types that don't
+  play well together (e.g. some future "NeedsLotsOfUserInteractionCredential"
+  type in the same request as an {{PasswordCredential}}). We may wish to define
+  a more graceful fallback mechanism if/when new credential types are defined.
 
   <h4 id="store-credential">
     Store a <code>Credential</code>