Enabling IDP Interception in FedCM Request

[pottis]

The current FedCM specification defines a browser-mediated flow where the browser makes direct HTTP requests to IDP endpoints. This PR implements a foundational capability allowing Identity Providers (IDPs) to intercept and handle FedCM (Federated Credential Management) requests through Service Workers. This feature unlocks advanced security and operational patterns that were previously impossible in the FedCM ecosystem.

Having this feature, it will address some of the key-issue from enterprise identity providers.
Key issues:

• Multi-domain failover: Route to backup IDP when primary fails
• Geographic/sovereign routing: Send requests to jurisdiction-specific servers
• Token caching during outages: Graceful degradation when IDP temporarily unavailable
• DPoP (Request Signing): Prevent token theft with cryptographic proof-of-possession
• Legacy system integration: Wrap existing identity services with FedCM interface

Links:
Issue #80

Explainer : https://github.com/pottis/FedCM/blob/4499cd7593e8f39b588ff3a6cca90e7ffd68beb8/explorations/identity_handler.md

---

Preview | Diff

[TallTed]

I overlooked the incorrectness of <a spec=fetch for=/>response</a> when I wrapped it from line 1590 to 1591. I cannot easily tell what this should be, so I'm not suggesting a correction here ... but I'm flagging the need for that correction. If we can figure it out, I think it can be applied in this PR. If not, this comment should be used to start a new issue.

[domfarolino]

Suggested change

	[=create an IdentityCredentialError|creating an IdentityCredentialError=] with {}
	[=create an IdentityCredentialError|creating an IdentityCredentialError=] with «»

See how the Infra Standard defines list literal syntax. I see there are other pre-existing instances of this in this spec already, but let's start incrementally using the right one.

[pottis]

Issue : #829 logged.

[TallTed]

@domfarolino — Please provide a link to "how the Infra Standard defines list literal syntax" so I and other reviewers don't need to spend time searching for it and maybe find the wrong definition. My immediate question is whether the European quotation mark chevrons («») are what is intended, and not doubled angle brackets (<< >>).

[domfarolino]

https://infra.spec.whatwg.org/#lists

[domfarolino]

same here (and any instances below).

[pottis]

Issue : #829 logged.

[domfarolino]

It seems a little unfortunate that this is not standardized. Has there been any discussion about doing that?

[pottis]

Issue : #829 logged.

[domfarolino]

(Continuation of my other comment, somewhere above)

I'm now realizing for the first time that we don't actually use the target IDP service worker like a normal service worker, where a request is first fetched, and then deep in Fetch, the Service Worker's "handle fetch" algorithm is called with a request that has been heavily processed, its headers set, its client/referrer/origin all resolved, etc.

Here, we're trying to sort of "mock" that by constructing a request, and just immediately firing a functional event inside the service worker passing the very-unprocessed request to the SW directly (i.e., Sec-Fetch-Dest headers were never added). But what good is it to expose this request to script, if it hasn't been processed much yet? Is it the request's URL that script will care about and want to act on?

Was there any discussion about just "fetching" the above request normally, and letting Fetch pass it off to the IDP's service worker (we could easily make it choose a FedCM-specific IDP service worker, instead of the normal one, as we've discussed elsewhere in this PR). That way we could do the normal thing of dispatching a FetchEvent on the service worker, and letting the service worker process the IDP request like any other request.

Maybe this has been discussed before and I'm off base. If so, my bad!

[yoshisatoyanagisawa]

I’d like to offer a different perspective on the architectural layering here. I remain convinced that leveraging the Fire Functional Event algorithm is the correct path forward for FedCM, rather than extending Handle Fetch.

My primary concern is that allowing browser-initiated, cross-origin requests to piggyback on the Handle Fetch event effectively re-opens the door to Foreign Fetch, which is a feature that was intentionally removed due to significant security and privacy risks. If we extend Handle Fetch to support client: null requests for FedCM, we create a precedent that arbitrary standards can use to bypass the Same-Origin Policy (SOP) via the Service Worker pipeline.

