From bef12c5e8c7dc67b938e16aec87f40d5423dfd09 Mon Sep 17 00:00:00 2001
From: Kai Lehmann <1779230+obfuscoder@users.noreply.github.com>
Date: Thu, 16 May 2024 11:45:06 +0000
Subject: [PATCH] Remove note on IdP to validate nonce (#582) (#583)

SHA: 10794f7327d3d44943b65c2013c4a7788b6c5cbe
Reason: push, by pull[bot]

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
---
 index.html | 155 ++++++++++++++++++++++++++---------------------------
 1 file changed, 77 insertions(+), 78 deletions(-)

diff --git a/index.html b/index.html
index 09d0edb6..6d3d0ac3 100644
--- a/index.html
+++ b/index.html
@@ -6,7 +6,7 @@
   <link href="https://www.w3.org/StyleSheets/TR/2021/cg-draft" rel="stylesheet">
   <meta content="Bikeshed version 82ce88815, updated Thu Sep 7 16:33:55 2023 -0700" name="generator">
   <link href="https://fedidcg.github.io/FedCM/" rel="canonical">
-  <meta content="82db3af5204b8a9b54d8f04a354b3c23e6f162cd" name="document-revision">
+  <meta content="10794f7327d3d44943b65c2013c4a7788b6c5cbe" name="document-revision">
 <style>
 dl.domintro dt {
     font-family: Menlo, Consolas, "DejaVu Sans Mono", Monaco, monospace;
@@ -917,7 +917,7 @@
   <div class="head">
    <p data-fill-with="logo"><a class="logo" href="https://www.w3.org/"> <img alt="W3C" height="48" src="https://www.w3.org/StyleSheets/TR/2021/logos/W3C" width="72"> </a> </p>
    <h1 class="p-name no-ref" id="title">Federated Credential Management API</h1>
-   <p id="w3c-state"><a href="https://www.w3.org/standards/types#CG-DRAFT">Draft Community Group Report</a>, <time class="dt-updated" datetime="2024-05-09">9 May 2024</time></p>
+   <p id="w3c-state"><a href="https://www.w3.org/standards/types#CG-DRAFT">Draft Community Group Report</a>, <time class="dt-updated" datetime="2024-05-16">16 May 2024</time></p>
    <div data-fill-with="spec-metadata">
     <dl>
      <dt>This version:
@@ -3129,7 +3129,6 @@ <h3 class="heading settled" data-level="3.5" id="idp-api-id-assertion-endpoint">
    <div class="idp-normative-text"> An <a data-link-type="dfn" href="#idp" id="ref-for-idp④⑦">IDP</a> MUST check the <a data-link-type="http-header" href="https://fetch.spec.whatwg.org/#http-origin" id="ref-for-http-origin⑤">Origin</a> header to ensure that a malicious <a data-link-type="dfn" href="#rp" id="ref-for-rp③⑨">RP</a> does
 not receive an ID token corresponding to another <a data-link-type="dfn" href="#rp" id="ref-for-rp④⓪">RP</a>. In other words, the <a data-link-type="dfn" href="#idp" id="ref-for-idp④⑧">IDP</a> MUST check that
 the <a data-link-type="http-header" href="https://fetch.spec.whatwg.org/#http-origin" id="ref-for-http-origin⑥">Origin</a> header value is represented by the <code class="idl"><a data-link-type="idl" href="#dom-identityproviderconfig-clientid" id="ref-for-dom-identityproviderconfig-clientid⑧">clientId</a></code>. As the <code class="idl"><a data-link-type="idl" href="#dom-identityproviderconfig-clientid" id="ref-for-dom-identityproviderconfig-clientid⑨">clientId</a></code> are <a data-link-type="dfn" href="#idp" id="ref-for-idp④⑨">IDP</a>-specific, the <a data-link-type="dfn" href="https://infra.spec.whatwg.org/#user-agent" id="ref-for-user-agent①③">user agent</a> cannot perform this check. </div>
-   <p class="note" role="note"><span class="marker">Note:</span> An <a data-link-type="dfn" href="#idp" id="ref-for-idp⑤⓪">IDP</a> should validate the nonce, if present, to prevent CSRF-style attacks.</p>
    <p>The response body must be a JSON object that can be <a data-link-type="dfn" href="https://webidl.spec.whatwg.org/#dfn-convert-ecmascript-to-idl-value" id="ref-for-dfn-convert-ecmascript-to-idl-value⑨">converted</a> to an <code class="idl"><a data-link-type="idl" href="#dictdef-identityprovidertoken" id="ref-for-dictdef-identityprovidertoken①">IdentityProviderToken</a></code> without an exception.</p>
    <p>Every <code class="idl"><a data-link-type="idl" href="#dictdef-identityprovidertoken" id="ref-for-dictdef-identityprovidertoken②">IdentityProviderToken</a></code> is expected to have members with the following semantics:</p>
    <dl>
@@ -3138,12 +3137,12 @@ <h3 class="heading settled" data-level="3.5" id="idp-api-id-assertion-endpoint">
      <p>The resulting token.</p>
    </dl>
    <p>The content of the <code class="idl"><a data-link-type="idl" href="#dom-identityprovidertoken-token" id="ref-for-dom-identityprovidertoken-token③">token</a></code> is opaque to the user agent and can contain
-anything that the <a data-link-type="dfn" href="#idp" id="ref-for-idp⑤①">IDP</a> would like to pass to the <a data-link-type="dfn" href="#rp" id="ref-for-rp④①">RP</a> to facilitate the login. For this reason the <a data-link-type="dfn" href="#rp" id="ref-for-rp④②">RP</a> is expected to be the party responsible for validating the <code class="idl"><a data-link-type="idl" href="#dom-identityprovidertoken-token" id="ref-for-dom-identityprovidertoken-token④">token</a></code> passed
-along from the <a data-link-type="dfn" href="#idp" id="ref-for-idp⑤②">IDP</a> using the appropriate token validation
+anything that the <a data-link-type="dfn" href="#idp" id="ref-for-idp⑤⓪">IDP</a> would like to pass to the <a data-link-type="dfn" href="#rp" id="ref-for-rp④①">RP</a> to facilitate the login. For this reason the <a data-link-type="dfn" href="#rp" id="ref-for-rp④②">RP</a> is expected to be the party responsible for validating the <code class="idl"><a data-link-type="idl" href="#dom-identityprovidertoken-token" id="ref-for-dom-identityprovidertoken-token④">token</a></code> passed
+along from the <a data-link-type="dfn" href="#idp" id="ref-for-idp⑤①">IDP</a> using the appropriate token validation
 algorithms defined. One example of how this might be done is defined
 in <a href="https://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation">OIDC Connect Core § IDTokenValidation</a>.</p>
-   <p class="note" role="note"><span class="marker">NOTE:</span> For <a data-link-type="dfn" href="#idp" id="ref-for-idp⑤③">IDPs</a>, it is worth considering how <a href="https://github.com/fedidcg/FedCM/issues/314">portable</a> accounts are.
-Portability is left entirely up to <a data-link-type="dfn" href="#idp" id="ref-for-idp⑤④">IDPs</a>, who can choose
+   <p class="note" role="note"><span class="marker">NOTE:</span> For <a data-link-type="dfn" href="#idp" id="ref-for-idp⑤②">IDPs</a>, it is worth considering how <a href="https://github.com/fedidcg/FedCM/issues/314">portable</a> accounts are.
+Portability is left entirely up to <a data-link-type="dfn" href="#idp" id="ref-for-idp⑤③">IDPs</a>, who can choose
 between a variety of different mechanisms to accomplish it
 (e.g. <a href="https://openid.net/specs/openid-connect-account-porting-1_0.html">OIDC’s Account Porting</a>).</p>
    <p>For example:</p>
@@ -3156,10 +3155,10 @@ <h3 class="heading settled" data-level="3.5" id="idp-api-id-assertion-endpoint">
    </div>
    <h3 class="heading settled" data-level="3.6" id="idp-api-disconnect-endpoint"><span class="secno">3.6. </span><span class="content">Disconnect endpoint</span><a class="self-link" href="#idp-api-disconnect-endpoint"></a></h3>
    <p>The <dfn class="dfn-paneled" data-dfn-type="dfn" data-noexport id="disconnect-endpoint">disconnect endpoint</dfn> is responsible for disconnecting a previously made federated
-login connection between an <a data-link-type="dfn" href="#rp" id="ref-for-rp④③">RP</a> and an <a data-link-type="dfn" href="#idp" id="ref-for-idp⑤⑤">IDP</a> account, and returning the account’s <code class="idl"><a data-link-type="idl" href="#dom-identityprovideraccount-id" id="ref-for-dom-identityprovideraccount-id④">id</a></code> so that the <a data-link-type="dfn" href="https://infra.spec.whatwg.org/#user-agent" id="ref-for-user-agent①④">user agent</a> can remove it from the <a data-link-type="dfn" href="#connected-accounts-set" id="ref-for-connected-accounts-set①①">connected accounts set</a>.</p>
+login connection between an <a data-link-type="dfn" href="#rp" id="ref-for-rp④③">RP</a> and an <a data-link-type="dfn" href="#idp" id="ref-for-idp⑤④">IDP</a> account, and returning the account’s <code class="idl"><a data-link-type="idl" href="#dom-identityprovideraccount-id" id="ref-for-dom-identityprovideraccount-id④">id</a></code> so that the <a data-link-type="dfn" href="https://infra.spec.whatwg.org/#user-agent" id="ref-for-user-agent①④">user agent</a> can remove it from the <a data-link-type="dfn" href="#connected-accounts-set" id="ref-for-connected-accounts-set①①">connected accounts set</a>.</p>
    <p>The <a data-link-type="dfn" href="#disconnect-endpoint" id="ref-for-disconnect-endpoint">disconnect endpoint</a> is fetched when invoking the <code class="idl"><a data-link-type="idl" href="#dom-identitycredential-disconnect" id="ref-for-dom-identitycredential-disconnect③">disconnect</a></code> method:</p>
    <p>(a) as a <strong>POST</strong> request,
-(b) <strong>with</strong> <a data-link-type="dfn" href="#idp" id="ref-for-idp⑤⑥">IDP</a> cookies,
+(b) <strong>with</strong> <a data-link-type="dfn" href="#idp" id="ref-for-idp⑤⑤">IDP</a> cookies,
 (c) <strong>with</strong> the <a data-link-type="dfn" href="#rp" id="ref-for-rp④④">RP</a>'s origin in the <a data-link-type="http-header" href="https://fetch.spec.whatwg.org/#http-origin" id="ref-for-http-origin⑦">Origin</a> header,
 (d) <strong>with</strong> the <a data-link-type="http-header" href="https://w3c.github.io/webappsec-fetch-metadata/#http-headerdef-sec-fetch-dest" id="ref-for-http-headerdef-sec-fetch-dest⑤">Sec-Fetch-Dest</a> header set to <code>webidentity</code>,
 (e) <strong>without</strong> following <a href="https://httpwg.org/specs/rfc9110.html#field.location">HTTP redirects</a>, and
@@ -3168,10 +3167,10 @@ <h3 class="heading settled" data-level="3.6" id="idp-api-disconnect-endpoint"><s
    <dl>
     <dt data-md><dfn class="idl-code" data-dfn-for="disconnect_endpoint_request" data-dfn-type="argument" data-export id="dom-disconnect_endpoint_request-client_id"><code>client_id</code><a class="self-link" href="#dom-disconnect_endpoint_request-client_id"></a></dfn>
     <dd data-md>
-     <p>The <a data-link-type="dfn" href="#rp" id="ref-for-rp④⑤">RP</a>'s unique identifier from the <a data-link-type="dfn" href="#idp" id="ref-for-idp⑤⑦">IDP</a></p>
+     <p>The <a data-link-type="dfn" href="#rp" id="ref-for-rp④⑤">RP</a>'s unique identifier from the <a data-link-type="dfn" href="#idp" id="ref-for-idp⑤⑥">IDP</a></p>
     <dt data-md><dfn class="dfn-paneled idl-code" data-dfn-for="disconnect_endpoint_request" data-dfn-type="argument" data-export id="dom-disconnect_endpoint_request-account_hint"><code>account_hint</code></dfn>
     <dd data-md>
-     <p>An account hint for the <a data-link-type="dfn" href="#idp" id="ref-for-idp⑤⑧">IDP</a> account being disconnected from the <a data-link-type="dfn" href="#rp" id="ref-for-rp④⑥">RP</a>.</p>
+     <p>An account hint for the <a data-link-type="dfn" href="#idp" id="ref-for-idp⑤⑦">IDP</a> account being disconnected from the <a data-link-type="dfn" href="#rp" id="ref-for-rp④⑥">RP</a>.</p>
    </dl>
    <p>For example:</p>
    <div class="example" id="example-d810f151">
@@ -3185,16 +3184,16 @@ <h3 class="heading settled" data-level="3.6" id="idp-api-disconnect-endpoint"><s
 client_id=client1234&amp;account_hint=hint12
 </pre>
    </div>
-   <p>If the disconnection is unsuccessful, the <a data-link-type="dfn" href="#idp" id="ref-for-idp⑤⑨">IDP</a> may respond with an error. If it is successful,
+   <p>If the disconnection is unsuccessful, the <a data-link-type="dfn" href="#idp" id="ref-for-idp⑤⑧">IDP</a> may respond with an error. If it is successful,
 the response body must be a JSON object that can be <a data-link-type="dfn" href="https://webidl.spec.whatwg.org/#dfn-convert-ecmascript-to-idl-value" id="ref-for-dfn-convert-ecmascript-to-idl-value①⓪">converted</a> to an <code class="idl"><a data-link-type="idl" href="#dictdef-disconnectedaccount" id="ref-for-dictdef-disconnectedaccount①">DisconnectedAccount</a></code> without an exception.</p>
    <dl>
     <dt data-md><dfn class="dfn-paneled idl-code" data-dfn-for="DisconnectedAccount" data-dfn-type="dict-member" data-export id="dom-disconnectedaccount-account_id"><code>account_id</code></dfn>, <span> of type <a data-link-type="idl-name" href="https://webidl.spec.whatwg.org/#idl-USVString" id="ref-for-idl-USVString⑤⓪">USVString</a></span>
     <dd data-md>
      <p>The <code class="idl"><a data-link-type="idl" href="#dom-identityprovideraccount-id" id="ref-for-dom-identityprovideraccount-id⑤">id</a></code> of the account that was successfully disconnected.</p>
    </dl>
-   <p>The <a data-link-type="dfn" href="#idp" id="ref-for-idp⑥⓪">IDP</a> must return the <code class="idl"><a data-link-type="idl" href="#dom-disconnectedaccount-account_id" id="ref-for-dom-disconnectedaccount-account_id②">account_id</a></code> since it may be different from the <code class="idl"><a data-link-type="idl" href="#dom-disconnect_endpoint_request-account_hint" id="ref-for-dom-disconnect_endpoint_request-account_hint">account_hint</a></code>, and the ID is the one which allows the <a data-link-type="dfn" href="https://infra.spec.whatwg.org/#user-agent" id="ref-for-user-agent①⑤">user agent</a> to disconnect the account from the <a data-link-type="dfn" href="#connected-accounts-set" id="ref-for-connected-accounts-set①②">connected accounts set</a>. If the <a data-link-type="dfn" href="#idp" id="ref-for-idp⑥①">IDP</a> returns an error or
-the <a data-link-type="dfn" href="https://infra.spec.whatwg.org/#user-agent" id="ref-for-user-agent①⑥">user agent</a> does not find the account with the ID provided by the <a data-link-type="dfn" href="#idp" id="ref-for-idp⑥②">IDP</a>, then all accounts
-associated with the relevant (<a data-link-type="dfn" href="#rp" id="ref-for-rp④⑦">RP</a>, <a data-link-type="dfn" href="#idp" id="ref-for-idp⑥③">IDP</a>) are removed from the <a data-link-type="dfn" href="#connected-accounts-set" id="ref-for-connected-accounts-set①③">connected accounts set</a>.</p>
+   <p>The <a data-link-type="dfn" href="#idp" id="ref-for-idp⑤⑨">IDP</a> must return the <code class="idl"><a data-link-type="idl" href="#dom-disconnectedaccount-account_id" id="ref-for-dom-disconnectedaccount-account_id②">account_id</a></code> since it may be different from the <code class="idl"><a data-link-type="idl" href="#dom-disconnect_endpoint_request-account_hint" id="ref-for-dom-disconnect_endpoint_request-account_hint">account_hint</a></code>, and the ID is the one which allows the <a data-link-type="dfn" href="https://infra.spec.whatwg.org/#user-agent" id="ref-for-user-agent①⑤">user agent</a> to disconnect the account from the <a data-link-type="dfn" href="#connected-accounts-set" id="ref-for-connected-accounts-set①②">connected accounts set</a>. If the <a data-link-type="dfn" href="#idp" id="ref-for-idp⑥⓪">IDP</a> returns an error or
+the <a data-link-type="dfn" href="https://infra.spec.whatwg.org/#user-agent" id="ref-for-user-agent①⑥">user agent</a> does not find the account with the ID provided by the <a data-link-type="dfn" href="#idp" id="ref-for-idp⑥①">IDP</a>, then all accounts
+associated with the relevant (<a data-link-type="dfn" href="#rp" id="ref-for-rp④⑦">RP</a>, <a data-link-type="dfn" href="#idp" id="ref-for-idp⑥②">IDP</a>) are removed from the <a data-link-type="dfn" href="#connected-accounts-set" id="ref-for-connected-accounts-set①③">connected accounts set</a>.</p>
    <h2 class="heading settled" data-level="4" id="permissions-policy-integration"><span class="secno">4. </span><span class="content">Permissions Policy Integration</span><a class="self-link" href="#permissions-policy-integration"></a></h2>
    <p>FedCM defines a <a data-link-type="dfn" href="https://w3c.github.io/webappsec-permissions-policy/#policy-controlled-feature" id="ref-for-policy-controlled-feature②">policy-controlled feature</a> identified by the string <code>"<dfn class="dfn-paneled" data-dfn-type="dfn" data-export id="identity-credentials-get">identity-credentials-get</dfn>"</code>.
 Its <a data-link-type="dfn" href="https://w3c.github.io/webappsec-permissions-policy/#policy-controlled-feature-default-allowlist" id="ref-for-policy-controlled-feature-default-allowlist">default allowlist</a> is <code>"self"</code>.</p>
@@ -3493,23 +3492,23 @@ <h2 class="heading settled" data-level="6" id="security"><span class="secno">6.
 separate section for <a href="#privacy">§ 7 Privacy</a> considerations.</p>
    <h3 class="heading settled" data-level="6.1" id="content-security-policy"><span class="secno">6.1. </span><span class="content">Content Security Policy</span><a class="self-link" href="#content-security-policy"></a></h3>
    <p>The first fetches triggered by the FedCM API are the manifest list, which is public, and the <a data-link-type="dfn" href="#config-file" id="ref-for-config-file①">config file</a>. Imagine a malicious script included by (and running as) the <a data-link-type="dfn" href="#rp" id="ref-for-rp④⑧">RP</a> attempting to
-execute the FedCM API calls to a malicious <a data-link-type="dfn" href="#idp" id="ref-for-idp⑥④">IDP</a>, one which is not trusted by the <a data-link-type="dfn" href="#rp" id="ref-for-rp④⑨">RP</a>. If the
+execute the FedCM API calls to a malicious <a data-link-type="dfn" href="#idp" id="ref-for-idp⑥③">IDP</a>, one which is not trusted by the <a data-link-type="dfn" href="#rp" id="ref-for-rp④⑨">RP</a>. If the
 call is successful, this would introduce browser UI on the <a data-link-type="dfn" href="#rp" id="ref-for-rp⑤⓪">RP</a> with sign in options into a
-malicious <a data-link-type="dfn" href="#idp" id="ref-for-idp⑥⑤">IDP</a>. This malicious<a data-link-type="dfn" href="#idp" id="ref-for-idp⑥⑥">IDP</a> could then attempt to trick the user. The protection
+malicious <a data-link-type="dfn" href="#idp" id="ref-for-idp⑥④">IDP</a>. This malicious<a data-link-type="dfn" href="#idp" id="ref-for-idp⑥⑤">IDP</a> could then attempt to trick the user. The protection
 against this attack is the <a data-link-type="biblio" href="https://w3c.github.io/webappsec-csp/"><cite>Content Security Policy Level 3</cite></a> check, which would fail because the origin of the manifest of
-the malicious <a data-link-type="dfn" href="#idp" id="ref-for-idp⑥⑦">IDP</a> would not be an origin included in the allowlist specified by the <a data-link-type="biblio" href="https://w3c.github.io/webappsec-csp/"><cite>Content Security Policy Level 3</cite></a> of
+the malicious <a data-link-type="dfn" href="#idp" id="ref-for-idp⑥⑥">IDP</a> would not be an origin included in the allowlist specified by the <a data-link-type="biblio" href="https://w3c.github.io/webappsec-csp/"><cite>Content Security Policy Level 3</cite></a> of
 the <a data-link-type="dfn" href="#rp" id="ref-for-rp⑤①">RP</a>, hence preventing the undesired FedCM UI from being shown. Since any subsequent fetches
 are same origin with respect to the <a data-link-type="dfn" href="#config-file" id="ref-for-config-file②">config file</a> or at least dependent on the contents of the <a data-link-type="dfn" href="#config-file" id="ref-for-config-file③">config file</a>, they do not require additional checks.</p>
    <p>The non-same-origin fetches include, for example, the brand icon. The user agent does not perform a <a data-link-type="biblio" href="https://w3c.github.io/webappsec-csp/"><cite>Content Security Policy Level 3</cite></a> check on these because they are directly specified from the manifest. In addition, the
 rendering of this image is performed by the user agent, and as such this image cannot affect the <a data-link-type="dfn" href="#rp" id="ref-for-rp⑤②">RP</a> site nor can they be inspected by the <a data-link-type="dfn" href="#rp" id="ref-for-rp⑤③">RP</a> in any way.</p>
    <h3 class="heading settled" data-level="6.2" id="sec-fetch-dest-header"><span class="secno">6.2. </span><span class="content">Sec-Fetch-Dest Header</span><a class="self-link" href="#sec-fetch-dest-header"></a></h3>
-   <p>The FedCM API introduces several non-static endpoints on the <a data-link-type="dfn" href="#idp" id="ref-for-idp⑥⑧">IDP</a>, so these need to be protected
+   <p>The FedCM API introduces several non-static endpoints on the <a data-link-type="dfn" href="#idp" id="ref-for-idp⑥⑦">IDP</a>, so these need to be protected
 from XSS attacks. In order to do so, the FedCM API introduces a new value for the <a data-link-type="http-header" href="https://w3c.github.io/webappsec-fetch-metadata/#http-headerdef-sec-fetch-dest" id="ref-for-http-headerdef-sec-fetch-dest⑥">Sec-Fetch-Dest</a> header, a <a data-link-type="dfn" href="https://fetch.spec.whatwg.org/#forbidden-request-header" id="ref-for-forbidden-request-header">forbidden request-header</a>. The requests initiated by the FedCM API
-have a <code>webidentity</code> value for this header. The value cannot be set by random websites, so the <a data-link-type="dfn" href="#idp" id="ref-for-idp⑥⑨">IDP</a> can be confident that the request was originated by the FedCM browser rather than sent by a
-websites trying to run an XSS attack. An <a data-link-type="dfn" href="#idp" id="ref-for-idp⑦⓪">IDP</a> needs to check for this header’s value in the
+have a <code>webidentity</code> value for this header. The value cannot be set by random websites, so the <a data-link-type="dfn" href="#idp" id="ref-for-idp⑥⑧">IDP</a> can be confident that the request was originated by the FedCM browser rather than sent by a
+websites trying to run an XSS attack. An <a data-link-type="dfn" href="#idp" id="ref-for-idp⑥⑨">IDP</a> needs to check for this header’s value in the
 credentialed requests it receives, which ensures that the request was initiated by the user agent,
 based on the FedCM API. A malicious actor cannot spam FedCM API calls, so this is sufficient
-protection for the new <a data-link-type="dfn" href="#idp" id="ref-for-idp⑦①">IDP</a> endpoints.</p>
+protection for the new <a data-link-type="dfn" href="#idp" id="ref-for-idp⑦⓪">IDP</a> endpoints.</p>
    <h3 class="heading settled" data-level="6.3" id="browser-surface-impersonation"><span class="secno">6.3. </span><span class="content">Browser Surface Impersonation</span><a class="self-link" href="#browser-surface-impersonation"></a></h3>
    <p>The FedCM API introduces new (trusted) user agent UI, and the user agent may choose to show the UI
 entirely on top of the page’s contents, if anything because the page was the one responsible for
@@ -3517,7 +3516,7 @@ <h3 class="heading settled" data-level="6.3" id="browser-surface-impersonation">
 gain the user’s trust that the user is interacting with a trusted browser surface, and gather
 information from the user that they would only give to the browser rather than the site (e.g.
 usernames/passwords of <strong>another</strong> site). This would be hard to achieve because the FedCM UI uses
-metadata about the user accounts of the <a data-link-type="dfn" href="#idp" id="ref-for-idp⑦②">IDP</a>, which the malicious website doesn’t have access to.
+metadata about the user accounts of the <a data-link-type="dfn" href="#idp" id="ref-for-idp⑦①">IDP</a>, which the malicious website doesn’t have access to.
 If this is a malicious site, it would not know the user accounts unless the user is already
 compromised. However, the site could have some guess of the user identity, so the browser is
 encouraged to provide UI that is hard to replicate and that clearly presents the domains of the
@@ -3537,19 +3536,19 @@ <h3 class="heading settled" data-level="7.1" id="privacy-principals"><span class
 expectations around their behavior.</p>
    <ol>
     <li data-md>
-     <p>The <a data-link-type="dfn" href="https://infra.spec.whatwg.org/#user-agent" id="ref-for-user-agent①⑦">user agent</a> implements <a href="#browser-api">§ 2 The Browser API</a> and controls the execution contexts for the <a data-link-type="dfn" href="#rp" id="ref-for-rp⑤④">RP</a> and <a data-link-type="dfn" href="#idp" id="ref-for-idp⑦③">IDP</a> content. The <a data-link-type="dfn" href="https://infra.spec.whatwg.org/#user-agent" id="ref-for-user-agent①⑧">user agent</a> is assumed to be trusted by the user, and transitively
-trusted by the <a data-link-type="dfn" href="#rp" id="ref-for-rp⑤⑤">RP</a> and <a data-link-type="dfn" href="#idp" id="ref-for-idp⑦④">IDP</a>.</p>
+     <p>The <a data-link-type="dfn" href="https://infra.spec.whatwg.org/#user-agent" id="ref-for-user-agent①⑦">user agent</a> implements <a href="#browser-api">§ 2 The Browser API</a> and controls the execution contexts for the <a data-link-type="dfn" href="#rp" id="ref-for-rp⑤④">RP</a> and <a data-link-type="dfn" href="#idp" id="ref-for-idp⑦②">IDP</a> content. The <a data-link-type="dfn" href="https://infra.spec.whatwg.org/#user-agent" id="ref-for-user-agent①⑧">user agent</a> is assumed to be trusted by the user, and transitively
+trusted by the <a data-link-type="dfn" href="#rp" id="ref-for-rp⑤⑤">RP</a> and <a data-link-type="dfn" href="#idp" id="ref-for-idp⑦③">IDP</a>.</p>
     <li data-md>
      <p><a data-link-type="dfn" href="#rp" id="ref-for-rp⑤⑥">RP</a>s are websites that invoke the FedCM API for the purpose of
 authenticating a user to their account or for requesting information about that user. Since any
 site can invoke the API, <a data-link-type="dfn" href="#rp" id="ref-for-rp⑤⑦">RP</a>s cannot necessarily be trusted to limit the user information it
 collects or use that information in an acceptable way.</p>
     <li data-md>
-     <p><a data-link-type="dfn" href="#idp" id="ref-for-idp⑦⑤">IDP</a>s are third-party websites that are the target of a FedCM call to
-attempt to fetch a token. Usually,the <a data-link-type="dfn" href="#idp" id="ref-for-idp⑦⑥">IDP</a> has a higher level of trust than the <a data-link-type="dfn" href="#rp" id="ref-for-rp⑤⑧">RP</a> since it already has the user’s personal information, but it is possible that the <a data-link-type="dfn" href="#idp" id="ref-for-idp⑦⑦">IDP</a> might use the user’s information in non-approved ways. In addition, it is possible that the <a data-link-type="dfn" href="#idp" id="ref-for-idp⑦⑧">IDP</a> specified in the API call may not be an <a data-link-type="dfn" href="#idp" id="ref-for-idp⑦⑨">IDP</a> the user knows about. In this case, it
+     <p><a data-link-type="dfn" href="#idp" id="ref-for-idp⑦④">IDP</a>s are third-party websites that are the target of a FedCM call to
+attempt to fetch a token. Usually,the <a data-link-type="dfn" href="#idp" id="ref-for-idp⑦⑤">IDP</a> has a higher level of trust than the <a data-link-type="dfn" href="#rp" id="ref-for-rp⑤⑧">RP</a> since it already has the user’s personal information, but it is possible that the <a data-link-type="dfn" href="#idp" id="ref-for-idp⑦⑥">IDP</a> might use the user’s information in non-approved ways. In addition, it is possible that the <a data-link-type="dfn" href="#idp" id="ref-for-idp⑦⑦">IDP</a> specified in the API call may not be an <a data-link-type="dfn" href="#idp" id="ref-for-idp⑦⑧">IDP</a> the user knows about. In this case, it
 likely does not have personal user information in advance.</p>
     <li data-md>
-     <p>A <dfn class="dfn-paneled" data-dfn-type="dfn" data-noexport id="tracker">tracker</dfn> is a third-party website that is not an <a data-link-type="dfn" href="#idp" id="ref-for-idp⑧⓪">IDP</a> but could abuse the FedCM API
+     <p>A <dfn class="dfn-paneled" data-dfn-type="dfn" data-noexport id="tracker">tracker</dfn> is a third-party website that is not an <a data-link-type="dfn" href="#idp" id="ref-for-idp⑦⑨">IDP</a> but could abuse the FedCM API
 exclusively for the purpose of tracking a user as they visit various websites. A <a data-link-type="dfn" href="#tracker" id="ref-for-tracker">tracker</a> may
 be injected by the <a data-link-type="dfn" href="#rp" id="ref-for-rp⑤⑨">RP</a> with or without their knowledge (e.g. injected into one of the various
 script tags that the <a data-link-type="dfn" href="#rp" id="ref-for-rp⑥⓪">RP</a> embeds that is loaded dynamically), but they usually do not modify
@@ -3561,16 +3560,16 @@ <h3 class="heading settled" data-level="7.1" id="privacy-principals"><span class
    <p>Based on the above, the privacy discussion makes the following assumptions:</p>
    <ol>
     <li data-md>
-     <p>It is not acceptable for an <a data-link-type="dfn" href="#rp" id="ref-for-rp⑥①">RP</a>, <a data-link-type="dfn" href="#idp" id="ref-for-idp⑧①">IDP</a>, or <a data-link-type="dfn" href="#tracker" id="ref-for-tracker③">tracker</a> to learn that a specific user visited a
+     <p>It is not acceptable for an <a data-link-type="dfn" href="#rp" id="ref-for-rp⑥①">RP</a>, <a data-link-type="dfn" href="#idp" id="ref-for-idp⑧⓪">IDP</a>, or <a data-link-type="dfn" href="#tracker" id="ref-for-tracker③">tracker</a> to learn that a specific user visited a
 specific site, without any permission granted by the user. That is, the <a data-link-type="dfn" href="https://infra.spec.whatwg.org/#user-agent" id="ref-for-user-agent①⑨">user agent</a> needs to hide the
-knowledge that a specific user identity visited a specific site from the <a data-link-type="dfn" href="#rp" id="ref-for-rp⑥②">RP</a>, <a data-link-type="dfn" href="#idp" id="ref-for-idp⑧②">IDP</a>, and <a data-link-type="dfn" href="#tracker" id="ref-for-tracker④">trackers</a>. It may share this knowledge with the <a data-link-type="dfn" href="#rp" id="ref-for-rp⑥③">RP</a> and <a data-link-type="dfn" href="#idp" id="ref-for-idp⑧③">IDP</a> once the user grants permission. In
-particular, the <a data-link-type="dfn" href="#rp" id="ref-for-rp⑥④">RP</a> should not know the user identity and the <a data-link-type="dfn" href="#idp" id="ref-for-idp⑧④">IDP</a> should not know the
+knowledge that a specific user identity visited a specific site from the <a data-link-type="dfn" href="#rp" id="ref-for-rp⑥②">RP</a>, <a data-link-type="dfn" href="#idp" id="ref-for-idp⑧①">IDP</a>, and <a data-link-type="dfn" href="#tracker" id="ref-for-tracker④">trackers</a>. It may share this knowledge with the <a data-link-type="dfn" href="#rp" id="ref-for-rp⑥③">RP</a> and <a data-link-type="dfn" href="#idp" id="ref-for-idp⑧②">IDP</a> once the user grants permission. In
+particular, the <a data-link-type="dfn" href="#rp" id="ref-for-rp⑥④">RP</a> should not know the user identity and the <a data-link-type="dfn" href="#idp" id="ref-for-idp⑧③">IDP</a> should not know the
 site that the user has visited before the FedCM flow gathers the user’s permission to do so.</p>
     <li data-md>
-     <p>It is the <a data-link-type="dfn" href="https://infra.spec.whatwg.org/#user-agent" id="ref-for-user-agent②⓪">user agent</a>'s responsibility to determine when the user has granted permission for the <a data-link-type="dfn" href="#idp" id="ref-for-idp⑧⑤">IDP</a> to communicate with the <a data-link-type="dfn" href="#rp" id="ref-for-rp⑥⑤">RP</a> in order to provide identification for the user.</p>
+     <p>It is the <a data-link-type="dfn" href="https://infra.spec.whatwg.org/#user-agent" id="ref-for-user-agent②⓪">user agent</a>'s responsibility to determine when the user has granted permission for the <a data-link-type="dfn" href="#idp" id="ref-for-idp⑧④">IDP</a> to communicate with the <a data-link-type="dfn" href="#rp" id="ref-for-rp⑥⑤">RP</a> in order to provide identification for the user.</p>
     <li data-md>
      <p>Once the <a data-link-type="dfn" href="https://infra.spec.whatwg.org/#user-agent" id="ref-for-user-agent②①">user agent</a> has determined that the user has granted permission to provide their
-account information to the <a data-link-type="dfn" href="#rp" id="ref-for-rp⑥⑥">RP</a>, it is ok for the <a data-link-type="dfn" href="#idp" id="ref-for-idp⑧⑥">IDP</a> and for the <a data-link-type="dfn" href="#rp" id="ref-for-rp⑥⑦">RP</a> to learn
+account information to the <a data-link-type="dfn" href="#rp" id="ref-for-rp⑥⑥">RP</a>, it is ok for the <a data-link-type="dfn" href="#idp" id="ref-for-idp⑧⑤">IDP</a> and for the <a data-link-type="dfn" href="#rp" id="ref-for-rp⑥⑦">RP</a> to learn
 information about that specific user’s account, as required to provide identification. The <a data-link-type="dfn" href="#rp" id="ref-for-rp⑥⑧">RP</a> should not learn about about any other user accounts.</p>
    </ol>
    <h3 class="heading settled" data-level="7.2" id="network-requests"><span class="secno">7.2. </span><span class="content">Network requests</span><a class="self-link" href="#network-requests"></a></h3>
@@ -3586,33 +3585,33 @@ <h3 class="heading settled" data-level="7.2" id="network-requests"><span class="
 or referrer. Thus, anyone could perform this fetch, and the information contained therein
 is considered public.</p>
     <li data-md>
-     <p>The <a data-link-type="dfn" href="#accounts-endpoint" id="ref-for-accounts-endpoint③">accounts endpoint</a> fetch can’t be used to track users because it is performed with cookies from the <a data-link-type="dfn" href="#idp" id="ref-for-idp⑧⑦">IDP</a> but, importantly, without the <code class="idl"><a data-link-type="idl" href="#dom-id_assertion_endpoint_request-client_id" id="ref-for-dom-id_assertion_endpoint_request-client_id②">client_id</a></code> or referrer. This in theory is a new power
+     <p>The <a data-link-type="dfn" href="#accounts-endpoint" id="ref-for-accounts-endpoint③">accounts endpoint</a> fetch can’t be used to track users because it is performed with cookies from the <a data-link-type="dfn" href="#idp" id="ref-for-idp⑧⑥">IDP</a> but, importantly, without the <code class="idl"><a data-link-type="idl" href="#dom-id_assertion_endpoint_request-client_id" id="ref-for-dom-id_assertion_endpoint_request-client_id②">client_id</a></code> or referrer. This in theory is a new power
 that the <a data-link-type="dfn" href="#rp" id="ref-for-rp⑦⓪">RP</a> gains that it would not have otherwise. Preventing too many of these fetches may
-be important, but <a data-link-type="dfn" href="#idp" id="ref-for-idp⑧⑧">IDP</a>s are already expected to protect against DoS attacks. In addition, the
+be important, but <a data-link-type="dfn" href="#idp" id="ref-for-idp⑧⑦">IDP</a>s are already expected to protect against DoS attacks. In addition, the
 user agent should only allow one FedCM flow per page at any given moment, immediately rejecting
 any attempts to start another one. Since a FedCM flow can only be terminated when the user
-interacts or after a long timer, the number of fetches performed is not a concern. The <a data-link-type="dfn" href="#idp" id="ref-for-idp⑧⑨">IDP</a> does learn a lot about the user from this fetch, but this is discussed in detail below.</p>
+interacts or after a long timer, the number of fetches performed is not a concern. The <a data-link-type="dfn" href="#idp" id="ref-for-idp⑧⑧">IDP</a> does learn a lot about the user from this fetch, but this is discussed in detail below.</p>
     <li data-md>
      <p>The <a data-link-type="dfn" href="#client-metadata-endpoint" id="ref-for-client-metadata-endpoint②">client metadata endpoint</a> fetch can’t be used to track users too because it is performed without cookies
-from the <a data-link-type="dfn" href="#idp" id="ref-for-idp⑨⓪">IDP</a>, albeit with a <code class="idl"><a data-link-type="idl" href="#dom-id_assertion_endpoint_request-client_id" id="ref-for-dom-id_assertion_endpoint_request-client_id③">client_id</a></code> and a referrer. This allows the <a data-link-type="dfn" href="#idp" id="ref-for-idp⑨①">IDP</a> to
+from the <a data-link-type="dfn" href="#idp" id="ref-for-idp⑧⑨">IDP</a>, albeit with a <code class="idl"><a data-link-type="idl" href="#dom-id_assertion_endpoint_request-client_id" id="ref-for-dom-id_assertion_endpoint_request-client_id③">client_id</a></code> and a referrer. This allows the <a data-link-type="dfn" href="#idp" id="ref-for-idp⑨⓪">IDP</a> to
 communicate the relevant Privacy Policy and Terms of Service to the user agent, in case
 they need to be displayed. Again, besides possible timing attacks described here, the <a data-link-type="dfn" href="#rp" id="ref-for-rp⑦①">RP</a> gains nothing from this fetch, and the <a data-link-type="dfn" href="#rp" id="ref-for-rp⑦②">RP</a> could already perform this fetch if it wanted to
-since it involves no cookies from the <a data-link-type="dfn" href="#idp" id="ref-for-idp⑨②">IDP</a>.</p>
+since it involves no cookies from the <a data-link-type="dfn" href="#idp" id="ref-for-idp⑨①">IDP</a>.</p>
     <li data-md>
-     <p>By design, the token fetch exposes the user at the website to the <a data-link-type="dfn" href="#idp" id="ref-for-idp⑨③">IDP</a>: it is
+     <p>By design, the token fetch exposes the user at the website to the <a data-link-type="dfn" href="#idp" id="ref-for-idp⑨②">IDP</a>: it is
 peformed with cookies, <code class="idl"><a data-link-type="idl" href="#dom-id_assertion_endpoint_request-client_id" id="ref-for-dom-id_assertion_endpoint_request-client_id④">client_id</a></code>, and referrer. Because of that, it is gated on the user
-interacting with the user agent UI, and enables the <a data-link-type="dfn" href="#idp" id="ref-for-idp⑨④">IDP</a> to communicate to the <a data-link-type="dfn" href="#rp" id="ref-for-rp⑦③">RP</a> the
+interacting with the user agent UI, and enables the <a data-link-type="dfn" href="#idp" id="ref-for-idp⑨③">IDP</a> to communicate to the <a data-link-type="dfn" href="#rp" id="ref-for-rp⑦③">RP</a> the
 information required to perform a federated signin/signup. It is not possible for the <a data-link-type="dfn" href="#rp" id="ref-for-rp⑦④">RP</a> or
-the <a data-link-type="dfn" href="#idp" id="ref-for-idp⑨⑤">IDP</a> to force the token fetch to happen without user permission, as the user agent cannot be
+the <a data-link-type="dfn" href="#idp" id="ref-for-idp⑨④">IDP</a> to force the token fetch to happen without user permission, as the user agent cannot be
 spoofed or otherwise tricked.</p>
     <li data-md>
      <p>The <a data-link-type="dfn" href="#disconnect-endpoint" id="ref-for-disconnect-endpoint①">disconnect endpoint</a> may only be fetched after the user has successfully gone through the
-FedCM flow at least once in the <a data-link-type="dfn" href="#rp" id="ref-for-rp⑦⑤">RP</a>. It sends a credentialed request to the <a data-link-type="dfn" href="#idp" id="ref-for-idp⑨⑥">IDP</a>, so it
+FedCM flow at least once in the <a data-link-type="dfn" href="#rp" id="ref-for-rp⑦⑤">RP</a>. It sends a credentialed request to the <a data-link-type="dfn" href="#idp" id="ref-for-idp⑨⑤">IDP</a>, so it
 is important that the <a data-link-type="dfn" href="https://infra.spec.whatwg.org/#user-agent" id="ref-for-user-agent②②">user agent</a> does not allow unlimited requests of such type, even after
 the user has used FedCM once. For this reason, any time that disconnection sends a credentialed
 request, at least one account is removed from the <a data-link-type="dfn" href="#connected-accounts-set" id="ref-for-connected-accounts-set①④">connected accounts set</a>, thus ensuring that
-this endpoint does not introduce a way for the <a data-link-type="dfn" href="#rp" id="ref-for-rp⑦⑥">RP</a> to send requests to the <a data-link-type="dfn" href="#idp" id="ref-for-idp⑨⑦">IDP</a> containing
-the <a data-link-type="dfn" href="#idp" id="ref-for-idp⑨⑧">IDP</a> cookies forever.</p>
+this endpoint does not introduce a way for the <a data-link-type="dfn" href="#rp" id="ref-for-rp⑦⑥">RP</a> to send requests to the <a data-link-type="dfn" href="#idp" id="ref-for-idp⑨⑥">IDP</a> containing
+the <a data-link-type="dfn" href="#idp" id="ref-for-idp⑨⑦">IDP</a> cookies forever.</p>
    </ul>
    <h3 class="heading settled" data-level="7.3" id="attack-scenarios"><span class="secno">7.3. </span><span class="content">Attack Scenarios</span><a class="self-link" href="#attack-scenarios"></a></h3>
    <p>This section describes the scenarios in which various agents might attempt to gain user information.
@@ -3621,14 +3620,14 @@ <h3 class="heading settled" data-level="7.3" id="attack-scenarios"><span class="
     <li data-md>
      <p>The <a data-link-type="dfn" href="#rp" id="ref-for-rp⑦⑦">RP</a> is collecting information,</p>
     <li data-md>
-     <p>The <a data-link-type="dfn" href="#idp" id="ref-for-idp⑨⑨">IDP</a> is collecting information, or</p>
+     <p>The <a data-link-type="dfn" href="#idp" id="ref-for-idp⑨⑧">IDP</a> is collecting information, or</p>
     <li data-md>
-     <p>Both the <a data-link-type="dfn" href="#rp" id="ref-for-rp⑦⑧">RP</a> and the <a data-link-type="dfn" href="#idp" id="ref-for-idp①⓪⓪">IDP</a> are colluding.</p>
+     <p>Both the <a data-link-type="dfn" href="#rp" id="ref-for-rp⑦⑧">RP</a> and the <a data-link-type="dfn" href="#idp" id="ref-for-idp⑨⑨">IDP</a> are colluding.</p>
    </ul>
    <p>For the purposes of this section, a principal is considered to be participating in the collection of
 information if it directly or indirectly performs actions with the aim of realizing one of the above
 threats.</p>
-   <p class="note" role="note"><span class="marker">Note:</span> An example of indirect collusion would be an <a data-link-type="dfn" href="#rp" id="ref-for-rp⑦⑨">RP</a> importing a script supplied by an <a data-link-type="dfn" href="#idp" id="ref-for-idp①⓪①">IDP</a> where the <a data-link-type="dfn" href="#idp" id="ref-for-idp①⓪②">IDP</a> intends to track users.</p>
+   <p class="note" role="note"><span class="marker">Note:</span> An example of indirect collusion would be an <a data-link-type="dfn" href="#rp" id="ref-for-rp⑦⑨">RP</a> importing a script supplied by an <a data-link-type="dfn" href="#idp" id="ref-for-idp①⓪⓪">IDP</a> where the <a data-link-type="dfn" href="#idp" id="ref-for-idp①⓪①">IDP</a> intends to track users.</p>
    <p>For the purpose of discussion, this document assumes that third-party cookies are <strong>disabled</strong> by
 default and are no longer effective for use in tracking mechanisms, and also some form of
 mitigations are implemented against ‘bounce tracking’ using link decoration or postMessage. Most of
@@ -3649,21 +3648,21 @@ <h4 class="heading settled" data-level="7.3.1" id="manifest-fingerprinting"><spa
 </pre>
    </div>
    <p class="note" role="note"><span class="marker">NOTE:</span> You can read more about the attack described <a href="https://github.com/fedidcg/FedCM/issues/230#issuecomment-1067029200">here</a>.</p>
-   <p>Here, the <a data-link-type="dfn" href="#rp" id="ref-for-rp⑧⓪">RP</a> includes identifies itself when fetching the manifest from the <a data-link-type="dfn" href="#idp" id="ref-for-idp①⓪③">IDP</a>. This
-coupled with the credentialed fetches that the FedCM API performs would enable the <a data-link-type="dfn" href="#idp" id="ref-for-idp①⓪④">IDP</a> to easily
+   <p>Here, the <a data-link-type="dfn" href="#rp" id="ref-for-rp⑧⓪">RP</a> includes identifies itself when fetching the manifest from the <a data-link-type="dfn" href="#idp" id="ref-for-idp①⓪②">IDP</a>. This
+coupled with the credentialed fetches that the FedCM API performs would enable the <a data-link-type="dfn" href="#idp" id="ref-for-idp①⓪③">IDP</a> to easily
 track the website that the user is visiting, without requiring any permission from the user. Our
 mitigation to this problem is to use the <a href="#idp-api-well-known">§ 3.1 The Well-Known File</a> file. The existence of a file at
-the root of the <a data-link-type="dfn" href="#idp" id="ref-for-idp①⓪⑤">IDP</a>'s domain is enforced to ensure that the file name does not introduce
+the root of the <a data-link-type="dfn" href="#idp" id="ref-for-idp①⓪④">IDP</a>'s domain is enforced to ensure that the file name does not introduce
 fingerprints about the <a data-link-type="dfn" href="#rp" id="ref-for-rp⑧①">RP</a> being visited.</p>
    <p>The whole manifest could be in this location, but instead it only points to the real
 manifest from there. This allows the flexibility in the future to allow a small constant
-number of manifests, should an <a data-link-type="dfn" href="#idp" id="ref-for-idp①⓪⑥">IDP</a> require this in the future, instead of just a single one. It
-also helps the <a data-link-type="dfn" href="#idp" id="ref-for-idp①⓪⑦">IDP</a>'s implementation because they any changes to the manifest are more likely to
+number of manifests, should an <a data-link-type="dfn" href="#idp" id="ref-for-idp①⓪⑤">IDP</a> require this in the future, instead of just a single one. It
+also helps the <a data-link-type="dfn" href="#idp" id="ref-for-idp①⓪⑥">IDP</a>'s implementation because they any changes to the manifest are more likely to
 be performed on a file located anywhere, as opposed to the root of the domain, which may have more
 constraints in terms of ease of update.</p>
    <h4 class="heading settled" data-level="7.3.2" id="timing-attacks"><span class="secno">7.3.2. </span><span class="content">Timing Attacks</span><a class="self-link" href="#timing-attacks"></a></h4>
-   <p>In the timing attack, the <a data-link-type="dfn" href="#rp" id="ref-for-rp⑧②">RP</a> and <a data-link-type="dfn" href="#idp" id="ref-for-idp①⓪⑧">IDP</a> collude to allow the <a data-link-type="dfn" href="#idp" id="ref-for-idp①⓪⑨">IDP</a> to compute the (<a data-link-type="dfn" href="#rp" id="ref-for-rp⑧③">RP</a>'s
-origin, <a data-link-type="dfn" href="#idp" id="ref-for-idp①①⓪">IDP</a>'s user identity) pair without the user’s permission. This attack is not deterministic:
+   <p>In the timing attack, the <a data-link-type="dfn" href="#rp" id="ref-for-rp⑧②">RP</a> and <a data-link-type="dfn" href="#idp" id="ref-for-idp①⓪⑦">IDP</a> collude to allow the <a data-link-type="dfn" href="#idp" id="ref-for-idp①⓪⑧">IDP</a> to compute the (<a data-link-type="dfn" href="#rp" id="ref-for-rp⑧③">RP</a>'s
+origin, <a data-link-type="dfn" href="#idp" id="ref-for-idp①⓪⑨">IDP</a>'s user identity) pair without the user’s permission. This attack is not deterministic:
 there is room for statistical error because it requires stitching together two separate pieces of
 information to track the user. However, it is important to mitigate this attack and ensure that
 it’s economically impractical to perform. In this attack, it is assumed that network requests do not
@@ -3675,20 +3674,20 @@ <h4 class="heading settled" data-level="7.3.2" id="timing-attacks"><span class="
    <p>The attack is as follows:</p>
    <ol>
     <li data-md>
-     <p>The <a data-link-type="dfn" href="#rp" id="ref-for-rp⑧④">RP</a> logs the time at which it invokes the API, time A and sends it to the <a data-link-type="dfn" href="#idp" id="ref-for-idp①①①">IDP</a> to
+     <p>The <a data-link-type="dfn" href="#rp" id="ref-for-rp⑧④">RP</a> logs the time at which it invokes the API, time A and sends it to the <a data-link-type="dfn" href="#idp" id="ref-for-idp①①⓪">IDP</a> to
 learn itself by marking the time in which it receives the fetch for the <a data-link-type="dfn" href="#rp" id="ref-for-rp⑧⑤">RP</a>'s client
 metadata. Time A is tied to the site.</p>
     <li data-md>
-     <p>A credentialed request is sent to the <a data-link-type="dfn" href="#idp" id="ref-for-idp①①②">IDP</a> that does not explicitly identify the <a data-link-type="dfn" href="#rp" id="ref-for-rp⑧⑥">RP</a>, but
-it is sent around a time that is close enough to the request above. The <a data-link-type="dfn" href="#idp" id="ref-for-idp①①③">IDP</a> notes the time
+     <p>A credentialed request is sent to the <a data-link-type="dfn" href="#idp" id="ref-for-idp①①①">IDP</a> that does not explicitly identify the <a data-link-type="dfn" href="#rp" id="ref-for-rp⑧⑥">RP</a>, but
+it is sent around a time that is close enough to the request above. The <a data-link-type="dfn" href="#idp" id="ref-for-idp①①②">IDP</a> notes the time
 in which this request has arrived, time B. Time B is tied to the user identity.</p>
     <li data-md>
-     <p>The <a data-link-type="dfn" href="#idp" id="ref-for-idp①①④">IDP</a> correlates time A and time B to find the (site, user identity) pair with high
+     <p>The <a data-link-type="dfn" href="#idp" id="ref-for-idp①①③">IDP</a> correlates time A and time B to find the (site, user identity) pair with high
 probability. Note that fingerprinting can make the correlation more accurate.</p>
    </ol>
    <p>Note that this kind of correlation is already possible without FedCM by using simple cross-origin
 top-level navigations, but using FedCM for this purpose would worsen the problem if it improved
-timing resolution or if it was less visible to users (e.g. the <a data-link-type="dfn" href="#idp" id="ref-for-idp①①⑤">IDP</a> could return empty accounts
+timing resolution or if it was less visible to users (e.g. the <a data-link-type="dfn" href="#idp" id="ref-for-idp①①④">IDP</a> could return empty accounts
 to the <a data-link-type="dfn" href="https://infra.spec.whatwg.org/#user-agent" id="ref-for-user-agent②⑤">user agent</a> to deliberately make no browser UI to be triggered, and hence make this attack
 invisible to the user).</p>
    <p>The <a data-link-type="dfn" href="https://infra.spec.whatwg.org/#user-agent" id="ref-for-user-agent②⑥">user agent</a> should mitigate this attack to protect users, in an interoperable way.</p>
@@ -3703,9 +3702,9 @@ <h4 class="heading settled" data-level="7.3.3" id="idp-intrusion"><span class="s
 Intrusion can thwart individuals' desires to be left alone, sap their time or attention, or
 interrupt their activities.</p>
    </blockquote>
-   <p>In the context of federation, intrusion happens when an <a data-link-type="dfn" href="#rp" id="ref-for-rp⑧⑦">RP</a> and an <a data-link-type="dfn" href="#idp" id="ref-for-idp①①⑥">IDP</a> are colluding to
+   <p>In the context of federation, intrusion happens when an <a data-link-type="dfn" href="#rp" id="ref-for-rp⑧⑦">RP</a> and an <a data-link-type="dfn" href="#idp" id="ref-for-idp①①⑤">IDP</a> are colluding to
 invasively and aggressively recommend the user to login disproportionally to the their intent. Much
-like unsolicited notifications, an <a data-link-type="dfn" href="#rp" id="ref-for-rp⑧⑧">RP</a> can collude with an <a data-link-type="dfn" href="#idp" id="ref-for-idp①①⑦">IDP</a> to aggressively log users in.</p>
+like unsolicited notifications, an <a data-link-type="dfn" href="#rp" id="ref-for-rp⑧⑧">RP</a> can collude with an <a data-link-type="dfn" href="#idp" id="ref-for-idp①①⑥">IDP</a> to aggressively log users in.</p>
    <p>The <a data-link-type="dfn" href="https://infra.spec.whatwg.org/#user-agent" id="ref-for-user-agent②⑦">user agent</a> can mitigate this by mediating the user controls and offering them proportionally
 to the intent of the user or the privacy risks involved. For example, a <a data-link-type="dfn" href="https://infra.spec.whatwg.org/#user-agent" id="ref-for-user-agent②⑧">user agent</a> can choose to
 show a loud / disruptive modal mediated dialog when it has enough confidence of the user’s intent or
@@ -3845,7 +3844,7 @@ <h4 class="heading settled" data-level="7.3.4" id="attack-scenarios-by-rp-cross-
 user and their activity across collaborating sites. Sometimes this is referred to as joining
 since it amounts to a join of user records between the account databases of multiple RPs. This
 correlation and profile-building is outside the user’s control and entirely out of the <a data-link-type="dfn" href="https://infra.spec.whatwg.org/#user-agent" id="ref-for-user-agent③⓪">user
-agent</a>’s or <a data-link-type="dfn" href="#idp" id="ref-for-idp①①⑧">IDP</a>’s view.</p>
+agent</a>’s or <a data-link-type="dfn" href="#idp" id="ref-for-idp①①⑦">IDP</a>’s view.</p>
    <div class="image">
     <svg height="100%" style="fill-rule:evenodd;clip-rule:evenodd;stroke-linejoin:round;stroke-miterlimit:10;" version="1.1" viewBox="0 0 6000 4500" width="100%" xmlnsU0003Aserif="http://www.serif.com/" xlink="http://www.w3.org/1999/xlink" xmlns="http://www.w3.org/2000/svg" space="preserve">
      <g transform="matrix(8.33333,0,0,8.33333,0,0)">
@@ -4001,9 +4000,9 @@ <h4 class="heading settled" data-level="7.3.4" id="attack-scenarios-by-rp-cross-
    </div>
    <p>The problem of <a data-link-type="dfn" href="#rp" id="ref-for-rp⑨⓪">RP</a>s joining user data via back-channels is inherent to the proliferation of
 identifying user data. This can be solved by issuing directed identifiers that provide an
-effective handle to a user’s identity with a given <a data-link-type="dfn" href="#idp" id="ref-for-idp①①⑨">IDP</a> that is unique and therefore cannot be
+effective handle to a user’s identity with a given <a data-link-type="dfn" href="#idp" id="ref-for-idp①①⑧">IDP</a> that is unique and therefore cannot be
 correlated with other <a data-link-type="dfn" href="#rp" id="ref-for-rp⑨①">RP</a>s. In the past, there have been schemes to accomplish this using one-way
-hashes of, for example, the user’s name, the <a data-link-type="dfn" href="#idp" id="ref-for-idp①②⓪">IDP</a>, and the <a data-link-type="dfn" href="#rp" id="ref-for-rp⑨②">RP</a>. These identifiers would be
+hashes of, for example, the user’s name, the <a data-link-type="dfn" href="#idp" id="ref-for-idp①①⑨">IDP</a>, and the <a data-link-type="dfn" href="#rp" id="ref-for-rp⑨②">RP</a>. These identifiers would be
 unique, and hence it would not be possible to correlate these with other <a data-link-type="dfn" href="#rp" id="ref-for-rp⑨③">RP</a>s.</p>
    <div class="image">
     <svg height="100%" style="fill-rule:evenodd;clip-rule:evenodd;stroke-linejoin:round;stroke-miterlimit:10;" version="1.1" viewBox="0 0 10667 8000" width="100%" xmlnsU0003Aserif="http://www.serif.com/" xlink="http://www.w3.org/1999/xlink" xmlns="http://www.w3.org/2000/svg" space="preserve">
@@ -4215,8 +4214,8 @@ <h4 class="heading settled" data-level="7.3.4" id="attack-scenarios-by-rp-cross-
     </svg>
    </div>
    <h4 class="heading settled" data-level="7.3.5" id="unauthorized-data-usage"><span class="secno">7.3.5. </span><span class="content">Unauthorized Data Usage</span><a class="self-link" href="#unauthorized-data-usage"></a></h4>
-   <p>Another attack is when the <a data-link-type="dfn" href="#rp" id="ref-for-rp⑨④">RP</a> or <a data-link-type="dfn" href="#idp" id="ref-for-idp①②①">IDP</a> uses user information for purposes not authorized by
-the user. When the user agrees to allow the <a data-link-type="dfn" href="#idp" id="ref-for-idp①②②">IDP</a> to provide information to the <a data-link-type="dfn" href="#rp" id="ref-for-rp⑨⑤">RP</a>, the
+   <p>Another attack is when the <a data-link-type="dfn" href="#rp" id="ref-for-rp⑨④">RP</a> or <a data-link-type="dfn" href="#idp" id="ref-for-idp①②⓪">IDP</a> uses user information for purposes not authorized by
+the user. When the user agrees to allow the <a data-link-type="dfn" href="#idp" id="ref-for-idp①②①">IDP</a> to provide information to the <a data-link-type="dfn" href="#rp" id="ref-for-rp⑨⑤">RP</a>, the
 permission is specific to certain purposes, such as sign-in and personalization. For instance, the <a data-link-type="dfn" href="#rp" id="ref-for-rp⑨⑥">RP</a> might use that data for other purposes that the user would not expect and did not authorize,
 such as selling email addresses to a spam list. Spamming risk can exist even when using
 directed identifiers.</p>
@@ -4277,14 +4276,14 @@ <h4 class="heading settled" data-level="7.3.6" id="rp-fingerprinting"><span clas
    <h4 class="heading settled" data-level="7.3.7" id="secondary-use"><span class="secno">7.3.7. </span><span class="content">Secondary Use</span><a class="self-link" href="#secondary-use"></a></h4>
    <p>Secondary use is the use of collected information about an individual without the individual’s
 perimssion for a purpose different from that for which the information was collected. This attack
-happens when <a data-link-type="dfn" href="#idp" id="ref-for-idp①②③">IDP</a>s misuse the information collected to enable sign-in for other purposes.</p>
-   <p>Existing federation protocols require that the <a data-link-type="dfn" href="#idp" id="ref-for-idp①②④">IDP</a> know which service is requesting a token
+happens when <a data-link-type="dfn" href="#idp" id="ref-for-idp①②②">IDP</a>s misuse the information collected to enable sign-in for other purposes.</p>
+   <p>Existing federation protocols require that the <a data-link-type="dfn" href="#idp" id="ref-for-idp①②③">IDP</a> know which service is requesting a token
 in order to allow identity federation. Identity providers can use this fact to build profiles of
 users across sites where the user has decided to use federation with the same account. This profile
 could be used, for example, to serve targeted advertisements to those users browsing on sites that
 the IDP controls.</p>
-   <p>This risk can exist even in the case where the <a data-link-type="dfn" href="#idp" id="ref-for-idp①②⑤">IDP</a> does not having pre-existing user account
-information (for instance, if it is not a _bona fide_ IDP), because FedCM requests sent to the <a data-link-type="dfn" href="#idp" id="ref-for-idp①②⑥">IDP</a> are credentialed. This is more likely to occur if the <a data-link-type="dfn" href="#rp" id="ref-for-rp①⓪⓪">RP</a> is colluding with the <a data-link-type="dfn" href="#idp" id="ref-for-idp①②⑦">IDP</a> to enable tracking via <a href="#timing-attacks">§ 7.3.2 Timing Attacks</a>.</p>
+   <p>This risk can exist even in the case where the <a data-link-type="dfn" href="#idp" id="ref-for-idp①②④">IDP</a> does not having pre-existing user account
+information (for instance, if it is not a _bona fide_ IDP), because FedCM requests sent to the <a data-link-type="dfn" href="#idp" id="ref-for-idp①②⑤">IDP</a> are credentialed. This is more likely to occur if the <a data-link-type="dfn" href="#rp" id="ref-for-rp①⓪⓪">RP</a> is colluding with the <a data-link-type="dfn" href="#idp" id="ref-for-idp①②⑥">IDP</a> to enable tracking via <a href="#timing-attacks">§ 7.3.2 Timing Attacks</a>.</p>
    <div class="image">
     <svg height="100%" style="fill-rule:evenodd;clip-rule:evenodd;stroke-linejoin:round;stroke-miterlimit:10;" version="1.1" viewBox="0 0 10667 8000" width="100%" xmlnsU0003Aserif="http://www.serif.com/" xlink="http://www.w3.org/1999/xlink" xmlns="http://www.w3.org/2000/svg" space="preserve">
      <g transform="matrix(8.33333,0,0,8.33333,0,0)">
@@ -4397,21 +4396,21 @@ <h4 class="heading settled" data-level="7.3.7" id="secondary-use"><span class="s
     <a class="self-link" href="#example-ee3423e4"></a> 
     <ol>
      <li data-md>
-      <p>User signs into RP1 (which sells jewelry) with an <a data-link-type="dfn" href="#idp" id="ref-for-idp①②⑧">IDP</a>.</p>
+      <p>User signs into RP1 (which sells jewelry) with an <a data-link-type="dfn" href="#idp" id="ref-for-idp①②⑦">IDP</a>.</p>
      <li data-md>
-      <p>User signs into RP2 (which sells houses) with the same <a data-link-type="dfn" href="#idp" id="ref-for-idp①②⑨">IDP</a>.</p>
+      <p>User signs into RP2 (which sells houses) with the same <a data-link-type="dfn" href="#idp" id="ref-for-idp①②⑧">IDP</a>.</p>
      <li data-md>
-      <p>User navigates to the <a data-link-type="dfn" href="#idp" id="ref-for-idp①③⓪">IDP</a>.</p>
+      <p>User navigates to the <a data-link-type="dfn" href="#idp" id="ref-for-idp①②⑨">IDP</a>.</p>
      <li data-md>
-      <p>Because the <a data-link-type="dfn" href="#idp" id="ref-for-idp①③①">IDP</a> knows that the user has an account with RP1 and RP2, the <a data-link-type="dfn" href="#idp" id="ref-for-idp①③②">IDP</a> can show ads about vacations for honeymoons.</p>
+      <p>Because the <a data-link-type="dfn" href="#idp" id="ref-for-idp①③⓪">IDP</a> knows that the user has an account with RP1 and RP2, the <a data-link-type="dfn" href="#idp" id="ref-for-idp①③①">IDP</a> can show ads about vacations for honeymoons.</p>
      <li data-md>
-      <p>The user is surprised that their <a data-link-type="dfn" href="#idp" id="ref-for-idp①③③">IDP</a> is aware of their plans to get
+      <p>The user is surprised that their <a data-link-type="dfn" href="#idp" id="ref-for-idp①③②">IDP</a> is aware of their plans to get
 married.</p>
     </ol>
    </div>
-   <p>Preventing tracking of users by the <a data-link-type="dfn" href="#idp" id="ref-for-idp①③④">IDP</a> is difficult: the <a data-link-type="dfn" href="#rp" id="ref-for-rp①⓪①">RP</a> has to be coded into the
+   <p>Preventing tracking of users by the <a data-link-type="dfn" href="#idp" id="ref-for-idp①③③">IDP</a> is difficult: the <a data-link-type="dfn" href="#rp" id="ref-for-rp①⓪①">RP</a> has to be coded into the
 identity token for security reasons, such as token reuse and fraud and abuse prevention. There have
-been cryptographic schemes developed to blind the <a data-link-type="dfn" href="#idp" id="ref-for-idp①③⑤">IDP</a> to the <a data-link-type="dfn" href="#rp" id="ref-for-rp①⓪②">RP</a> while still
+been cryptographic schemes developed to blind the <a data-link-type="dfn" href="#idp" id="ref-for-idp①③④">IDP</a> to the <a data-link-type="dfn" href="#rp" id="ref-for-rp①⓪②">RP</a> while still
 preventing token reuse(see Mozilla’s <a href="https://wiki.mozilla.org/Identity/Persona_AAR">personas</a>).
 These schemes have not been adopted by this specification.</p>
    <div class="image">
@@ -5646,7 +5645,7 @@ <h2 class="no-num no-ref heading settled" id="issues-index"><span class="content
 window.dfnpanelData['5f90bbfb'] = {"dfnID": "5f90bbfb", "url": "https://webidl.spec.whatwg.org/#idl-undefined", "dfnText": "undefined", "refSections": [{"refs": [{"id": "ref-for-idl-undefined"}], "title": "2.1.3. JavaScript API"}, {"refs": [{"id": "ref-for-idl-undefined\u2460"}], "title": "2.3. The IdentityCredential Interface"}, {"refs": [{"id": "ref-for-idl-undefined\u2461"}], "title": "2.4. The IdentityProvider Interface"}, {"refs": [{"id": "ref-for-idl-undefined\u2462"}], "title": "5.3. Select account"}, {"refs": [{"id": "ref-for-idl-undefined\u2463"}, {"id": "ref-for-idl-undefined\u2464"}], "title": "5.5. Account list"}, {"refs": [{"id": "ref-for-idl-undefined\u2465"}], "title": "5.8. Set delay enabled"}], "external": true};
 window.dfnpanelData['e97a9688'] = {"dfnID": "e97a9688", "url": "https://webidl.spec.whatwg.org/#idl-unsigned-long", "dfnText": "unsigned long", "refSections": [{"refs": [{"id": "ref-for-idl-unsigned-long"}], "title": "2.3.5. Fetch the config file"}, {"refs": [{"id": "ref-for-idl-unsigned-long\u2460"}], "title": "3.2. The config file"}], "external": true};
 window.dfnpanelData['rp'] = {"dfnID": "rp", "url": "#rp", "dfnText": "RP", "refSections": [{"refs": [{"id": "ref-for-rp"}, {"id": "ref-for-rp\u2460"}, {"id": "ref-for-rp\u2461"}], "title": "1. Introduction"}, {"refs": [{"id": "ref-for-rp\u2462"}, {"id": "ref-for-rp\u2463"}, {"id": "ref-for-rp\u2464"}, {"id": "ref-for-rp\u2465"}], "title": "2. The Browser API"}, {"refs": [{"id": "ref-for-rp\u2466"}], "title": "2.1.4. Clearing the Login Status Map data"}, {"refs": [{"id": "ref-for-rp\u2467"}, {"id": "ref-for-rp\u2468"}, {"id": "ref-for-rp\u2460\u24ea"}], "title": "2.2. The connected accounts set"}, {"refs": [{"id": "ref-for-rp\u2460\u2460"}], "title": "2.3.1.1. Disconnect request"}, {"refs": [{"id": "ref-for-rp\u2460\u2461"}, {"id": "ref-for-rp\u2460\u2462"}, {"id": "ref-for-rp\u2460\u2463"}, {"id": "ref-for-rp\u2460\u2464"}, {"id": "ref-for-rp\u2460\u2465"}, {"id": "ref-for-rp\u2460\u2466"}, {"id": "ref-for-rp\u2460\u2467"}], "title": "2.3.2. The CredentialRequestOptions"}, {"refs": [{"id": "ref-for-rp\u2460\u2468"}, {"id": "ref-for-rp\u2461\u24ea"}], "title": "2.3.4. Create an IdentityCredential"}, {"refs": [{"id": "ref-for-rp\u2461\u2460"}], "title": "2.3.5. Fetch the config file"}, {"refs": [{"id": "ref-for-rp\u2461\u2461"}], "title": "2.3.7. Fetch an identity assertion"}, {"refs": [{"id": "ref-for-rp\u2461\u2462"}], "title": "2.3.8. Request permission to sign-up"}, {"refs": [{"id": "ref-for-rp\u2461\u2463"}, {"id": "ref-for-rp\u2461\u2464"}], "title": "2.4. The IdentityProvider Interface"}, {"refs": [{"id": "ref-for-rp\u2461\u2465"}], "title": "3.1. The Well-Known File"}, {"refs": [{"id": "ref-for-rp\u2461\u2466"}], "title": "3.2. The config file"}, {"refs": [{"id": "ref-for-rp\u2461\u2467"}, {"id": "ref-for-rp\u2461\u2468"}, {"id": "ref-for-rp\u2462\u24ea"}, {"id": "ref-for-rp\u2462\u2460"}], "title": "3.3. Accounts endpoint"}, {"refs": [{"id": "ref-for-rp\u2462\u2461"}, {"id": "ref-for-rp\u2462\u2462"}, {"id": "ref-for-rp\u2462\u2463"}, {"id": "ref-for-rp\u2462\u2464"}], "title": "3.4. Client Metadata"}, {"refs": [{"id": "ref-for-rp\u2462\u2465"}, {"id": "ref-for-rp\u2462\u2466"}, {"id": "ref-for-rp\u2462\u2467"}, {"id": "ref-for-rp\u2462\u2468"}, {"id": "ref-for-rp\u2463\u24ea"}, {"id": "ref-for-rp\u2463\u2460"}, {"id": "ref-for-rp\u2463\u2461"}], "title": "3.5. Identity assertion endpoint"}, {"refs": [{"id": "ref-for-rp\u2463\u2462"}, {"id": "ref-for-rp\u2463\u2463"}, {"id": "ref-for-rp\u2463\u2464"}, {"id": "ref-for-rp\u2463\u2465"}, {"id": "ref-for-rp\u2463\u2466"}], "title": "3.6. Disconnect endpoint"}, {"refs": [{"id": "ref-for-rp\u2463\u2467"}, {"id": "ref-for-rp\u2463\u2468"}, {"id": "ref-for-rp\u2464\u24ea"}, {"id": "ref-for-rp\u2464\u2460"}, {"id": "ref-for-rp\u2464\u2461"}, {"id": "ref-for-rp\u2464\u2462"}], "title": "6.1. Content Security Policy"}, {"refs": [{"id": "ref-for-rp\u2464\u2463"}, {"id": "ref-for-rp\u2464\u2464"}, {"id": "ref-for-rp\u2464\u2465"}, {"id": "ref-for-rp\u2464\u2466"}, {"id": "ref-for-rp\u2464\u2467"}, {"id": "ref-for-rp\u2464\u2468"}, {"id": "ref-for-rp\u2465\u24ea"}, {"id": "ref-for-rp\u2465\u2460"}, {"id": "ref-for-rp\u2465\u2461"}, {"id": "ref-for-rp\u2465\u2462"}, {"id": "ref-for-rp\u2465\u2463"}, {"id": "ref-for-rp\u2465\u2464"}, {"id": "ref-for-rp\u2465\u2465"}, {"id": "ref-for-rp\u2465\u2466"}, {"id": "ref-for-rp\u2465\u2467"}], "title": "7.1. Principals"}, {"refs": [{"id": "ref-for-rp\u2465\u2468"}, {"id": "ref-for-rp\u2466\u24ea"}, {"id": "ref-for-rp\u2466\u2460"}, {"id": "ref-for-rp\u2466\u2461"}, {"id": "ref-for-rp\u2466\u2462"}, {"id": "ref-for-rp\u2466\u2463"}, {"id": "ref-for-rp\u2466\u2464"}, {"id": "ref-for-rp\u2466\u2465"}], "title": "7.2. Network requests"}, {"refs": [{"id": "ref-for-rp\u2466\u2466"}, {"id": "ref-for-rp\u2466\u2467"}, {"id": "ref-for-rp\u2466\u2468"}], "title": "7.3. Attack Scenarios"}, {"refs": [{"id": "ref-for-rp\u2467\u24ea"}, {"id": "ref-for-rp\u2467\u2460"}], "title": "7.3.1. Manifest Fingerprinting"}, {"refs": [{"id": "ref-for-rp\u2467\u2461"}, {"id": "ref-for-rp\u2467\u2462"}, {"id": "ref-for-rp\u2467\u2463"}, {"id": "ref-for-rp\u2467\u2464"}, {"id": "ref-for-rp\u2467\u2465"}], "title": "7.3.2. Timing Attacks"}, {"refs": [{"id": "ref-for-rp\u2467\u2466"}, {"id": "ref-for-rp\u2467\u2467"}], "title": "7.3.3. IDP Intrusion"}, {"refs": [{"id": "ref-for-rp\u2467\u2468"}, {"id": "ref-for-rp\u2468\u24ea"}, {"id": "ref-for-rp\u2468\u2460"}, {"id": "ref-for-rp\u2468\u2461"}, {"id": "ref-for-rp\u2468\u2462"}], "title": "7.3.4. Cross-Site Correlation"}, {"refs": [{"id": "ref-for-rp\u2468\u2463"}, {"id": "ref-for-rp\u2468\u2464"}, {"id": "ref-for-rp\u2468\u2465"}], "title": "7.3.5. Unauthorized Data Usage"}, {"refs": [{"id": "ref-for-rp\u2468\u2466"}, {"id": "ref-for-rp\u2468\u2467"}, {"id": "ref-for-rp\u2468\u2468"}], "title": "7.3.6. RP Fingerprinting"}, {"refs": [{"id": "ref-for-rp\u2460\u24ea\u24ea"}, {"id": "ref-for-rp\u2460\u24ea\u2460"}, {"id": "ref-for-rp\u2460\u24ea\u2461"}], "title": "7.3.7. Secondary Use"}], "external": false};
-window.dfnpanelData['idp'] = {"dfnID": "idp", "url": "#idp", "dfnText": "IDP", "refSections": [{"refs": [{"id": "ref-for-idp"}, {"id": "ref-for-idp\u2460"}, {"id": "ref-for-idp\u2461"}, {"id": "ref-for-idp\u2462"}], "title": "1. Introduction"}, {"refs": [{"id": "ref-for-idp\u2463"}, {"id": "ref-for-idp\u2464"}, {"id": "ref-for-idp\u2465"}], "title": "2. The Browser API"}, {"refs": [{"id": "ref-for-idp\u2466"}], "title": "2.1.1. Login Status Map"}, {"refs": [{"id": "ref-for-idp\u2467"}], "title": "2.1.2. HTTP header API"}, {"refs": [{"id": "ref-for-idp\u2468"}], "title": "2.1.3. JavaScript API"}, {"refs": [{"id": "ref-for-idp\u2460\u24ea"}, {"id": "ref-for-idp\u2460\u2460"}], "title": "2.1.4. Clearing the Login Status Map data"}, {"refs": [{"id": "ref-for-idp\u2460\u2461"}], "title": "2.2. The connected accounts set"}, {"refs": [{"id": "ref-for-idp\u2460\u2462"}], "title": "2.3. The IdentityCredential Interface"}, {"refs": [{"id": "ref-for-idp\u2460\u2463"}, {"id": "ref-for-idp\u2460\u2464"}, {"id": "ref-for-idp\u2460\u2465"}], "title": "2.3.2. The CredentialRequestOptions"}, {"refs": [{"id": "ref-for-idp\u2460\u2466"}], "title": "2.3.3. The [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) internal method"}, {"refs": [{"id": "ref-for-idp\u2460\u2467"}], "title": "2.3.4. Create an IdentityCredential"}, {"refs": [{"id": "ref-for-idp\u2460\u2468"}, {"id": "ref-for-idp\u2461\u24ea"}, {"id": "ref-for-idp\u2461\u2460"}, {"id": "ref-for-idp\u2461\u2461"}], "title": "2.3.5. Fetch the config file"}, {"refs": [{"id": "ref-for-idp\u2461\u2462"}], "title": "2.3.6. Fetch the accounts"}, {"refs": [{"id": "ref-for-idp\u2461\u2463"}], "title": "2.3.7. Fetch an identity assertion"}, {"refs": [{"id": "ref-for-idp\u2461\u2464"}, {"id": "ref-for-idp\u2461\u2465"}, {"id": "ref-for-idp\u2461\u2466"}, {"id": "ref-for-idp\u2461\u2467"}, {"id": "ref-for-idp\u2461\u2468"}, {"id": "ref-for-idp\u2462\u24ea"}], "title": "2.4. The IdentityProvider Interface"}, {"refs": [{"id": "ref-for-idp\u2462\u2460"}, {"id": "ref-for-idp\u2462\u2461"}], "title": "3. Identity Provider HTTP API"}, {"refs": [{"id": "ref-for-idp\u2462\u2462"}, {"id": "ref-for-idp\u2462\u2463"}], "title": "3.1. The Well-Known File"}, {"refs": [{"id": "ref-for-idp\u2462\u2464"}, {"id": "ref-for-idp\u2462\u2465"}, {"id": "ref-for-idp\u2462\u2466"}, {"id": "ref-for-idp\u2462\u2467"}, {"id": "ref-for-idp\u2462\u2468"}], "title": "3.2. The config file"}, {"refs": [{"id": "ref-for-idp\u2463\u24ea"}, {"id": "ref-for-idp\u2463\u2460"}, {"id": "ref-for-idp\u2463\u2461"}], "title": "3.3. Accounts endpoint"}, {"refs": [{"id": "ref-for-idp\u2463\u2462"}, {"id": "ref-for-idp\u2463\u2463"}, {"id": "ref-for-idp\u2463\u2464"}, {"id": "ref-for-idp\u2463\u2465"}, {"id": "ref-for-idp\u2463\u2466"}, {"id": "ref-for-idp\u2463\u2467"}, {"id": "ref-for-idp\u2463\u2468"}, {"id": "ref-for-idp\u2464\u24ea"}, {"id": "ref-for-idp\u2464\u2460"}, {"id": "ref-for-idp\u2464\u2461"}, {"id": "ref-for-idp\u2464\u2462"}, {"id": "ref-for-idp\u2464\u2463"}], "title": "3.5. Identity assertion endpoint"}, {"refs": [{"id": "ref-for-idp\u2464\u2464"}, {"id": "ref-for-idp\u2464\u2465"}, {"id": "ref-for-idp\u2464\u2466"}, {"id": "ref-for-idp\u2464\u2467"}, {"id": "ref-for-idp\u2464\u2468"}, {"id": "ref-for-idp\u2465\u24ea"}, {"id": "ref-for-idp\u2465\u2460"}, {"id": "ref-for-idp\u2465\u2461"}, {"id": "ref-for-idp\u2465\u2462"}], "title": "3.6. Disconnect endpoint"}, {"refs": [{"id": "ref-for-idp\u2465\u2463"}, {"id": "ref-for-idp\u2465\u2464"}, {"id": "ref-for-idp\u2465\u2465"}, {"id": "ref-for-idp\u2465\u2466"}], "title": "6.1. Content Security Policy"}, {"refs": [{"id": "ref-for-idp\u2465\u2467"}, {"id": "ref-for-idp\u2465\u2468"}, {"id": "ref-for-idp\u2466\u24ea"}, {"id": "ref-for-idp\u2466\u2460"}], "title": "6.2. Sec-Fetch-Dest Header"}, {"refs": [{"id": "ref-for-idp\u2466\u2461"}], "title": "6.3. Browser Surface Impersonation"}, {"refs": [{"id": "ref-for-idp\u2466\u2462"}, {"id": "ref-for-idp\u2466\u2463"}, {"id": "ref-for-idp\u2466\u2464"}, {"id": "ref-for-idp\u2466\u2465"}, {"id": "ref-for-idp\u2466\u2466"}, {"id": "ref-for-idp\u2466\u2467"}, {"id": "ref-for-idp\u2466\u2468"}, {"id": "ref-for-idp\u2467\u24ea"}, {"id": "ref-for-idp\u2467\u2460"}, {"id": "ref-for-idp\u2467\u2461"}, {"id": "ref-for-idp\u2467\u2462"}, {"id": "ref-for-idp\u2467\u2463"}, {"id": "ref-for-idp\u2467\u2464"}, {"id": "ref-for-idp\u2467\u2465"}], "title": "7.1. Principals"}, {"refs": [{"id": "ref-for-idp\u2467\u2466"}, {"id": "ref-for-idp\u2467\u2467"}, {"id": "ref-for-idp\u2467\u2468"}, {"id": "ref-for-idp\u2468\u24ea"}, {"id": "ref-for-idp\u2468\u2460"}, {"id": "ref-for-idp\u2468\u2461"}, {"id": "ref-for-idp\u2468\u2462"}, {"id": "ref-for-idp\u2468\u2463"}, {"id": "ref-for-idp\u2468\u2464"}, {"id": "ref-for-idp\u2468\u2465"}, {"id": "ref-for-idp\u2468\u2466"}, {"id": "ref-for-idp\u2468\u2467"}], "title": "7.2. Network requests"}, {"refs": [{"id": "ref-for-idp\u2468\u2468"}, {"id": "ref-for-idp\u2460\u24ea\u24ea"}, {"id": "ref-for-idp\u2460\u24ea\u2460"}, {"id": "ref-for-idp\u2460\u24ea\u2461"}], "title": "7.3. Attack Scenarios"}, {"refs": [{"id": "ref-for-idp\u2460\u24ea\u2462"}, {"id": "ref-for-idp\u2460\u24ea\u2463"}, {"id": "ref-for-idp\u2460\u24ea\u2464"}, {"id": "ref-for-idp\u2460\u24ea\u2465"}, {"id": "ref-for-idp\u2460\u24ea\u2466"}], "title": "7.3.1. Manifest Fingerprinting"}, {"refs": [{"id": "ref-for-idp\u2460\u24ea\u2467"}, {"id": "ref-for-idp\u2460\u24ea\u2468"}, {"id": "ref-for-idp\u2460\u2460\u24ea"}, {"id": "ref-for-idp\u2460\u2460\u2460"}, {"id": "ref-for-idp\u2460\u2460\u2461"}, {"id": "ref-for-idp\u2460\u2460\u2462"}, {"id": "ref-for-idp\u2460\u2460\u2463"}, {"id": "ref-for-idp\u2460\u2460\u2464"}], "title": "7.3.2. Timing Attacks"}, {"refs": [{"id": "ref-for-idp\u2460\u2460\u2465"}, {"id": "ref-for-idp\u2460\u2460\u2466"}], "title": "7.3.3. IDP Intrusion"}, {"refs": [{"id": "ref-for-idp\u2460\u2460\u2467"}, {"id": "ref-for-idp\u2460\u2460\u2468"}, {"id": "ref-for-idp\u2460\u2461\u24ea"}], "title": "7.3.4. Cross-Site Correlation"}, {"refs": [{"id": "ref-for-idp\u2460\u2461\u2460"}, {"id": "ref-for-idp\u2460\u2461\u2461"}], "title": "7.3.5. Unauthorized Data Usage"}, {"refs": [{"id": "ref-for-idp\u2460\u2461\u2462"}, {"id": "ref-for-idp\u2460\u2461\u2463"}, {"id": "ref-for-idp\u2460\u2461\u2464"}, {"id": "ref-for-idp\u2460\u2461\u2465"}, {"id": "ref-for-idp\u2460\u2461\u2466"}, {"id": "ref-for-idp\u2460\u2461\u2467"}, {"id": "ref-for-idp\u2460\u2461\u2468"}, {"id": "ref-for-idp\u2460\u2462\u24ea"}, {"id": "ref-for-idp\u2460\u2462\u2460"}, {"id": "ref-for-idp\u2460\u2462\u2461"}, {"id": "ref-for-idp\u2460\u2462\u2462"}, {"id": "ref-for-idp\u2460\u2462\u2463"}, {"id": "ref-for-idp\u2460\u2462\u2464"}], "title": "7.3.7. Secondary Use"}], "external": false};
+window.dfnpanelData['idp'] = {"dfnID": "idp", "url": "#idp", "dfnText": "IDP", "refSections": [{"refs": [{"id": "ref-for-idp"}, {"id": "ref-for-idp\u2460"}, {"id": "ref-for-idp\u2461"}, {"id": "ref-for-idp\u2462"}], "title": "1. Introduction"}, {"refs": [{"id": "ref-for-idp\u2463"}, {"id": "ref-for-idp\u2464"}, {"id": "ref-for-idp\u2465"}], "title": "2. The Browser API"}, {"refs": [{"id": "ref-for-idp\u2466"}], "title": "2.1.1. Login Status Map"}, {"refs": [{"id": "ref-for-idp\u2467"}], "title": "2.1.2. HTTP header API"}, {"refs": [{"id": "ref-for-idp\u2468"}], "title": "2.1.3. JavaScript API"}, {"refs": [{"id": "ref-for-idp\u2460\u24ea"}, {"id": "ref-for-idp\u2460\u2460"}], "title": "2.1.4. Clearing the Login Status Map data"}, {"refs": [{"id": "ref-for-idp\u2460\u2461"}], "title": "2.2. The connected accounts set"}, {"refs": [{"id": "ref-for-idp\u2460\u2462"}], "title": "2.3. The IdentityCredential Interface"}, {"refs": [{"id": "ref-for-idp\u2460\u2463"}, {"id": "ref-for-idp\u2460\u2464"}, {"id": "ref-for-idp\u2460\u2465"}], "title": "2.3.2. The CredentialRequestOptions"}, {"refs": [{"id": "ref-for-idp\u2460\u2466"}], "title": "2.3.3. The [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) internal method"}, {"refs": [{"id": "ref-for-idp\u2460\u2467"}], "title": "2.3.4. Create an IdentityCredential"}, {"refs": [{"id": "ref-for-idp\u2460\u2468"}, {"id": "ref-for-idp\u2461\u24ea"}, {"id": "ref-for-idp\u2461\u2460"}, {"id": "ref-for-idp\u2461\u2461"}], "title": "2.3.5. Fetch the config file"}, {"refs": [{"id": "ref-for-idp\u2461\u2462"}], "title": "2.3.6. Fetch the accounts"}, {"refs": [{"id": "ref-for-idp\u2461\u2463"}], "title": "2.3.7. Fetch an identity assertion"}, {"refs": [{"id": "ref-for-idp\u2461\u2464"}, {"id": "ref-for-idp\u2461\u2465"}, {"id": "ref-for-idp\u2461\u2466"}, {"id": "ref-for-idp\u2461\u2467"}, {"id": "ref-for-idp\u2461\u2468"}, {"id": "ref-for-idp\u2462\u24ea"}], "title": "2.4. The IdentityProvider Interface"}, {"refs": [{"id": "ref-for-idp\u2462\u2460"}, {"id": "ref-for-idp\u2462\u2461"}], "title": "3. Identity Provider HTTP API"}, {"refs": [{"id": "ref-for-idp\u2462\u2462"}, {"id": "ref-for-idp\u2462\u2463"}], "title": "3.1. The Well-Known File"}, {"refs": [{"id": "ref-for-idp\u2462\u2464"}, {"id": "ref-for-idp\u2462\u2465"}, {"id": "ref-for-idp\u2462\u2466"}, {"id": "ref-for-idp\u2462\u2467"}, {"id": "ref-for-idp\u2462\u2468"}], "title": "3.2. The config file"}, {"refs": [{"id": "ref-for-idp\u2463\u24ea"}, {"id": "ref-for-idp\u2463\u2460"}, {"id": "ref-for-idp\u2463\u2461"}], "title": "3.3. Accounts endpoint"}, {"refs": [{"id": "ref-for-idp\u2463\u2462"}, {"id": "ref-for-idp\u2463\u2463"}, {"id": "ref-for-idp\u2463\u2464"}, {"id": "ref-for-idp\u2463\u2465"}, {"id": "ref-for-idp\u2463\u2466"}, {"id": "ref-for-idp\u2463\u2467"}, {"id": "ref-for-idp\u2463\u2468"}, {"id": "ref-for-idp\u2464\u24ea"}, {"id": "ref-for-idp\u2464\u2460"}, {"id": "ref-for-idp\u2464\u2461"}, {"id": "ref-for-idp\u2464\u2462"}], "title": "3.5. Identity assertion endpoint"}, {"refs": [{"id": "ref-for-idp\u2464\u2463"}, {"id": "ref-for-idp\u2464\u2464"}, {"id": "ref-for-idp\u2464\u2465"}, {"id": "ref-for-idp\u2464\u2466"}, {"id": "ref-for-idp\u2464\u2467"}, {"id": "ref-for-idp\u2464\u2468"}, {"id": "ref-for-idp\u2465\u24ea"}, {"id": "ref-for-idp\u2465\u2460"}, {"id": "ref-for-idp\u2465\u2461"}], "title": "3.6. Disconnect endpoint"}, {"refs": [{"id": "ref-for-idp\u2465\u2462"}, {"id": "ref-for-idp\u2465\u2463"}, {"id": "ref-for-idp\u2465\u2464"}, {"id": "ref-for-idp\u2465\u2465"}], "title": "6.1. Content Security Policy"}, {"refs": [{"id": "ref-for-idp\u2465\u2466"}, {"id": "ref-for-idp\u2465\u2467"}, {"id": "ref-for-idp\u2465\u2468"}, {"id": "ref-for-idp\u2466\u24ea"}], "title": "6.2. Sec-Fetch-Dest Header"}, {"refs": [{"id": "ref-for-idp\u2466\u2460"}], "title": "6.3. Browser Surface Impersonation"}, {"refs": [{"id": "ref-for-idp\u2466\u2461"}, {"id": "ref-for-idp\u2466\u2462"}, {"id": "ref-for-idp\u2466\u2463"}, {"id": "ref-for-idp\u2466\u2464"}, {"id": "ref-for-idp\u2466\u2465"}, {"id": "ref-for-idp\u2466\u2466"}, {"id": "ref-for-idp\u2466\u2467"}, {"id": "ref-for-idp\u2466\u2468"}, {"id": "ref-for-idp\u2467\u24ea"}, {"id": "ref-for-idp\u2467\u2460"}, {"id": "ref-for-idp\u2467\u2461"}, {"id": "ref-for-idp\u2467\u2462"}, {"id": "ref-for-idp\u2467\u2463"}, {"id": "ref-for-idp\u2467\u2464"}], "title": "7.1. Principals"}, {"refs": [{"id": "ref-for-idp\u2467\u2465"}, {"id": "ref-for-idp\u2467\u2466"}, {"id": "ref-for-idp\u2467\u2467"}, {"id": "ref-for-idp\u2467\u2468"}, {"id": "ref-for-idp\u2468\u24ea"}, {"id": "ref-for-idp\u2468\u2460"}, {"id": "ref-for-idp\u2468\u2461"}, {"id": "ref-for-idp\u2468\u2462"}, {"id": "ref-for-idp\u2468\u2463"}, {"id": "ref-for-idp\u2468\u2464"}, {"id": "ref-for-idp\u2468\u2465"}, {"id": "ref-for-idp\u2468\u2466"}], "title": "7.2. Network requests"}, {"refs": [{"id": "ref-for-idp\u2468\u2467"}, {"id": "ref-for-idp\u2468\u2468"}, {"id": "ref-for-idp\u2460\u24ea\u24ea"}, {"id": "ref-for-idp\u2460\u24ea\u2460"}], "title": "7.3. Attack Scenarios"}, {"refs": [{"id": "ref-for-idp\u2460\u24ea\u2461"}, {"id": "ref-for-idp\u2460\u24ea\u2462"}, {"id": "ref-for-idp\u2460\u24ea\u2463"}, {"id": "ref-for-idp\u2460\u24ea\u2464"}, {"id": "ref-for-idp\u2460\u24ea\u2465"}], "title": "7.3.1. Manifest Fingerprinting"}, {"refs": [{"id": "ref-for-idp\u2460\u24ea\u2466"}, {"id": "ref-for-idp\u2460\u24ea\u2467"}, {"id": "ref-for-idp\u2460\u24ea\u2468"}, {"id": "ref-for-idp\u2460\u2460\u24ea"}, {"id": "ref-for-idp\u2460\u2460\u2460"}, {"id": "ref-for-idp\u2460\u2460\u2461"}, {"id": "ref-for-idp\u2460\u2460\u2462"}, {"id": "ref-for-idp\u2460\u2460\u2463"}], "title": "7.3.2. Timing Attacks"}, {"refs": [{"id": "ref-for-idp\u2460\u2460\u2464"}, {"id": "ref-for-idp\u2460\u2460\u2465"}], "title": "7.3.3. IDP Intrusion"}, {"refs": [{"id": "ref-for-idp\u2460\u2460\u2466"}, {"id": "ref-for-idp\u2460\u2460\u2467"}, {"id": "ref-for-idp\u2460\u2460\u2468"}], "title": "7.3.4. Cross-Site Correlation"}, {"refs": [{"id": "ref-for-idp\u2460\u2461\u24ea"}, {"id": "ref-for-idp\u2460\u2461\u2460"}], "title": "7.3.5. Unauthorized Data Usage"}, {"refs": [{"id": "ref-for-idp\u2460\u2461\u2461"}, {"id": "ref-for-idp\u2460\u2461\u2462"}, {"id": "ref-for-idp\u2460\u2461\u2463"}, {"id": "ref-for-idp\u2460\u2461\u2464"}, {"id": "ref-for-idp\u2460\u2461\u2465"}, {"id": "ref-for-idp\u2460\u2461\u2466"}, {"id": "ref-for-idp\u2460\u2461\u2467"}, {"id": "ref-for-idp\u2460\u2461\u2468"}, {"id": "ref-for-idp\u2460\u2462\u24ea"}, {"id": "ref-for-idp\u2460\u2462\u2460"}, {"id": "ref-for-idp\u2460\u2462\u2461"}, {"id": "ref-for-idp\u2460\u2462\u2462"}, {"id": "ref-for-idp\u2460\u2462\u2463"}], "title": "7.3.7. Secondary Use"}], "external": false};
 window.dfnpanelData['login-status-map'] = {"dfnID": "login-status-map", "url": "#login-status-map", "dfnText": "Login Status\nmap", "refSections": [{"refs": [{"id": "ref-for-login-status-map"}, {"id": "ref-for-login-status-map\u2460"}], "title": "2.1.1. Login Status Map"}, {"refs": [{"id": "ref-for-login-status-map\u2461"}, {"id": "ref-for-login-status-map\u2462"}], "title": "2.1.4. Clearing the Login Status Map data"}], "external": false};
 window.dfnpanelData['unknown'] = {"dfnID": "unknown", "url": "#unknown", "dfnText": "unknown", "refSections": [{"refs": [{"id": "ref-for-unknown"}], "title": "2.1.1. Login Status Map"}, {"refs": [{"id": "ref-for-unknown\u2460"}], "title": "2.1.4. Clearing the Login Status Map data"}, {"refs": [{"id": "ref-for-unknown\u2461"}, {"id": "ref-for-unknown\u2462"}], "title": "2.3.4. Create an IdentityCredential"}], "external": false};
 window.dfnpanelData['logged-in'] = {"dfnID": "logged-in", "url": "#logged-in", "dfnText": "logged-in", "refSections": [{"refs": [{"id": "ref-for-logged-in"}], "title": "2.1.1. Login Status Map"}, {"refs": [{"id": "ref-for-logged-in\u2460"}], "title": "2.1.2. HTTP header API"}, {"refs": [{"id": "ref-for-logged-in\u2461"}], "title": "2.1.3. JavaScript API"}, {"refs": [{"id": "ref-for-logged-in\u2462"}, {"id": "ref-for-logged-in\u2463"}], "title": "2.3.4. Create an IdentityCredential"}, {"refs": [{"id": "ref-for-logged-in\u2464"}], "title": "2.3.9. Helper algorithms"}], "external": false};