Revamp intro

spec/index.bs

@@ -110,30 +110,21 @@ script + svg :is(polygon, text) {
 
 *This section is non-normative.*
 
-As the web has evolved there have been ongoing privacy-oriented changes
-(e.g [Safari](https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/),
-[Firefox](https://blog.mozilla.org/blog/2019/09/03/todays-firefox-blocks-third-party-tracking-cookies-and-cryptomining-by-default/),
-[Chrome](https://blog.google/products/chrome/privacy-sustainability-and-the-importance-of-and/))
-and changes to the underlying privacy principles (e.g. [[PRIVACY-MODEL]]).
-
-With this evolution, fundamental assumptions of the web
-platform are being redefined or removed. Access to cookies in a third-party
-context are one of those assumptions. While overall good for the
-web, the third-party cookie deprecation removes a fundamental building block
-used by certain designs of federated identity.
-
-The Federated Credential Management API aims to bridge the gap for the
-federated identity designs which relied on third-party cookies.
-The API provides the primitives needed to support federated identity when/where
-it depends on third-party cookies, from sign-in to sign-out and revocation.
-
-In order to provide the federated identity primitives without the use of
-third-party cookies the API places the [=user agent=] as a mediator between a
-<dfn><abbr title="Relying Party">RP</abbr></dfn> (website that requests user information for
-federated sign in) and an <dfn><abbr title="Identity Provider">IDP</abbr></dfn> (website that provides
-user information for federated sign in). This mediation requires user
-permission before allowing the [=RPs=] and [=IDPs=] to know about their
-connection to the user.
+The Federated Credential Management API allows the user agent to mediate certain federated login
+flows without requiring third-party cookies, popups, or full page redirects. It does so without
+letting the <dfn><abbr title="Identity Provider">IDP</abbr></dfn> (website that provides user
+information for federated sign in) know that a given user has visited the <dfn><abbr title="Relying
+Party">RP</abbr></dfn> (website that requests user information for federated sign in), which is
+better than the approach relying on third-party cookies from a privacy perspective. And it provides
+the accounts available without requiring a full load of an [=IDP=] page, which is a better UX than
+popups or full page redirects. In addition, it paves the path for the user agent to introduce login
+options to the user in locations that may be contextually relevant to the user but impossible for a
+site to access on their own. For instance, it allows the user agent to show federated accounts from
+multiple [=IDP=]s in a single unifired UI surface to the user, something that would be basically
+impossible for sites to coordinate independently. In addition, a user agent could show a login
+widget in the omnibar or in an autofill dropdown menu. In summary, the FedCM API enables federation
+in a privacy friendly way, providing UX improvements over the existing flows and paving the way for
+a future where the user agent provides a seamless login experience to the user.
 
 The specification leans heavily on changes in the [=user agent=] and [=IDP=]
 and minimally on the [=RP=]. The FedCM API provides a way to fetch tokens.
@@ -3587,10 +3578,6 @@ Note: write down the Acknowledgements section.
     "href": "https://w3c.github.io/webappsec-permissions-policy",
     "title": "Permissions Policy"
   },
-  "PRIVACY-MODEL": {
-    "href": "https://github.com/michaelkleber/privacy-model",
-    "title": "Privacy Model"
-  },
   "PRIVACY-THREAT-MODEL": {
     "href": "https://w3cping.github.io/privacy-threat-model/",
     "title": "Target Privacy Threat Model"