Yes to both. FedCM-only: The identity handler SW is only dispatched for FedCM credentialed endpoint requests (accounts, id_assertion, disconnect). Regular visits/requests to the IDP origin are unaffected — the SW is registered with a FedCM-specific association, so it doesn't intercept normal navigations or fetches. FedCM-initiated only: The SW only receives IdentityRequestEvents dispatched by the browser's FedCM flow. It does not intercept arbitrary browser-initiated requests (e.g., cookie-credentialed fetches, navigations) to the IDP origin. On Monday, April 13, 2026 at 10:23:49 PM UTC+5:30 Chris Thompson wrote:
> From a web platform security perspective, this seems reasonable but a > couple of questions as you begin working on implementation: > > 1. Is the FedCM SW only used for FedCM and not regular visits/requests > to the IdP origin? > 2. Is the FedCM SW only used for FedCM-initiated requests, not all > browser-initiated requests to the IdP origin? > > If we could ensure those two points, that would help simplify how to > reason about these SWs (and might mitigate some potential "cross-protocol" > type vulnerabilities). > > Cheers, > - Chris > > On Thursday, April 2, 2026 at 10:59:50 AM UTC-7 Chromestatus wrote: > >> *Contact emails* >> [email protected] >> >> *Explainer* >> https://github.com/w3c-fedid/FedCM/pull/815 >> >> *Specification* >> *No information provided* >> >> *Summary* >> Implement the FedCM Identity Handler, which allows Identity Providers >> (IDPs) to declare a Service Worker in their config.json that intercepts >> credentialed FedCM requests (accounts, id_assertion, disconnect). >> Currently, FedCM fetches to IDP endpoints (accounts, token, disconnect) are >> made directly by the browser with no opportunity for the IDP to augment the >> request. This prevents IDPs from: - Adding DPoP (Demonstration of >> Proof-of-Possession) proof headers - Performing client-side token >> enrichment or transformation - Implementing custom caching strategies for >> account responses - Adding attestation or other security headers to >> credentialed requests The Identity Handler allows IDPs to register a >> Service Worker that receives an `identityrequest` event for each FedCM >> endpoint call, enabling request augmentation before it reaches the IDP >> server. On failure, the browser transparently falls back to normal network >> fetch. Issue : https://github.com/w3c-fedid/FedCM/issues/80 >> >> *Blink component* >> Blink>Identity>FedCM >> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EIdentity%3EFedCM%22> >> >> *Web Feature ID* >> fedcm <https://webstatus.dev/features/fedcm> >> >> *Motivation* >> https://github.com/w3c-fedid/FedCM/issues/80 >> >> *Initial public proposal* >> *No information provided* >> >> *Goals for experimentation* >> None >> >> *Requires code in //chrome?* >> False >> >> *Estimated milestones* >> >> No milestones specified >> >> >> *Link to entry on the Chrome Platform Status* >> https://chromestatus.com/feature/5096917819326464?gate=6247307227037696 >> >> *Links to previous Intent discussions* >> Intent to Prototype: >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/69ceae01.050a0220.1c79a0.01ae.GAE%40google.com >> >> >> This intent message was generated by Chrome Platform Status >> <https://chromestatus.com>. >> > -- 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 [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/db8432a6-1ef3-4227-9074-82922323d789n%40chromium.org.