As we discussed previously on service-worker-discuss, the Handle Fetch algorithm should remain strictly dedicated to navigations and subresource fetches within a controlled environment. In contrast, the Fire Functional Event algorithm was designed specifically to allow the User Agent to orchestrate specialized interactions with a Service Worker without blurring these fundamental spec boundaries.

This approach keeps the Service Worker specification focused and simple, while placing the responsibility for defining FedCM-specific request/response semantics where they belong: in the FedCM specification.

I would also very much value hearing @wanderview's thoughts on whether extending Handle Fetch in this manner poses a long-term risk to the Service Worker security model.

[wanderview]

I haven't had time to read this PR as its quite long, but the principles you are talking about make sense to me, @yoshisatoyanagisawa. In particular, I think using Fire Functional Event is important to make sure the service worker keep-alive logic, etc, is handled properly. Bypassing that could result in the SW thread being kept alive too long which introduces privacy and abuse risks.

[domfarolino]

I'm not opposing this design due to a layering concern. I'm raising this because it just doesn't work. The stated intent of firing the functional event in the IDP's Service Worker is so that the IDP can "forward" the identity event's fetch request, but preserve the Sec-Fetch-Dest: webidentity header, so that the IDP's server knows it came form a legitimate UA-constructed webidentity request:

Its value is a browser-constructed {{Request}} object for the [=IDP=]
endpoint. The request has its [=request/destination=] set to "webidentity", which causes the [=user agent=] to set the [:Sec-Fetch-Dest:] [=forbidden request-header=] to webidentity. The
service worker can forward this request via {{WindowOrWorkerGlobalScope/fetch()|fetch(event.request)}} to preserve the header, which the
[=IDP=] server can use to verify the request originated from the FedCM API.

But this is just not how service workers work. FetchEvent.request.destination will indeed remain webidentity, and I believe the forbidden request headers like Sec-Fetch-Dest will exist, just not be exposed to script since they're sensitive. But when you call fetch() on that request, it immediately constructs a new DOM Request object from the original request, and this does NOT copy over the destination, which means when we go back through the whole network stack with this request Sec-Fetch-Dest will not be preserved. So the current design does not accomplish the stated goals.

