CREDENTIAL: Strip out 'existing solutions'.

Author: mikewest

specs/credentialmanagement/index.src.html

@@ -387,41 +387,6 @@ <h4 id="examples-change-password">Change Password</h4>
     the user agent that she's successfully signed in with new credentials. The
     user agent can then update the credentials it stores.
   </section>
-
-  <section>
-    <h3 id="existing-solutions">
-      Haven't we done this before? What about [<em>insert technology here</em>]?
-    </h3>
-
-    <h4 id="existing-solutions-browserid">BrowserID/Persona</h4>
-
-    BrowserID is a proposal for an API which allows websites to request an
-    assertion of a user's email address ownership. [[BROWSERID]]
-
-    The API specified here does not attempt to assert the user's identity
-    directly: it only provides a more direct interface to the user agent's
-    <a>credential store</a>. Assertions about identity would still rely on
-    <a>federated identity provider</a>'s particular SDKs and workflows.
-
-    BrowserID is complementary to this API, and could be tacked onto the
-    {{FederatedCredential}} flow at some point in the future. For example, a
-    user who chooses a {{FederatedCredential}} whose origin supports
-    BrowserID could perform the authentication steps in the background by
-    passing the user's email address and public key to the relevant
-    <a>identity provider</a>, and adding a new property to the
-    {{FederatedCredential}} given back to the website which contains the
-    signed certificate asserting the user's identity.
-
-    This document doesn't specify any of that behavior, but is designed with
-    it in mind: the immediate goal is to give websites more direct access to
-    the user agent's existing credential manager, as federations are completely
-    unsupported at the moment. Generating assertions is an obvious next step.
-    See [[#future-work]] for other thoughts on the subject.
-
-    <h4 id="existing-solutions-webid">WebID</h4>
-
-    TODO
-  </section>
 </section>
 
 <!--