diff --git a/index.html b/index.html index 6d3d0ac37..024192c54 100644 --- a/index.html +++ b/index.html @@ -1,12 +1,12 @@ - Federated Credential Management API - + Federated Credential Management API + - - + + - +

Federated Credential Management API

-

Draft Community Group Report,

-
-
-
This version: -
https://fedidcg.github.io/FedCM/ -
Test Suite: -
https://github.com/web-platform-tests/wpt/blob/master/credential-management/ -
Issue Tracking: -
GitHub -
Inline In Spec -
Editor: -
(Google Inc.) -
Former Editor: -
(Google Inc.) -
-
+

Editor’s Draft,

+
+ More details about this document +
+
+
This version: +
https://w3c-fedid.github.io/FedCM/ +
Latest published version: +
https://www.w3.org/TR/fedcm/ +
Test Suite: +
https://github.com/web-platform-tests/wpt/tree/master/fedcm +
Feedback: +
GitHub +
Inline In Spec +
Editor: +
(Google Inc.) +
Former Editor: +
(Google Inc.) +
+
+
-

Copyright © 2024 the Contributors to the Federated Credential Management API Specification, published by the Federated Identity Community Group under the W3C Community Contributor License Agreement (CLA). -A human-readable summary is available.

+

Copyright © 2024 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.

Abstract

A Web Platform API that allows users to login to websites with their federated accounts in a privacy preserving manner.

-
-

Status of this document

+

Status of this document

-

This specification was published by the Federated Identity Community Group. - It is not a W3C Standard nor is it on the W3C Standards Track. - - Please note that under the W3C Community Contributor License Agreement (CLA) there is a limited opt-out and other conditions apply. - - Learn more about W3C Community and Business Groups.

+

This is a public copy of the editors’ draft. + It is provided for discussion only and may change at any moment. + Its publication here does not imply endorsement of its contents by W3C. + Don’t cite this document other than as work in progress.

+

Changes to this document may be tracked at https://github.com/w3c-fedid/.

+

The (archived) public mailing list public-fedid-wg@w3.org (see instructions) + is preferred for discussion of this specification. + When sending e-mail, + please put the text “fedcm” in the subject, + preferably like this: + “[fedcm] …summary of comment…”

+

This document was produced by the Federated Identity Working Group.

+

This document was produced by a group operating under + the W3C Patent Policy. + W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; + that page also includes instructions for disclosing a patent. + An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

+

This document is governed by the 03 November 2023 W3C Process Document.

@@ -965,9 +761,10 @@

Table of Contents