(@npm1 raised a similar concern about webidentity in #815 (comment) / https://github.com/w3c-fedid/FedCM/pull/815/changes#r3053129839.)

[wanderview]

Yea, its similar to w3c/ServiceWorker#1803

[yoshisatoyanagisawa]

Since the fetch destination is limited and uncontrollable from the ServiceWorker script, I think this is the reasonable choice. We might need to ensure the allowed headers are safe to use. Also, I hope the security to review the API.

[domfarolino]

Going back to @yoshisatoyanagisawa's response above:

If the IDP can identify the requester is the Service Worker registered by the IDP, it is fine. However, without browser-enforced signals (like forbidden headers), an attacker can easily write attack code to pretend to be the Service Worker to cause CSRF.

The IDP can verify that the requestor is in the IDP's own origin (i.e., its own service worker) via forbidden headers, like Sec-Fetch-Site: same-origin. An attacker cannot write "attack code" to pretend to be the IDP's service worker when contacting the IDP's server, because it cannot forge this header. So here's how I envision it:

Fetches caught by the IDP's service worker would validate that the IdentityRequestEvent's request has a webidentity destination, that the RP could not forge. If the SW checks out the request and deems it "valid", then the SW sends a same-origin request to its own server to get the actual resource. The server checks that Sec-Fetch-Dest === same-origin to be sure that the attacker did not forge the request, and to confirm that it's talking to its own origin.

If there is no browser help to provide a non-forgeable identifier, it might not be so easy to maintain the existing security model.

So yeah, just to be clear I think the existing forbidden headers give us everything we'd need, without warping the processing model of service workers as a special case in this specification. The service worker processing model is how it is for a reason, and I think letting individual specs poke substantial holes in it for one-off use-cases is regrettable and should be avoided, especially when existing primitives line up to form an equivalent solution, which I think is the case here.

---

Also the whole augmented fetch thing doesn't make sense to me. The draft above references things like "§3.4 below" that don't exist, and definitions like "Allowlist headers section" that aren't filled out. @pottis please scrutinize your AI responses more thoroughly.

[pottis]

@domfarolino , I intentionally left out those points because I wanted to confirm the approach first. I understand your feedback and will make sure to include all relevant information to help reviewers in the future.

Regarding your comment, "Also the whole augmented fetch thing doesn't make sense to me"—could you please elaborate? There are some limitations with fetch(…) where certain properties get reset when it's called for which i am proposing this approach.

[domfarolino]

—could you please elaborate?

I don't know what "dpop proof" is, and I'm not sure how it fits into this proposal. What is the "augmented fetch" trying to accomplish? I'd appreciate an explanation to that before a long algorithm with incomplete definitions. For example: is the goal to preserve webidentity and Sec-Fetch-Dest from the request that the SW intercepted from the RP? If so, then why is any kind of "proof" / key / signature needed, if the existence of the forbidden header is enough? And if you're not trying to preserve webidentity and Sec-Fetch-Dest, then why do we need a special "augmented fetch" anyways, when you can just add your own (cryptographic) headers to the request that the SW forward onto its same-origin server?

[yoshisatoyanagisawa]

That makes sense. I initially thought a new fetch API was necessary for CSRF prevention, but if it can be reliably achieved using existing primitives like Sec-Fetch-Site: same-origin, I agree that we should avoid introducing a new API. Adding a non-normative note to guide developers on how to implement these server-side checks should be sufficient to address the CSRF concerns without adding complexity to the service worker model.

[hlflanagan]

Discussed during the 5 May 2026 meeting.

[yoshisatoyanagisawa]

Technically, arbitrary "Match Service Worker Registration" algorithm caller can look up the registration for FedCM if the storage key and origin matches. Is it intended? i.e. algorithm outside of the FedCM may use the registration or unregister it.

[domfarolino]

Yeah, I thought we were keeping a separate partition of FedCM-specific service workers so that we wouldn't collide with pre-existing service worker registrations, and so that other parts of the platform wouldn't collide with FedCM/IDP service workers.

[yoshisatoyanagisawa]

I am saying this because I thought FedCM ServiceWorker is intend to be isolated from the other ServiceWorkers by having its own mapping, but it looks not.

[pottis]

If I understand the concerns correctly,
a) Pre-existing IDP service workers (caching/push) are automatically enrolled into FedCM as soon as a listener is added.
b) FedCM service workers can be accessed and unregistered by any caller using Match Service Worker Registration.

To separate general functionality from FedCM-specific behavior, I'm considering adding a field to ServiceWorkerRegistration:
partial dictionary RegistrationOptions { boolean acceptsFedCM = false; };
partial interface ServiceWorkerRegistration { readonly attribute boolean acceptsFedCM; };

With this change, IDP authors would register their service worker as follows:
navigator.serviceWorker.register('/sw.js', { acceptsFedCM: true });

Please share your thoughts, or let me know if you have suggestions for a better approach to achieve isolation.
Note: The current specification prefers the IDP to register the service worker

[domfarolino]

You need a mechanism for this new kind of "acceptsFedCM" service worker to intercept webidentity requests; how would that work? When Fetch fetches webidentity requests, would it just pass a special "key" to https://w3c.github.io/ServiceWorker/#match-service-worker-registration, so that we only match "acceptsFedCM" service workers?

[yoshisatoyanagisawa]

@pottis I'm not convinced that adding this field fixes the issue. A proper fix might require ServiceWorkerRegistration to have a state explaining its owners (FedCM, Web, or both), but that involves updating the registration and control logic. I'd like to understand the clear rationale for opting for this complexity over simple isolation.

[domfarolino]

What would the alternative "simple isolation" look like to you @yoshisatoyanagisawa? When would Fetch know to trigger the "FedCM service worker" vs others, and how would we know which SW to fetch/install when doing all of this for FedCM?

[yoshisatoyanagisawa]

After discussing this directly with @pottis, I recognize that I had been operating under the assumption of a previous registration model and overlooked the fact that it had already changed in the current design.

