In the FedCM API, when a user is signing in to a relying party (RP) with an identity provider (IdP) in the browser for the first time, the browser will treat them as a “new” user since it didn’t observe such a sign-in moment before. When the FedCM API is invoked again on the same RP with the same IdP, the browser will treat them as a “returning” user and may trigger “returning user only features” like auto re-authentication <https://developer.chrome.com/blog/fedcm-auto-reauthn/> or providing user info to IdP <https://developer.chrome.com/blog/fedcm-chrome-116-updates/#user-info>.
Strictly speaking, the source of truth about whether a user has already created an account on rp.example with idp.example is held by the IdP. The current implementation could lead to suboptimal UX in some cases. For example, a user may create such an account in browser A and can be auto re-authenticated without explicit permission in browser A; however, because of the potential of abuse (e.g. a tracker impersonating an IdP can lie to the browser to bypass explicit mediation), when FedCM API is called in browser B, the user-agent requires an explicit user mediation when it hasn’t observed one, regardless of what it gets from the IdP for privacy reasons. However, there are already many ways that an IdP may get access to third party cookies on the RP: user settings, enterprise policies, heuristics ( Safari <https://webkit.org/blog/8311/intelligent-tracking-prevention-2-0/#:~:text=Temporary%20Compatibility%20Fix%3A%20Automatic%20Storage%20Access%20for%20Popups>, Firefox <https://developer.mozilla.org/en-US/docs/Web/Privacy/State_Partitioning#storage_access_heuristics>, Chrome in progress <https://chromestatus.com/feature/5181771549507584>) and other Web Platform APIs (e.g. Storage Access API <https://developer.mozilla.org/en-US/docs/Web/API/Storage_Access_API>). In Chrome, this choice is represented by the navigator.cookieEnabled <https://developer.mozilla.org/en-US/docs/Web/API/Navigator/cookieEnabled> API. FedCM provides only a subset of the capabilities possible via third-party cookies, so if the IdP already has access to third-party cookies on the RP, access to FedCM presents no additional privacy risk. Therefore, starting from M121, Chrome will take the “IdP having third party cookies access” factor into consideration and relax the returning user criteria. In particular: 1. If the IdP doesn’t already have access to third party cookies on the RP, continue FedCM’s algorithm as usual 2. Otherwise, if the IdP claims that the user has created an account on the RP (through the approved_clients <https://fedidcg.github.io/FedCM/#dom-identityprovideraccount-approved_clients> list), Chrome will trust that signal and treat the user as a “returning user”, e.g. allowing auto re-authentication <https://developer.chrome.com/blog/fedcm-auto-reauthn/> if other conditions are met. It’s worth noting that Chrome will not override its own returning user knowledge with the IdP’s claim. For example, when an IdP loses the third party cookies access in the future, if a user has not explicitly granted permission via the FedCM UI, Chrome will still treat them as a new user. This change is backward compatible and we have communicated with existing partners such that they are aware of the implications. -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACh2XCNpWu49YfOJf9pSXV25vJJw1iH1x9P8aVKBEDFP%3DonMcQ%40mail.gmail.com.