2.1 The Login Status API
  1. 2.1.1 Login Status Map -
  2. 2.1.2 HTTP header API -
  3. 2.1.3 JavaScript API -
  4. 2.1.4 Clearing the Login Status Map data +
  5. 2.1.2 Infrastructure algorithm +
  6. 2.1.3 HTTP header API +
  7. 2.1.4 JavaScript API +
  8. 2.1.5 Clearing the Login Status Map data
  • 2.2 The connected accounts set
  • @@ -1018,7 +815,8 @@

    Table of Contents

    1. 6.1 Content Security Policy
    2. 6.2 Sec-Fetch-Dest Header -
    3. 6.3 Browser Surface Impersonation +
    4. 6.3 CORS Header +
    5. 6.4 Browser Surface Impersonation
  • 7 Privacy @@ -1039,10 +837,12 @@

    Table of Contents

  • 8 Extensibility
  • 9 Acknowledgements +
  • 10 FPWD Issues
  • Conformance
    1. Document conventions +
    2. Conformant Algorithms
  • Index @@ -1061,10 +861,10 @@

    Table of Contents

    - - - - + + + +

    1. Introduction

    This section is non-normative.

    As the web has evolved there have been ongoing privacy-oriented changes @@ -1291,7 +1091,35 @@

    Set Login Status map[origin] to value.

    -

    2.1.2. HTTP header API

    +

    2.1.2. Infrastructure algorithm

    +
    + An environment settings object (settings) is same-site with its + ancestors if the following algorithm returns true: +
      +
    1. +

      If settings’s relevant global object has no associated Document, +return false.

      +
    2. +

      Let document be settings’ relevant global object's associated Document.

      +
    3. +

      If document has no browsing context, return false.

      +
    4. +

      Let origin be settings’ origin.

      +
    5. +

      Let navigable be document’s node navigable.

      +
    6. +

      While navigable has a non-null parent:

      +
        +
      1. +

        Set navigable to navigable’s parent.

        +
      2. +

        If navigable’s active document's origin is not same site with origin, return false.

        +
      +
    7. +

      Return true.

      +
    +
    +

    2.1.3. HTTP header API

    IDPs can set the login status using an HTTP response header as follows.

    The HTTP header checking should move into the Fetch spec, since it affects all resource loads.

    @@ -1310,9 +1138,9 @@

    If client is null, return.

  • -

    If origin is not same origin with the request's origin, return.

    +

    If origin is not same site with the request's origin, return.

  • -

    If client is not same-origin with its ancestors, return.

    +

    If client is not same-site with its ancestors, return.

  • Assert that value is a tuple.

    @@ -1324,7 +1152,7 @@

    If token is "logged-out", set the login status for origin to logged-out.

    -

    2.1.3. JavaScript API

    +

    2.1.4. JavaScript API

    IDPs can also use a JavaScript API to update the stored login status:

    enum LoginStatus {
   "logged-in",
@@ -1344,17 +1172,17 @@ 
    setStatus() is called with argument status: 
     
      
      
    1. 
-      
      If the current settings object is not same-origin with its ancestors,
+      
      If the current settings object is not same-site with its ancestors,
 throw a SecurityError DOMException.
      
      
    2. 
-      
      Let origin be the current settings object's origin.
      
+      
      Let origin be the current settings object's origin.
      
      
    3. 
       
      Let value be logged-in if status is "logged-in" or logged-out if status is "logged-out".
      
      
    4. 
       
      Set the login status for origin to value.
      
     
    
    
-   
    2.1.4. Clearing the Login Status Map data
    
+   
    2.1.5. Clearing the Login Status Map data
    
    
    User agents MUST also clear the Login Status map data when:
    
    
    
     
    the user clears all cookies or site settings data
@@ -1376,7 +1204,7 @@ 
    
     
    the user agent receives a Clear-Site-Data header with a
 value of "cookies" or "*", and the request's client is
-not null, and the client’s origin is same
+not null, and the client’s origin is same
 origin with the top-level origin
     
    
      
    while clearing cookies for
@@ -1396,42 +1224,68 @@ 
    
    
    If a user clears browsing data for an origin (cookies, localStorage, etc.), the user agent MUST remove all triples with an origin matching the origin from connected accounts set.
    
-   
    
-     To compute the connection status given an IdentityProviderConfig provider, an IdentityProviderAccount account, and a globalObject, run the following steps. This returns connected or disconnected. 
+   
    
+     To compute the connected account key given an IdentityProviderConfig provider, an IdentityProviderAccount account, and a globalObject, run the following steps. It returns a
+triple of the form (rp, idp, account). 
     
      
-     
    1. 
-      
      If account contains approved_clients and account’s approved_clients does not contain provider’s clientId, return disconnected.
      
      
    2. 
       
      Let configUrl be the result of running parse url with provider’s configURL and globalObject.
      
      
    3. 
       
      Let idpOrigin be the origin corresponding to configUrl.
      
      
    4. 
-      
      Let rpOrigin be globalObject’s associated Document's origin.
      
+      
      Let rpOrigin be globalObject’s associated Document's origin.
      
      
    5. 
       
      Let accountId be account’s id.
      
      
    6. 
-      
      Let triple be (rpOrigin, idpOrigin, accountId).
      
+      
      Return (rpOrigin, idpOrigin, accountId).
      
+    
    
+   
    
+   
    
+     When asked whether an IdentityProviderAccount account is eligible for auto reauthentication given an IdentityProviderConfig provider and a globalObject, run the following steps. This returns a boolean. 
+    
      
+     
    1. 
+      
      If account contains approved_clients and account’s approved_clients does not contain provider’s clientId, return false.
      
+     
    2. 
+      
      Let triple be the result of running compute the connected account key given provider, account, and globalObject.
      
+     
    3. 
+      
      Return whether connected accounts set contains triple.
      
+    
    
+   
    
+   
    
+     When asked to compute the connection status given an IdentityProviderAccount account, an IdentityProviderConfig provider and a globalObject, run the following steps.
+This returns connected or disconnected. 
+    
      
+     
    1. 
+      
      If account contains approved_clients:
      
+      
        
+       
      1. 
+        
        If account’s approved_clients containsprovider’s clientId, return connected.
        
+       
      2. 
+        
        Return disconnected.
        
+      
      
      
    2. 
-      
      If connected accounts set contains triple , return connected.
      
+      
      Let triple be the result of running compute the connected account key given provider, account, and globalObject.
      
      
    3. 
-      
      Otherwise, return disconnected.
      
+      
      If connected accounts set contains triple, return connected.
      
+     
    4. 
+      
      Return disconnected.
      
     
    
    
    
    
    
-     To create a connection between the RP and the IdP account given an IdentityProviderConfig provider, an IdentityProviderAccount account, and a globalObject (the RP's), run the following steps: 
+     To create a connection between the RP and the IdP account given an IdentityProviderConfig provider, an IdentityProviderAccount account, and a globalObject (the RP's), run the following steps: 
     
      
      
    1. 
       
      Let configUrl be the result of running parse url with provider’s configURL and globalObject.
      
      
    2. 
       
      Let idpOrigin be the origin corresponding to configUrl.
      
      
    3. 
-      
      Let rpOrigin be globalObject’s associated Document's origin.
      
+      
      Let rpOrigin be globalObject’s associated Document's origin.
      
      
    4. 
       
      Let accountId be account’s id.
      
      
    5. 
       
      Let triple be (rpOrigin, idpOrigin, accountId).
      
      
    6. 
-      
      Append triple to connected accounts set.
      
+      
      Append triple to connected accounts set.
      
     
    
    
    
    
    
@@ -1441,10 +1295,10 @@ 
    
       
    Let triple be (rpOrigin, idpOrigin, accountId).
    
      
  • 
-      
    If connected accounts set contains triple:
    
+      
    If connected accounts set contains triple:
    
       
      
        
    1. 
-        
      Remove triple from the connected accounts set.
      
+        
      Remove triple from the connected accounts set.
      
        
    2. 
         
      Return true.
      
       
    
@@ -1456,16 +1310,16 @@ 
    remove all connections: given rpOrigin and idpOrigin, run the following steps: 
     
      
      
    1. 
-      
      For every (rp, idp, accountId) triple in the connected accounts set:
      
+      
      For every (rp, idp, accountId) triple in the connected accounts set:
      
       
        
        
      1. 
-        
        If rp equals rpOrigin and idp equals idpOrigin, remove triple from the connected accounts set.
        
+        
        If rp equals rpOrigin and idp equals idpOrigin, remove triple from the connected accounts set.
        
       
      
     
    
    
    • 
    
    2.3. The IdentityCredential Interface
    
    
    This specification introduces a new type of Credential, called an IdentityCredential:
    
-
    dictionary IdentityCredentialDisconnectOptions : IdentityProviderConfig {
+
    dictionary IdentityCredentialDisconnectOptions : IdentityProviderConfig {
   required USVString accountHint;
 };
 
@@ -1505,7 +1359,7 @@ 
    current global object.
    
      
  • 
-      
    Let document be globalObject’s associated Document.
    
+      
    Let document be globalObject’s associated Document.
    
      
  • 
       
    If document is not allowed to use the identity-credentials-get policy-controlled feature, throw a "NotAllowedError" DOMException.
    
      
  • 
@@ -1538,8 +1392,7 @@ 
    reject promise with a
 "NetworkError" DOMException.
    
      
  • 
-      
    If there does not exist an account account such that compute the connection status of options, account, and globalObject returns connected, then reject promise with a
-"NetworkError" DOMException. This check can be performed by iterating over the connected accounts set or by keeping a separate data structure to make this lookup fast.
    
+      
    If there does not exist an account account such that connected accounts set contains the result of compute the connected account key given account, options, and globalObject, then reject promise with a "NetworkError" DOMException. This check can be performed by iterating over the connected accounts set or by keeping a separate data structure to make this lookup fast.
    
      
  • 
       
    Let config be the result of running fetch the config file with provider and globalObject.
    
      
  • 
@@ -1553,7 +1406,7 @@ 
    origin corresponding to configUrl.
    
      
  • 
-      
    Let rpOrigin be globalObject’s associated Document's origin.
    
+      
    Let rpOrigin be globalObject’s associated Document's origin.
    
      
  • 
       
    If result is failure:
    
       
      
@@ -1585,7 +1438,7 @@ 
      Let requestBody be the result of running urlencoded serializer with a list containing:
      
       
        
        
      1. 
-        
        ("client_id", options’s clientId)
        
+        
        ("client_id", options’s clientId)
        
        
      2. 
         
        ("account_hint", options’s accountHint)
        
       
      
@@ -1618,7 +1471,7 @@ 
      "webidentity"
      
        
      origin
        
      
-        
      globalObject’s associated document's origin
      
+        
      globalObject’s associated document's origin
      
        
      header list
        
      
         
      a list containing a single header with name set to Accept and value set to application/x-www-form-urlencoded
      
@@ -1674,7 +1527,7 @@ 
      IdentityCredentialRequestOptions identity;
 };
 
    • 
-   
    The IdentityCredentialRequestOptions contains a list of IdentityProviderConfigs that the RP supports and has
+   
    The IdentityCredentialRequestOptions contains a list of IdentityProviderConfigs that the RP supports and has
 pre-registered with (i.e. the IDP has given the RP a clientId).
 The IdentityCredentialRequestOptions also contains a IdentityCredentialRequestOptionsContext which the user agent can use to provide a more meaningful dialog to users.
    
 
    enum IdentityCredentialRequestOptionsContext {
@@ -1689,14 +1542,14 @@ 
    IdentityCredentialRequestOptionsContext context = "signin";
 };
 
    
-   
    Each IdentityProviderConfig represents an IDP that
+   
    Each IdentityProviderConfig represents an IDP that
 the RP supports (e.g. that it has a pre-registration agreement with).
    
 
    dictionary IdentityProviderConfig {
   required USVString configURL;
   required USVString clientId;
 };
 
-dictionary IdentityProviderRequestOptions : IdentityProviderConfig {
+dictionary IdentityProviderRequestOptions : IdentityProviderConfig {
   USVString nonce;
   DOMString loginHint;
   DOMString domainHint;
@@ -1706,7 +1559,7 @@ 
    configURL
     
    
      
    The URL of the configuration file for the identity provider.
    
-    
    clientId
+    
    clientId
     
    
      
    The client_id provided to the RP out of band by the IDP
    
     
    nonce
@@ -1718,7 +1571,7 @@ 
    IdentityProviderAccount.
    
+match this login hint value. It generally matches some attribute from the desired IdentityProviderAccount.
    
     
    domainHint
     
    
      
    A string representing the domain hint corresponding to a domain which the RP is
@@ -1733,15 +1586,15 @@ 
    
     
    origin
     
    
-     
    This argument is the relevant settings object's origin, as determined by the
+     
    This argument is the relevant settings object's origin, as determined by the
  calling get() implementation, i.e., CredentialsContainer's Request a Credential abstract operation.
    
     
    options
     
    
-     
    This argument is a CredentialRequestOptions object whose identity member exists.
    
+     
    This argument is a CredentialRequestOptions object whose identity member exists.
    
     
    sameOriginWithAncestors
     
    
      
    This argument is a Boolean value which is true if and only if the
- caller’s environment settings object is same-origin with its ancestors. It is false if caller is cross-origin.
    
+ caller’s environment settings object is same-origin with its ancestors. It is false if caller is cross-origin.
    
      
    Note: Invocation of this internal method indicates that it was allowed by permissions policy, which is evaluated at the Credential Management Level 1 level.
 See § 4 Permissions Policy Integration. As such, sameOriginWithAncestors is unused.
    
    
    
@@ -1906,7 +1759,7 @@ 
    <
       
    If provider’s loginHint is not empty:
    
       
      
        
    1. 
-        
      For every account in accountList, remove account from accountList if account’s login_hints does not contain provider’s loginHint.
      
+        
      For every account in accountList, remove account from accountList if account’s login_hints does not contain provider’s loginHint.
      
        
    2. 
         
      If accountList is now empty, go to the mismatch dialog step.
      
       
    
@@ -1923,7 +1776,7 @@ 
    <
             
    If account’s domain_hints is empty, remove account from accountList.
    
           
          
  • 
-          
    Otherwise, remove account from accountList if account’s domain_hints does not contain provider’s domainHint.
    
+          
    Otherwise, remove account from accountList if account’s domain_hints does not contain provider’s domainHint.
    
         
        
  • 
         
    If accountList is now empty, go to the mismatch dialog step.
    
@@ -1945,9 +1798,8 @@ 
    <
       
    For each acc in accountsList:
    
       
      
        
    1. 
-        
      Let accState be the result of running the compute the connection status algorithm given provider and acc.
      
-       
    2. 
-        
      If accState is connected, set registeredAccount to acc and increase numRegisteredAccounts by 1.
      
+        
      If acc is eligible for auto reauthentication given provider, and globalObject,
+set registeredAccount to acc and increase numRegisteredAccounts by 1.
      
       
    
      
  • 
       
    Let permission, disclosureTextShown, and isAutoSelected be set to false.
    
@@ -1955,8 +1807,8 @@ 
    <
       
    If mediation is not "required", requiresUserMediation is false, and numRegisteredAccounts is equal to 1:
    
       
      
        
    1. 
-        
      Set account to registeredAccount and accountState to the result of running compute the connection status algorithm given provider and account. When doing this,
-the user agent MAY show some UI to the user indicating that they are being auto-reauthenticated.
      
+        
      Set account to registeredAccount and permission to true. When doing this, the user
+agent MAY show some UI to the user indicating that they are being auto-reauthenticated.
      
        
    2. 
         
      Set isAutoSelected to true.
      
       
    
@@ -1968,15 +1820,10 @@ 
    <
        
  • 
         
    Set account to accountsList[0].
    
        
  • 
-        
    Set accountState to the result of running the compute the connection status algorithm
-given provider, account, and globalObject.
    
+        
    If compute the connection status of account, provider and globalObject returns connected, show a dialog to request user permission to sign
+in via account, and set the result in permission. The user agent MAY use options’s context to customize the dialog.
    
        
  • 
-        
    If accountState is disconnected,
-let permission be the result of running request permission to sign-up algorithm
-with account, accountState, config, provider, and globalObject. Also set disclosureTextShown to true.
    
-       
  • 
-        
    Otherwise, show a dialog to request user permission to sign in via account, and set the
-result in permission. The user agent MAY use options’s context to customize the dialog.
    
+        
    Otherwise, let permission be the result of running request permission to sign-up algorithm with account, config, provider, and globalObject. Also set disclosureTextShown to true.
    
       
      
  • 
       
    Otherwise:
    
@@ -1986,18 +1833,15 @@ 
    <
        
  • 
         
    If account is failure, return (failure, true).
    
        
  • 
-        
    Set accountState to the result of running the compute the connection status algorithm
-given provider and account.
    
+        
    If compute the connection status of account, provider and globalObject is connected, set permission to true.
    
        
  • 
-        
    If accountState is disconnected:
    
+        
    Otherwise:
    
         
      
          
    1. 
           
      Let permission be the result of running the request permission to sign-up algorithm with account, config, provider, and globalObject.
      
          
    2. 
           
      Set disclosureTextShown to true.
      
         
    
-       
  • 
-        
    Otherwise, set permission to true.
    
       
      
  • 
       
    Wait until the user agent's dialogs requesting for user choice or permission to be
@@ -2038,7 +1882,7 @@ 
    
       
    Let config, configInWellKnown both be null.
    
      
  • 
-      
    Let rpOrigin be globalObject’s associated Document's origin.
    
+      
    Let rpOrigin be globalObject’s associated Document's origin.
    
      
  • 
       
    If rpOrigin is not an opaque origin, and rootUrl’s host is equal
 to rpOrigin’s registrable domain, and rootUrl’s scheme is
@@ -2270,16 +2114,16 @@ 
    USVString email;
   USVString given_name;
   USVString picture;
-  sequence<USVString> approved_clients;
+  sequence<USVString> approved_clients;
   sequence<DOMString> login_hints;
   sequence<DOMString> domain_hints;
 };
 dictionary IdentityProviderAccountList {
-  sequence<IdentityProviderAccount> accounts;
+  sequence<IdentityProviderAccount> accounts;
 };
    • - To fetch the account picture given an IdentityProviderAccount account and a globalObject, run the following steps: + To fetch the account picture given an IdentityProviderAccount account and a globalObject, run the following steps:

    1. Let pictureUrl be the result of running parse url with account["picture"] and globalObject.

      @@ -2346,7 +2190,7 @@

      Let requestBody be the result of running urlencoded serializer with a list containing:

      1. -

        ("client_id", provider’s clientId)

        +

        ("client_id", provider’s clientId)

      2. ("nonce", provider’s nonce)

      3. @@ -2385,7 +2229,7 @@

        "webidentity"

        origin
        -

        globalObject’s associated document's origin

        +

        globalObject’s associated document's origin

        header list

        a list containing a single header with name set to Accept and value set to application/x-www-form-urlencoded

        @@ -2394,10 +2238,8 @@

        "include"

        mode
        -

        "no-cors"

        +

        "cors"

        -

        The spec is yet to be updated so that all requests are created -with mode set to "user-agent-no-cors". See the relevant pull request for details.

      4. Let credential be null.

      5. @@ -2429,14 +2271,14 @@

        2.3.8. Request permission to sign-up

        - To select an account given an accountsList, run the following steps. This returns an IdentityProviderAccount or failure. + To select an account given an accountsList, run the following steps. This returns an IdentityProviderAccount or failure.

        1. Assert accountsList’s size is greater than 1.

        2. Display an account chooser displaying the options from accountsList.

        3. -

          Let account be the IdentityProviderAccount of the account that the user +

          Let account be the IdentityProviderAccount of the account that the user manually selects from the accounts chooser, or failure if no account is selected.

        4. Return account.

          @@ -2446,7 +2288,7 @@

          - To request permission to sign-up the user with a given an IdentityProviderAccount account, + To request permission to sign-up the user with a given an IdentityProviderAccount account, an IdentityProviderAPIConfig config, an IdentityProviderRequestOptions provider, and a globalObject, run the following steps. This returns a boolean.
          1. @@ -2458,11 +2300,11 @@

          2. If metadata is not failure, metadata["privacy_policy_url"] -is defined and the provider’s clientId is not in the list of account["approved_clients"], then the user agent MUST display +is defined and the provider’s clientId is not in the list of account["approved_clients"], then the user agent MUST display the metadata["privacy_policy_url"] link.

          3. If metadata is not failure, metadata["terms_of_service_url"] -is defined, and the provider’s clientId is not in the list of account["approved_clients"], then the user agent MUST display +is defined, and the provider’s clientId is not in the list of account["approved_clients"], then the user agent MUST display the metadata["terms_of_service_url"] link.

          4. The user agent MAY use the context to customize the @@ -2485,7 +2327,7 @@

            If clientMetadataUrl is failure, return failure.

          5. -

            Let request be a new request as follows:

            +

            Let request be a new request as follows:

            url
            @@ -2507,19 +2349,19 @@

            "webidentity"

            origin
            -

            globalObject’s associated document's origin

            +

            globalObject’s associated document's origin

            header list

            a list containing a single header with name set to Accept and value set to application/json

            credentials mode

            "omit"

            -
            mode +
            mode

            "no-cors"

            -

            The spec is yet to be updated so that all requests are created -with mode set to "user-agent-no-cors". See the relevant pull request for details.

            +

            The spec is yet to be updated so that all requests are created +with mode set to "user-agent-no-cors". See the relevant pull request for details.

          6. Let metadata be null.

          7. @@ -2561,7 +2403,7 @@

          - To fetch request given a request request, globalObject, and an algorithm processResponseConsumeBody, run the following steps: + To fetch request given a request request, globalObject, and an algorithm processResponseConsumeBody, run the following steps:

          1. Queue a global task on the network task source given globalObject to:

            @@ -2587,7 +2429,7 @@

            If manifestUrl is failure, return failure.

          2. -

            If manifestUrl is not same origin with configUrl, return failure.

            +

            If manifestUrl is not same origin with configUrl, return failure.

          3. If manifestUrl is not a potentially trustworthy URL, return failure.

          4. @@ -2615,7 +2457,7 @@

          - To show an IDP login dialog given an IdentityProviderAPIConfig config, an IdentityProviderConfig provider, and a globalObject, run the following steps. This returns + To show an IDP login dialog given an IdentityProviderAPIConfig config, an IdentityProviderConfig provider, and a globalObject, run the following steps. This returns success or failure.
          1. @@ -2686,7 +2528,7 @@

            Exposed=Window, SecureContext] interface IdentityProvider { static undefined close(); - static Promise<sequence<IdentityUserInfo>> getUserInfo(IdentityProviderConfig config); + static Promise<sequence<IdentityUserInfo>> getUserInfo(IdentityProviderConfig config); };

            Decide whether IdentityProvider is the @@ -2699,7 +2541,7 @@

            show an IDP login dialog algorithm for more details.

            An IdentityUserInfo represents user account information from a user. This information is exposed to the IDP once the user has already used the FedCM API to login in the RP. That is, it is -exposed when there exists an account account such that the connected accounts set contains the triple (RP, IDP, account). The information matches what is received from the accounts endpoint. The IDP can obtain this information by invoking the getUserInfo() static method from an iframe matching the origin of its configURL.

            +exposed when there exists an account account such that the connected accounts set contains the triple (RP, IDP, account). The information matches what is received from the accounts endpoint. The IDP can obtain this information by invoking the getUserInfo() static method from an iframe matching the origin of its configURL.

            const userInfo = await IdentityProvider.getUserInfo({
@@ -2718,22 +2560,22 @@ 
            
-     When invoking the getUserInfo() method given an IdentityProviderConfig provider, perform the following steps: 
+     When invoking the getUserInfo() method given an IdentityProviderConfig provider, perform the following steps: 
     
              
      
            1. 
       
              Let globalObject be the current global object.
              
      
            2. 
-      
              Let document be globalObject’s associated Document.
              
+      
              Let document be globalObject’s associated Document.
              
      
            3. 
       
              If document is not allowed to use the identity-credentials-get policy-controlled feature, throw a "NotAllowedError" DOMException.
              
      
            4. 
-      
              If there does not exist an account account such that compute the connection status of provider, account, and globalObject returns connected, then throw a new "NetworkError" DOMException. This check can be performed by iterating over the connected accounts set or by keeping a separate data structure to make this lookup fast.
              
+      
              If there does not exist an account account such that connected accounts set contains the result of compute the connected account key given account, provider, and globalObject, then reject promise with a "NetworkError" DOMException. This check can be performed by iterating over the connected accounts set or by keeping a separate data structure to make this lookup fast.
              
      
            5. 
       
              Let configUrl be the result of running parse url with provider’s configURL and globalObject.
              
      
            6. 
       
              If configUrl is failure, throw an "InvalidStateError" DOMException.
              
      
            7. 
-      
              If document’s origin is not same origin as configUrl’s origin,
+      
              If document’s origin is not same origin as configUrl’s origin,
 throw an "InvalidStateError" DOMException.
              
      
            8. 
       
              Run a Content Security Policy Level 3 check with a connect-src directive on the URL
@@ -2751,27 +2593,26 @@ 
              fetch the config file with provider and globalObject.
              
        
            9. 
-        
              If config is failure, reject promise with a new "NetworkError" DOMException.
              
+        
              If config is failure, reject promise with a new "NetworkError" DOMException.
              
        
            10. 
         
              Let accountsList be the result of fetch the accounts with config, provider,
 and globalObject.
              
        
            11. 
-        
              Let hasReturningAccount be false.
              
+        
              Let hasAccountEligibleForAutoReauthentication be false.
              
        
            12. 
         
              For each account in accountsList:
              
         
                
          
              1. 
-          
                If account["approved_clients"] is not empty and it does not contain provider’s clientId, continue.
                
+          
                If account["approved_clients"] is not empty and it does not contain provider’s clientId, continue.
                
           
                Note: this allows the IDP to override whether an account is a returning account.
 This could be useful for instance in cases where the user has disconnected the
 account out of band.
                
          
              2. 
-          
                Compute the connection status of provider, account, and globalObject. If the
-result is connected, set hasReturningAccount to
-true.
                
+          
                If account is eligible for auto reauthentication given provider and globalObject, set hasAccountEligibleForAutoReauthentication to true.
                
         
              
        
            13. 
-        
              If hasReturningAccount is false, reject promise with a new "NetworkError" DOMException.
              
+        
              If hasAccountEligibleForAutoReauthentication is false, reject promise with a new
+"NetworkError" DOMException.
              
        
            14. 
         
              Let userInfoList be a new list.
              
        
            15. 
@@ -2821,7 +2662,7 @@ 
              3. <
 to execute these in such a way that it does not allow the user to be tracked (by an attacker
 impersonating an IDP) on to the site using FedCM. The following table has information about the
 network requests performed:
              
-   
+   
              
     
      
              
       Endpoint
@@ -2991,7 +2832,7 @@ 
              
    
    
              The response body must be a JSON object that can be converted to an IdentityProviderAccountList without an exception.
              
-   
              Every IdentityProviderAccount is expected to have members with the following semantics:
              
+   
              Every IdentityProviderAccount is expected to have members with the following semantics:
              
    
              
     
              id,  of type USVString
     
              
@@ -3010,7 +2851,7 @@ 
              URL for the account’s picture.
              
     
              approved_clients,  of type sequence<USVString>
     
              
-     
              A list of RPs (that gets matched against the requesting clientId) this account is already registered with.
+     
              A list of RPs (that gets matched against the requesting clientId) this account is already registered with.
 Used in the request permission to sign-up to allow the IDP to control whether to show
 the Privacy Policy and the Terms of Service.
              
     
              login_hints,  of type sequence<DOMString>
@@ -3128,7 +2969,7 @@ 
              
    
    
               An IDP MUST check the Origin header to ensure that a malicious RP does
 not receive an ID token corresponding to another RP. In other words, the IDP MUST check that
-the Origin header value is represented by the clientId. As the clientId are IDP-specific, the user agent cannot perform this check. 
              
+the Origin header value is represented by the clientId. As the clientId are IDP-specific, the user agent cannot perform this check. 
    
              The response body must be a JSON object that can be converted to an IdentityProviderToken without an exception.
              
    
              Every IdentityProviderToken is expected to have members with the following semantics:
              
    
              
@@ -3155,14 +2996,14 @@ 
              
    
    
              3.6. Disconnect endpoint
              
    
              The disconnect endpoint is responsible for disconnecting a previously made federated
-login connection between an RP and an IDP account, and returning the account’s id so that the user agent can remove it from the connected accounts set.
              
+login connection between an RP and an IDP account, and returning the account’s id so that the user agent can remove it from the connected accounts set.
              
    
              The disconnect endpoint is fetched when invoking the disconnect method:
              
    
              (a) as a POST request,
 (b) with IDP cookies,
 (c) with the RP's origin in the Origin header,
 (d) with the Sec-Fetch-Dest header set to webidentity,
 (e) without following HTTP redirects, and
-(f) in "cors" mode.
              
+(f) in "cors" mode.
              
    
              It will also contain the following in the request body application/x-www-form-urlencoded:
              
    
              
     
              client_id
@@ -3191,9 +3032,9 @@ 
              
      
              The id of the account that was successfully disconnected.
              
    
              
-   
              The IDP must return the account_id since it may be different from the account_hint, and the ID is the one which allows the user agent to disconnect the account from the connected accounts set. If the IDP returns an error or
+   
              The IDP must return the account_id since it may be different from the account_hint, and the ID is the one which allows the user agent to disconnect the account from the connected accounts set. If the IDP returns an error or
 the user agent does not find the account with the ID provided by the IDP, then all accounts
-associated with the relevant (RP, IDP) are removed from the connected accounts set.
              
+associated with the relevant (RP, IDP) are removed from the connected accounts set.
              
    
              4. Permissions Policy Integration
              
    
              FedCM defines a policy-controlled feature identified by the string "identity-credentials-get".
 Its default allowlist is "self".
              
@@ -3256,7 +3097,7 @@ 
              /session/{session id}/fedcm/canceldialog
     
              
    
-   
              The remote end steps are:
              
+   
              The remote end steps are:
              
    
                
     
              1. 
      
                If no FedCM dialog is currently open, return a WebDriver error with error code no such alert.
                
@@ -3279,7 +3120,7 @@ 
                /session/{session id}/fedcm/selectaccount
     
    
-   
                The remote end steps are:
                
+   
                The remote end steps are:
                
    
                  
     
                1. 
      
                  If parameters is not a JSON Object, return a WebDriver error with error code invalid argument.
                  
@@ -3310,7 +3151,7 @@ 
                  /session/{session id}/fedcm/clickdialogbutton
     
    
-   
                  The remote end steps are:
                  
+   
                  The remote end steps are:
                  
    
                    
     
                  1. 
      
                    If parameters is not a JSON Object, return a WebDriver error with error code invalid argument.
                    
@@ -3342,7 +3183,7 @@ 
                    /session/{session id}/fedcm/accountlist
     
    
-   
                    The remote end steps are:
                    
+   
                    The remote end steps are:
                    
    
                      
     
                    1. 
      
                      If no FedCM dialog is currently open, return a WebDriver error with error code no such alert.
                      
@@ -3355,7 +3196,7 @@ 
                      For each account in accounts:
                      
      
                        
       
                      1. 
-       
                        Let accountState be the result of running the compute the connection status algorithm given account and the IdentityProviderRequestOptions of the IDP account belongs to
                        
+       
                        Let accountState be the result of running the compute the connection status algorithm given account and the IdentityProviderRequestOptions of the IDP account belongs to
                        
       
                      2. 
        
                        Append a dictionary to list with the following properties:
                        
        
                          
@@ -3375,7 +3216,7 @@ 
                          idpConfigUrl set to the configURL of the
 IDP this account belongs to
                          
         
                        1. 
-         
                          loginState to "SignUp" if accountState is disconnected and "SignIn" otherwise
                          
+         
                          loginState to "SignUp" if accountState is disconnected and "SignIn" otherwise
                          
         
                        2. 
          
                          termsOfServiceUrl to the terms_of_service_url if one was provided and the loginState is "SignUp", otherwise undefined
                          
         
                        3. 
@@ -3398,8 +3239,8 @@ 
                          /session/{session id}/fedcm/gettitle
     
    
-   
                          Note: This command lets automation verify that the context api was applied properly
                          
-   
                          The remote end steps are:
                          
+   
                          Note: This command lets automation verify that the context api was applied properly
                          
+   
                          The remote end steps are:
                          
    
                            
     
                          1. 
      
                            If no FedCM dialog is currently open, return a WebDriver error with error code no such alert.
                            
@@ -3427,7 +3268,7 @@ 
                            /session/{session id}/fedcm/getdialogtype
     
    
-   
                            The remote end steps are:
                            
+   
                            The remote end steps are:
                            
    
                              
     
                            1. 
      
                              If no FedCM dialog is currently open, return a WebDriver error with error code no such alert.
                              
@@ -3451,7 +3292,7 @@ 
                              /session/{session id}/fedcm/setdelayenabled
     
    
-   
                              The remote end steps are:
                              
+   
                              The remote end steps are:
                              
    
                                
     
                              1. 
      
                                If parameters is not a JSON Object, return a WebDriver error with error code invalid argument.
                                
@@ -3478,7 +3319,7 @@ 
                                /session/{session id}/fedcm/resetcooldown
     
    
-   
                                The remote end steps are:
                                
+   
                                The remote end steps are:
                                
    
                                  
     
                                1. 
      
                                  If the user agent uses a cooldown delay, which disables the API for an
@@ -3509,14 +3350,19 @@ 
                                  IDP endpoints.
                                  
-   
                                  6.3. Browser Surface Impersonation
                                  
+   
                                  6.3. CORS Header
                                  
+   
                                  The FedCM API allows the response from the identity assertion endpoint to be shared to the RP. Because of this, we impose the requirement that the IDP explicitly consents to this
+sharing taking place by using the "cors" mode when fetching this endpoint. This also
+helps with servers that may accidentally ignore the Sec-Fetch-Dest: they cannot
+ignore CORS, as without it the fetch will fail.
                                  
+   
                                  6.4. Browser Surface Impersonation
                                  
    
                                  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
 this UI. This introduces a potential concern of a malicious site to try to replicate the FedCM UI,
 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 another site). This would be hard to achieve because the FedCM UI uses
-metadata about the user accounts of the IDP, which the malicious website doesn’t have access to.
+metadata about the user accounts of the IDP, 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
@@ -3536,22 +3382,22 @@ 
                                  
    
                                    
     
                                  1. 
-     
                                    The user agent implements § 2 The Browser API and controls the execution contexts for the RP and IDP content. The user agent is assumed to be trusted by the user, and transitively
-trusted by the RP and IDP.
                                    
+     
                                    The user agent implements § 2 The Browser API and controls the execution contexts for the RP and IDP content. The user agent is assumed to be trusted by the user, and transitively
+trusted by the RP and IDP.
                                    
     
                                  2. 
-     
                                    RPs are websites that invoke the FedCM API for the purpose of
+     
                                    RPs 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, RPs cannot necessarily be trusted to limit the user information it
+site can invoke the API, RPs cannot necessarily be trusted to limit the user information it
 collects or use that information in an acceptable way.
                                    
     
                                  3. 
-     
                                    IDPs are third-party websites that are the target of a FedCM call to
-attempt to fetch a token. Usually,the IDP has a higher level of trust than the RP since it already has the user’s personal information, but it is possible that the IDP might use the user’s information in non-approved ways. In addition, it is possible that the IDP specified in the API call may not be an IDP the user knows about. In this case, it
+     
                                    IDPs are third-party websites that are the target of a FedCM call to
+attempt to fetch a token. Usually,the IDP has a higher level of trust than the RP since it already has the user’s personal information, but it is possible that the IDP might use the user’s information in non-approved ways. In addition, it is possible that the IDP specified in the API call may not be an IDP the user knows about. In this case, it
 likely does not have personal user information in advance.
                                    
     
                                  4. 
-     
                                    A tracker is a third-party website that is not an IDP but could abuse the FedCM API
+     
                                    A tracker is a third-party website that is not an IDP but could abuse the FedCM API
 exclusively for the purpose of tracking a user as they visit various websites. A tracker may
-be injected by the RP with or without their knowledge (e.g. injected into one of the various
-script tags that the RP embeds that is loaded dynamically), but they usually do not modify
+be injected by the RP with or without their knowledge (e.g. injected into one of the various
+script tags that the RP embeds that is loaded dynamically), but they usually do not modify
 the UI of the website, so that it is harder to detect the tracking. A tracker that
 successfully adds tracking scripts for users in various websites may then use this information
 for various purposes, such as selling the information about the user. It should not be possible
@@ -3560,21 +3406,21 @@ 
                                    Based on the above, the privacy discussion makes the following assumptions:
                                    
    
                                      
     
                                    1. 
-     
                                      It is not acceptable for an RP, IDP, or tracker to learn that a specific user visited a
+     
                                      It is not acceptable for an RP, IDP, or tracker to learn that a specific user visited a
 specific site, without any permission granted by the user. That is, the user agent needs to hide the
-knowledge that a specific user identity visited a specific site from the RP, IDP, and trackers. It may share this knowledge with the RP and IDP once the user grants permission. In
-particular, the RP should not know the user identity and the IDP should not know the
+knowledge that a specific user identity visited a specific site from the RP, IDP, and trackers. It may share this knowledge with the RP and IDP once the user grants permission. In
+particular, the RP should not know the user identity and the IDP should not know the
 site that the user has visited before the FedCM flow gathers the user’s permission to do so.
                                      
     
                                    2. 
-     
                                      It is the user agent's responsibility to determine when the user has granted permission for the IDP to communicate with the RP in order to provide identification for the user.
                                      
+     
                                      It is the user agent's responsibility to determine when the user has granted permission for the IDP to communicate with the RP in order to provide identification for the user.
                                      
     
                                    3. 
      
                                      Once the user agent has determined that the user has granted permission to provide their
-account information to the RP, it is ok for the IDP and for the RP to learn
-information about that specific user’s account, as required to provide identification. The RP should not learn about about any other user accounts.
                                      
+account information to the RP, it is ok for the IDP and for the RP to learn
+information about that specific user’s account, as required to provide identification. The RP should not learn about about any other user accounts.
                                      
    
                                    
    
                                    7.2. Network requests
                                    
    
                                    This specification ensures that the FedCM fetches are all same-origin with respect to the provider specified
-by the RP. The reason for this is because fetches with cookies would use the cookies from the
+by the RP. The reason for this is because fetches with cookies would use the cookies from the
 origin specified, so allowing arbitrary origins would introduce confusion and potential privacy
 issues with regards to which cookies are shared and with whom within the FedCM flow. The easiest way
 to ensure that all of these fetches remain same-origin is by disabling redirects and checking the
@@ -3585,49 +3431,49 @@ 
                                    accounts endpoint fetch can’t be used to track users because it is performed with cookies from the IDP but, importantly, without the client_id or referrer. This in theory is a new power
-that the RP gains that it would not have otherwise. Preventing too many of these fetches may
-be important, but IDPs are already expected to protect against DoS attacks. In addition, the
+     
                                    The accounts endpoint fetch can’t be used to track users because it is performed with cookies from the IDP but, importantly, without the client_id or referrer. This in theory is a new power
+that the RP gains that it would not have otherwise. Preventing too many of these fetches may
+be important, but IDPs 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 IDP does learn a lot about the user from this fetch, but this is discussed in detail below.
                                    
+interacts or after a long timer, the number of fetches performed is not a concern. The IDP does learn a lot about the user from this fetch, but this is discussed in detail below.
                                    
     
                                  5. 
      
                                    The client metadata endpoint fetch can’t be used to track users too because it is performed without cookies
-from the IDP, albeit with a client_id and a referrer. This allows the IDP to
+from the IDP, albeit with a client_id and a referrer. This allows the IDP 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 RP gains nothing from this fetch, and the RP could already perform this fetch if it wanted to
-since it involves no cookies from the IDP.
                                    
+they need to be displayed. Again, besides possible timing attacks described here, the RP gains nothing from this fetch, and the RP could already perform this fetch if it wanted to
+since it involves no cookies from the IDP.
                                    
     
                                  6. 
-     
                                    By design, the token fetch exposes the user at the website to the IDP: it is
+     
                                    By design, the token fetch exposes the user at the website to the IDP: it is
 peformed with cookies, client_id, and referrer. Because of that, it is gated on the user
-interacting with the user agent UI, and enables the IDP to communicate to the RP the
-information required to perform a federated signin/signup. It is not possible for the RP or
-the IDP to force the token fetch to happen without user permission, as the user agent cannot be
+interacting with the user agent UI, and enables the IDP to communicate to the RP the
+information required to perform a federated signin/signup. It is not possible for the RP or
+the IDP to force the token fetch to happen without user permission, as the user agent cannot be
 spoofed or otherwise tricked.
                                    
     
                                  7. 
      
                                    The disconnect endpoint may only be fetched after the user has successfully gone through the
-FedCM flow at least once in the RP. It sends a credentialed request to the IDP, so it
+FedCM flow at least once in the RP. It sends a credentialed request to the IDP, so it
 is important that the user agent 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 connected accounts set, thus ensuring that
-this endpoint does not introduce a way for the RP to send requests to the IDP containing
-the IDP cookies forever.
                                    
+request, at least one account is removed from the connected accounts set, thus ensuring that
+this endpoint does not introduce a way for the RP to send requests to the IDP containing
+the IDP cookies forever.
                                    
    
    
                                    7.3. Attack Scenarios
                                    
    
                                    This section describes the scenarios in which various agents might attempt to gain user information.
 It considers the possibilities when:
                                    
    
                                      
     
                                    • 
-     
                                      The RP is collecting information,
                                      
+     
                                      The RP is collecting information,
                                      
     
                                    • 
-     
                                      The IDP is collecting information, or
                                      
+     
                                      The IDP is collecting information, or
                                      
     
                                    • 
-     
                                      Both the RP and the IDP are colluding.
                                      
+     
                                      Both the RP and the IDP are colluding.
                                      
    
                                    
    
                                    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.
                                    
-   
                                    Note: An example of indirect collusion would be an RP importing a script supplied by an IDP where the IDP intends to track users.
                                    
+   
                                    Note: An example of indirect collusion would be an RP importing a script supplied by an IDP where the IDP intends to track users.
                                    
    
                                    For the purpose of discussion, this document assumes that third-party cookies are disabled 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
@@ -3648,21 +3494,21 @@

            NOTE: You can read more about the attack described here.

            -

            Here, the RP includes identifies itself when fetching the manifest from the IDP. This -coupled with the credentialed fetches that the FedCM API performs would enable the IDP to easily +

            Here, the RP includes identifies itself when fetching the manifest from the IDP. This +coupled with the credentialed fetches that the FedCM API performs would enable the IDP 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 § 3.1 The Well-Known File file. The existence of a file at -the root of the IDP's domain is enforced to ensure that the file name does not introduce -fingerprints about the RP being visited.

            +the root of the IDP's domain is enforced to ensure that the file name does not introduce +fingerprints about the RP being visited.

            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 IDP require this in the future, instead of just a single one. It -also helps the IDP's implementation because they any changes to the manifest are more likely to +number of manifests, should an IDP require this in the future, instead of just a single one. It +also helps the IDP'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.

            7.3.2. Timing Attacks

            -

            In the timing attack, the RP and IDP collude to allow the IDP to compute the (RP's -origin, IDP's user identity) pair without the user’s permission. This attack is not deterministic: +

            In the timing attack, the RP and IDP collude to allow the IDP to compute the (RP's +origin, IDP'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 @@ -3674,20 +3520,20 @@

            RP logs the time at which it invokes the API, time A and sends it to the IDP to -learn itself by marking the time in which it receives the fetch for the RP's client +

            The RP logs the time at which it invokes the API, time A and sends it to the IDP to +learn itself by marking the time in which it receives the fetch for the RP's client metadata. Time A is tied to the site.

          2. -

            A credentialed request is sent to the IDP that does not explicitly identify the RP, but -it is sent around a time that is close enough to the request above. The IDP notes the time +

            A credentialed request is sent to the IDP that does not explicitly identify the RP, but +it is sent around a time that is close enough to the request above. The IDP notes the time in which this request has arrived, time B. Time B is tied to the user identity.

          3. -

            The IDP correlates time A and time B to find the (site, user identity) pair with high +

            The IDP 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.

          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 IDP could return empty accounts +timing resolution or if it was less visible to users (e.g. the IDP could return empty accounts to the user agent to deliberately make no browser UI to be triggered, and hence make this attack invisible to the user).

          The user agent should mitigate this attack to protect users, in an interoperable way.

          @@ -3702,9 +3548,9 @@

          RP and an IDP are colluding to +

          In the context of federation, intrusion happens when an RP and an IDP are colluding to invasively and aggressively recommend the user to login disproportionally to the their intent. Much -like unsolicited notifications, an RP can collude with an IDP to aggressively log users in.

          +like unsolicited notifications, an RP can collude with an IDP to aggressively log users in.

          The user agent 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 user agent can choose to show a loud / disruptive modal mediated dialog when it has enough confidence of the user’s intent or @@ -3714,7 +3560,7 @@

          - + @@ -3768,7 +3614,7 @@

          - + @@ -3814,7 +3660,7 @@

          - + @@ -3833,20 +3679,20 @@

          +

          7.3.4. Cross-Site Correlation

          -

          This attack happens when multiple RPs collude to use their user’s data to correlate them and +

          This attack happens when multiple RPs collude to use their user’s data to correlate them and build a richer profile. When a user willingly provides their full name, email address, phone number, etc, to multiple relying parties, those relying parties can collaborate to build a profile of that 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 user -agent’s or IDP’s view.

          +agent’s or IDP’s view.

          - + @@ -3893,7 +3739,7 @@

          - + @@ -3903,7 +3749,7 @@

          - + @@ -3920,7 +3766,7 @@

          - + @@ -3930,7 +3776,7 @@

          - + @@ -3942,7 +3788,7 @@

          - + @@ -3952,7 +3798,7 @@

          - + @@ -3972,7 +3818,7 @@

          - +

          @@ -3998,14 +3844,14 @@

          RPs joining user data via back-channels is inherent to the proliferation of +

          The problem of RPs 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 IDP that is unique and therefore cannot be -correlated with other RPs. In the past, there have been schemes to accomplish this using one-way -hashes of, for example, the user’s name, the IDP, and the RP. These identifiers would be -unique, and hence it would not be possible to correlate these with other RPs.

          +effective handle to a user’s identity with a given IDP that is unique and therefore cannot be +correlated with other RPs. In the past, there have been schemes to accomplish this using one-way +hashes of, for example, the user’s name, the IDP, and the RP. These identifiers would be +unique, and hence it would not be possible to correlate these with other RPs.

          - + @@ -4043,7 +3889,7 @@

          - + @@ -4083,7 +3929,7 @@

          - + @@ -4132,7 +3978,7 @@

          - + @@ -4141,7 +3987,7 @@

          - + @@ -4208,24 +4054,24 @@

          - +

          7.3.5. Unauthorized Data Usage

          -

          Another attack is when the RP or IDP uses user information for purposes not authorized by -the user. When the user agrees to allow the IDP to provide information to the RP, the -permission is specific to certain purposes, such as sign-in and personalization. For instance, the RP might use that data for other purposes that the user would not expect and did not authorize, +

          Another attack is when the RP or IDP uses user information for purposes not authorized by +the user. When the user agrees to allow the IDP to provide information to the RP, the +permission is specific to certain purposes, such as sign-in and personalization. For instance, the RP 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.

          7.3.6. RP Fingerprinting

          -

          This attack happens when the RP employs client state-based tracking to identify user. Any +

          This attack happens when the RP employs client state-based tracking to identify user. Any API that exposes any kind of client state to the web risk becoming a vector for fingerprinting. The -purpose of this API is for the user to provide identification to the RP. And the user should be -able to rescind the access to that identification, for instance by logging out. However, a tracking RP could keep state to detect the user that was previously logged in:

          +purpose of this API is for the user to provide identification to the RP. And the user should be +able to rescind the access to that identification, for instance by logging out. However, a tracking RP could keep state to detect the user that was previously logged in:

          - + @@ -4265,27 +4111,27 @@

          - + - +

          7.3.7. Secondary Use

          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 IDPs misuse the information collected to enable sign-in for other purposes.

          -

          Existing federation protocols require that the IDP know which service is requesting a token +happens when IDPs misuse the information collected to enable sign-in for other purposes.

          +

          Existing federation protocols require that the IDP 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.

          -

          This risk can exist even in the case where the IDP does not having pre-existing user account -information (for instance, if it is not a _bona fide_ IDP), because FedCM requests sent to the IDP are credentialed. This is more likely to occur if the RP is colluding with the IDP to enable tracking via § 7.3.2 Timing Attacks.

          +

          This risk can exist even in the case where the IDP does not having pre-existing user account +information (for instance, if it is not a _bona fide_ IDP), because FedCM requests sent to the IDP are credentialed. This is more likely to occur if the RP is colluding with the IDP to enable tracking via § 7.3.2 Timing Attacks.

          - + @@ -4311,7 +4157,7 @@

          - + @@ -4346,7 +4192,7 @@

          - + @@ -4387,8 +4233,8 @@

          - - + +

          @@ -4396,25 +4242,25 @@

          1. -

            User signs into RP1 (which sells jewelry) with an IDP.

            +

            User signs into RP1 (which sells jewelry) with an IDP.

          2. -

            User signs into RP2 (which sells houses) with the same IDP.

            +

            User signs into RP2 (which sells houses) with the same IDP.

          3. -

            User navigates to the IDP.

            +

            User navigates to the IDP.

          4. -

            Because the IDP knows that the user has an account with RP1 and RP2, the IDP can show ads about vacations for honeymoons.

            +

            Because the IDP knows that the user has an account with RP1 and RP2, the IDP can show ads about vacations for honeymoons.

          5. -

            The user is surprised that their IDP is aware of their plans to get +

            The user is surprised that their IDP is aware of their plans to get married.

        -

        Preventing tracking of users by the IDP is difficult: the RP has to be coded into the +

        Preventing tracking of users by the IDP is difficult: the RP 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 IDP to the RP while still +been cryptographic schemes developed to blind the IDP to the RP while still preventing token reuse(see Mozilla’s personas). These schemes have not been adopted by this specification.

        - + @@ -4457,7 +4303,7 @@

        - + @@ -4500,7 +4346,7 @@

        - + @@ -4510,7 +4356,7 @@

        - +

        @@ -4518,6 +4364,40 @@

        Note: go over the extensibility mechanisms.

        9. Acknowledgements

        Note: write down the Acknowledgements section.

        +

        10. FPWD Issues

        + Note: The WG has labeled the following issues as critical open issues that must be formally addressed before publication of a Candidate Recommendation. +

    • Conformance

    @@ -4545,6 +4425,22 @@

    , like this:

    Note, this is an informative note.

    +
    +

    Conformant Algorithms

    +

    Requirements phrased in the imperative as part of algorithms + (such as "strip any leading space characters" + or "return false and abort these steps") + are to be interpreted with the meaning of the key word + ("must", "should", "may", etc) + used in introducing the algorithm.

    +

    Conformance requirements phrased as algorithms or specific steps + can be implemented in any manner, + so long as the end result is equivalent. + In particular, the algorithms defined in this specification + are intended to be easy to understand + and are not intended to be performant. + Implementers are encouraged to optimize.

    +

    Index

    @@ -4570,6 +4466,7 @@

    definition of, in § 3.2
  • dict-member for IdentityProviderBranding, in § 3.2 +
  • compute the connected account key, in § 2.2
  • compute the connection status, in § 2.2
  • computing the manifest URL, in § 2.3.9
  • config file, in § 3.2 @@ -4590,6 +4487,7 @@

    [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors), in § 2.3.3
  • domainHint, in § 2.3.2
  • domain_hints, in § 3.3 +
  • eligible for auto reauthentication, in § 2.2
  • email -
  • NavigatorLogin, in § 2.1.3 +
  • NavigatorLogin, in § 2.1.4
  • nonce, in § 2.3.2
  • parse url, in § 2.3.9
  • @@ -4667,11 +4565,12 @@

    remove all connections, in § 2.2
  • request permission to sign-up, in § 2.3.8
  • RP, in § 1 +
  • same-site with its ancestors, in § 2.1.2
  • select an account, in § 2.3.8
  • send a disconnect request, in § 2.3.1.1
  • setdelayenabled, in § 5.8 -
  • Set-Login, in § 2.1.2 -
  • setStatus(status), in § 2.1.3 +
  • Set-Login, in § 2.1.3 +
  • setStatus(status), in § 2.1.4
  • set the login status, in § 2.1.1
  • show an IDP login dialog, in § 2.3.9
  • "signin", in § 2.3.2 @@ -4796,8 +4695,10 @@

    [HTML] defines the following terms:
    • Navigator +
    • active document
    • allowed to use
    • associated document +
    • browsing context
    • create a fresh top-level traversable
    • current global object
    • current settings object @@ -4806,14 +4707,18 @@

      in parallel
    • navigable
    • networking task source +
    • node navigable
    • opaque origin
    • origin
    • origin (for environment settings object) +
    • parent
    • permissions policy
    • queue a global task
    • realm +
    • relevant global object
    • relevant settings object
    • same origin +
    • same site
    • scheme
    • top-level origin
    • top-level traversable @@ -4856,6 +4761,11 @@

      default allowlist
    • policy-controlled feature

    +
  • + [PRIVATE-AGGREGATION-API] defines the following terms: +
      +
    • remote end steps +
  • [SECURE-CONTEXTS] defines the following terms:
      @@ -4892,7 +4802,6 @@

      error
    • extension commands
    • invalid argument -
    • remote end steps
    • success

  • @@ -4925,7 +4834,7 @@

    N
    [CLEAR-SITE-DATA]
    Mike West. Clear Site Data. URL: https://w3c.github.io/webappsec-clear-site-data/
    [CREDENTIAL-MANAGEMENT-1] -
    Nina Satragno. Credential Management Level 1. URL: https://w3c.github.io/webappsec-credential-management/ +
    Nina Satragno; Marcos Caceres. Credential Management Level 1. URL: https://w3c.github.io/webappsec-credential-management/
    [CSP]
    Mike West; Antonio Sartori. Content Security Policy Level 3. URL: https://w3c.github.io/webappsec-csp/
    [CSS-COLOR-4] @@ -4956,6 +4865,8 @@

    N
    Ian Clelland. Permissions Policy. URL: https://w3c.github.io/webappsec-permissions-policy/
    [PRIVACY-THREAT-MODEL]
    Target Privacy Threat Model. URL: https://w3cping.github.io/privacy-threat-model/ +
    [PRIVATE-AGGREGATION-API] +
    Private Aggregation API. Unofficial Proposal Draft. URL: https://patcg-individual-drafts.github.io/private-aggregation-api/
    [RFC2119]
    S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc2119
    [RFC6973] @@ -5132,60 +5043,10 @@

    mode set to "user-agent-no-cors". See the relevant pull request for details. ↵
    The spec is yet to be updated so that all requests are created with mode set to "user-agent-no-cors". See the relevant pull request for details. ↵
    -
    The spec is yet to be updated so that all requests are created -with mode set to "user-agent-no-cors". See the relevant pull request for details. ↵
    Decide whether IdentityProvider is the correct location for the getUserInfo() method. ↵
    Clarify the IDP API response when the user is not signed in. ↵
    -
    - ⚠MDN -
    -

    IdentityCredential/token

    -

    In only one current engine.

    -
    - FirefoxNoneSafariNoneChrome108+ -
    - Opera?Edge108+ -
    - Edge (Legacy)?IENone -
    - Firefox for Android?iOS Safari?Chrome for Android?Android WebView?Samsung Internet?Opera Mobile? -
    -
    -
    -
    - ⚠MDN -
    -

    IdentityCredential

    -

    In only one current engine.

    -
    - FirefoxNoneSafariNoneChrome108+ -
    - Opera?Edge108+ -
    - Edge (Legacy)?IENone -
    - Firefox for Android?iOS Safari?Chrome for Android?Android WebView?Samsung Internet?Opera Mobile? -
    -
    -
    -
    - ⚠MDN -
    -

    Headers/Permissions-Policy/identity-credentials-get

    -

    In only one current engine.

    -
    - FirefoxNoneSafariNoneChrome110+ -
    - Opera?Edge110+ -
    - Edge (Legacy)?IENone -
    - Firefox for Android?iOS Safari?Chrome for Android?Android WebView?Samsung Internet?Opera Mobile? -
    -
    -
    -