Correcting for that understanding, I believe the API should follow the architectural pattern used by features like the Periodic Background Sync API or the Notification API.

Specifically, I suggest extending ServiceWorkerRegistration with a dedicated interface—for example, registration.identity (an IdentityProviderManager). To enable FedCM interception, developers would be required to explicitly call registration.identity.register(configURL). This creates a one-to-one mapping between the IDP Config URL and the registration, ensuring that functional events are only dispatched to workers that have intentionally opted-in to handle that specific provider. (configURL was used since configURL might be the unique identifier for IdentityProviderConfig.)

This approach addresses the semantic mismatch of using the implicit 'Match Service Worker Registration' algorithm for internal UA requests that lack a controlled client. It also provides a clear lifecycle for unlinking via unregister(configURL) or through the removal of the parent registration.

What are your thoughts on adopting this explicit registration model?

[TallTed]

Suggested change

	service worker can forward this request via {{WindowOrWorkerGlobalScope/fetch()|fetch(event.request)}} to preserve the header, which the
	[=IDP=] server can use to verify the request originated from the FedCM API.
	service worker can forward this request via {{WindowOrWorkerGlobalScope/fetch()|fetch(event.request)}}
	to preserve the header, which the [=IDP=] server can use to verify whether the request
	originated from the FedCM API.

[yoshisatoyanagisawa]

nit but is it possible for the JavaScript object to have the field like this? (this is something like how to write standard, and not important for the way to implement this.)

In the past, I might have implemented the corresponding structure to deal with the situation like: https://urlpattern.spec.whatwg.org/#urlpattern-associated-url-pattern
However, I hope whom knows web standard will take another look.

[domfarolino]

Can you clarify the concern you have @yoshisatoyanagisawa

[yoshisatoyanagisawa]

I thought we need a corresponding data structure to have a hidden field for the web exposed structure, and I thought we need the corresponding data structure for IdentityRequestEvent to have hidden fields while we do not provide the mapping from the Web exposed to the internal structure if we want the field hidden.
However, if we do not need such a complicated logic to realize the hidden field, it should be fine.

[domfarolino]

Got it. The way this PR does it and the way that URLPattern does it is basically the same. Objects, including IDL objects, can have two types of "things":

1. They can have "internal" members, which are denoted in spec prose by either [[InternalSlots]], "associated" structures like you do with URLPattern, or just ordinary non-IDL "members", like https://dom.spec.whatwg.org/#abortsignal-abort-algorithms;
2. They can have IDL attributes and methods, which are web-exposed.

Both URLPattern and this spec are doing (1) here, and they're the same.

[yoshisatoyanagisawa]

ok, then let me withdraw my comment. This looks following https://dom.spec.whatwg.org/#abortsignal-dependent style.

[yoshisatoyanagisawa]

to be clear, "service worker script" instead of "service worker", right?
"service worker" sounds like that the Service Worker core logic uses this for decision making.

[pottis]

Thank you for pointing that out. I had been using SW and the SW script interchangeably, but I'll make sure to clarify the distinction moving forward.

[yoshisatoyanagisawa]

We may want to revise this because the fetch from the Service Worker script won't preserve the sec-fetch-destination header. I understand that the dedicated method will be provided for the purpose instead.

[pottis]

Sure. Seems @domfarolino still not aligned on fetchAuguement on its purpose, once i add proposal API to spec, will update the wording.

[domfarolino]

Given #815 (comment) it looks like we're all aligned that "augmented fetch" and preserving Sec-Fetch-Destination is not a key part of this proposal, and is probably not needed.

[yoshisatoyanagisawa]

Yeah, upon the discussion, I understand we agreed not to provide the additional fetch method. We just leave the developer note to ask them to check sec-fetch-site instead.
Anyway, the phrase should be updated because sec-fetch-dest won't be available.

[yoshisatoyanagisawa]

If other reviewers requested, it should be fine. However, I failed to catch why these flags should be set because events might not be propagated to anybody else.

[pottis]

@domfarolino requested to capture the steps.

[domfarolino]

This is because the following should throw:

self.onidentityevent = e => {
  e.respondWith(foo);
  e.respondWith(bar); // throws, since respondWith() was already called!
};

To match how FetchEvent works in service workers already: https://w3c.github.io/ServiceWorker/#ref-for-fetchevent-respond-with-entered-flag.

[yoshisatoyanagisawa]

Thank you for the reply, I checked https://w3c.github.io/ServiceWorker/#fetch-event-respondwith Step 5, and it looks doing something similar.
Then, it is fine to leave as-is.

[yoshisatoyanagisawa]

nit but since |credential| was set to null in L1616, the step may not wait anything. You might want to wait here while |credential| is null?

e.g. I saw ServiceWorker has yet another flag to tell the finish condition or watching a specific field like: https://w3c.github.io/ServiceWorker/#run-service-worker-algorithm

[yoshisatoyanagisawa]

nit but might be good to mark |result| unset or something non null, then it might be easy for the latter step to recognize the value is set.

[yoshisatoyanagisawa]

may want to return in addition

[yoshisatoyanagisawa]

For the failed case, the PR seems to treat it as the failure. Is it really intended?

cf. For the Service Worker Handle Fetch algorithm, it may return the network error, and the fetch specification will trigger the network fallback for the case instead of showing the error page. Therefore, broken ServiceWorker script would just bring the network fallback instead of complete service stop.

[yoshisatoyanagisawa]

You may want to add a note for the service worker case.

[yoshisatoyanagisawa]

You might need to update this because it actually cannot forward the sec-fetch-dest header.

[yoshisatoyanagisawa]

I thought the FedCM's ServiceWorker is isolated from the regular web ServiceWorkers, but it looks not?

[pottis]

replied in this comment : #815 (comment)

[domfarolino]

Hey @pottis, thanks for working on this and pouring so much effort into it, however I think we should step back a little bit and discuss some things at a higher-level. This PR is close to 400 lines long and we're 300 comments deep, and @samuelgoto and I are noticing that there's no OP¹, no explainer, no written design requirements, and the farther we go down a few rabbit holes, the more deep design alterations get proposed.

I think we're all quite motivated to help unblock major partners adopting the FedCM specification, but fundamentally this deep into a pull request is not the best place for us to have such deep design discussions, which is why threads like #815 (comment) are getting a unruly and hard to resolve.

We think it'd be best to step back a bit and try and draft an explainer for this work. This can probably be a distillation of the parts of #80 that stuck, as well as discussion of how this relates to #787, and what resolutions if any came out of previous WG meetings about this feature (since I got pulled into all of this outside and after all of the meetings, as far as I can tell). I'm happy to help out with the explainer too.

Footnotes

1. As of yesterday there was no OP. Apparently one has been written in the past 24 hours, but claims like "This feature unlocks advanced security and operational patterns that were previously impossible in the FedCM ecosystem." need more elaboration and discussion, among some others. ↩

[hlflanagan]

This has been added to the agenda for Tuesday, 19 May 2026. From the email to the lists:

PR #815 proposes a mechanism that would allow Identity Providers to handle certain FedCM requests using a Service Worker-based mechanism. The motivating use cases include request signing / proof-of-possession patterns such as DPoP, operational failover, geographic or jurisdiction-specific routing, caching during outages, and integration with legacy identity systems. The discussion has raised detailed questions across FedCM request processing, Service Worker dispatch, Fetch semantics, privacy, and IDP security expectations. Some of the detailed review appears to depend on higher-level direction from the WG. For example, we should clarify what privacy and security properties need to be accounted for in the IdP Interception proposal. If a FedCM request is handled by an IDP-controlled Service Worker rather than sent directly by the browser, what properties must remain true? For example, what may the handler learn compared with the current browser-direct request path? Is fallback to the ordinary network path always acceptable, or are there cases where the IDP must be able to fail closed?

Speaking as chair, I would like to separate those direction-setting questions from line-by-line spec review. I am not taking a position on the proposal, but I would like to make sure the CG and WG has a shared understanding of the problem and the boundaries so we can make an explicit decision on what needs to be in the PR.