Need inputs and feedback on Service Worker Interception in Browser Process

[suresh potti]

Hey folks,

In the current FedCM implementation, all network requests are initiated within the browser process, which prevents them from being intercepted by the Service Worker. We have recently received a request to enable Service Worker interception for a subset of these calls, specifically for the /token, /accounts, and /disconnect endpoints.
I would appreciate your input and feedback on the proposed design choice.
Doc:https://docs.google.com/document/d/1BwqnN_dsOCU9styAN5k1TwKHDWKFcNOQt_pOLgA3zQQ/edit?tab=t.0
CL:https://chromium-review.googlesource.com/c/chromium/src/+/7206662

Thanks,
Suresh

[Ben Kelly]

Can you describe how this would be handled in spec language?

These seem like subresource requests, but normally service workers are scoped to non-subresource requests representing controlled environments.  What is the controlled environment for these intercepted requests?  The intercepted fetch events need to reference a client or reserved_client... What is used in these cases?

--
You received this message because you are subscribed to the Google Groups "service-worker-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to service-worker-di...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/service-worker-discuss/e35b42ee-0300-47b5-8534-543a4df4419fn%40chromium.org.

[Ben Kelly]

Right, this is like a limited form of "foreign fetch" which was previously considered by service workers: https://developer.chrome.com/blog/foreign-fetch

On Fri, Jan 9, 2026 at 10:35 AM Dominic Farolino <domfa...@google.com> wrote:

The first thing that worries me is the assumption that the identity assertion request (/tokens, in your doc) should be eligible for IDP service worker interception. The request has a null client practically as an implementation detail, but to make its web-exposed privacy/security characteristics the same as ordinary requests fetched by the RP, it's origin is the RP's origin, and the mode is explicitly CORS. So this is a cross-origin CORS request from the RP to the IDP. Generally a request from A.com to B.com is only interceptible by A.com's service workers, as I understand, but in this case you're making it eligible for interception by B.com's (IDP's) service worker, which seems bad. Maybe I'm missing some critical context on why this is OK, but since the origin and request mode were very carefully selected, this smells like a SOP violation.

(In your CL's `fedcm_service_worker_url_loader_factory.cc`, this appears to be done in FedCmServiceWorkerURLLoaderFactory::CreateLoaderAndStart(), which immediately generates a storage key for SW look-up based on the request's destination URL, not its origin.

On Thu, Jan 8, 2026 at 5:43 PM Nicolás Peña Moreno <n...@google.com> wrote:

We currently set the client to null, which likely won't work for service workers. +Dominic Farolino, any thoughts on how we could address this? I remember we previously discussed how the client should be set for FedCM requests.

[suresh potti]

Controlled Environment: The IDP's origin (e.g., https://idp.example), not the RP's origin. The request is sent to the IDP's endpoint, so the IDP's Service Worker intercepts it.

Client References passed in ServiceWorkerFetchDispatcher:
clientId: References the RP document's client UUID (currently passed as empty string in implementation)
resultingClientId: null (not creating a new client—these are subresource requests)

Note: The RP page doesn't need SW registration. Only the IDP origin needs an active Service Worker to intercept these requests.

[suresh potti]

This is not a SOP violation—it's the correct behavior.

The confusion stems from the request's initiator vs destination:
Request initiator: Set to RP origin (rp.com) for browser CORS enforcement
Request destination: IDP endpoint (https://idp.example/token)
Service Worker routing: Based on destination URL, not initiator

Why this is correct:
1. Service Workers intercept requests sent to their origin, regardless of who initiated them
2. A fetch to https://idp.example/token should be intercepted by idp.example's SW, not rp.com's SW
3. This is standard SW behavior—same as cross-origin iframe or image requests

The CORS mode and RP origin are for browser-level security (CORS preflight, credential handling), not SW routing. The storage key is correctly generated from request.url (destination), ensuring the IDP's SW intercepts requests to IDP endpoints.

[Dominic Farolino]

The response I wrote to the second message in this thread apparently didn't make it in, because my corp account isn't part of this "group". I'll re-post it below, since Suresh is responding to it above (and it's confusing since he's responding to my message that didn't show up publicly).

------

The first thing that worries me is the assumption that the identity assertion request (/tokens, in your doc) should be eligible for IDP service worker interception. The request has a null client practically as an implementation detail, but to make its web-exposed privacy/security characteristics the same as ordinary requests fetched by the RP, it's origin is the RP's origin, and the mode is explicitly CORS. So this is a cross-origin CORS request from the RP to the IDP. Generally a request from A.com to B.com is only interceptible by A.com's service workers, as I understand, but in this case you're making it eligible for interception by B.com's (IDP's) service worker, which seems bad. Maybe I'm missing some critical context on why this is OK, but since the origin and request mode were very carefully selected, this smells like a SOP violation.

(In your CL's `fedcm_service_worker_url_loader_factory.cc`, this appears to be done in FedCmServiceWorkerURLLoaderFactory::CreateLoaderAndStart(), which immediately generates a storage key for SW look-up based on the request's destination URL, not its origin.

------

[Dominic Farolino]

The confusion stems from the request's initiator vs destination:
Request initiator: Set to RP origin (rp.com) for browser CORS enforcement
Request destination: IDP endpoint (https://idp.example/token)
Service Worker routing: Based on destination URL, not initiator

Sure, the way you wrote the code, the service worker interception is based on the destination URL, not the initiator. I'm saying that this is novel behavior (besides foreign fetch which no longer exists), and is NOT how service workers function today.

Why this is correct:
1. Service Workers intercept requests sent to their origin, regardless of who initiated them
2. A fetch to https://idp.example/token should be intercepted by idp.example's SW, not rp.com's SW
3. This is standard SW behavior—same as cross-origin iframe or image requests

I think everything in this list is wrong. 

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/service-worker-discuss/3d0e6149-8bdf-490d-a9e2-fb85f76db7can%40chromium.org.

[Ben Kelly]

On Mon, Jan 12, 2026 at 5:11 AM 'suresh potti' via service-worker-discuss <service-wor...@chromium.org> wrote:

This is not a SOP violation—it's the correct behavior.

The confusion stems from the request's initiator vs destination:
Request initiator: Set to RP origin (rp.com) for browser CORS enforcement
Request destination: IDP endpoint (https://idp.example/token)
Service Worker routing: Based on destination URL, not initiator

Why this is correct:
1. Service Workers intercept requests sent to their origin, regardless of who initiated them
2. A fetch to https://idp.example/token should be intercepted by idp.example's SW, not rp.com's SW
3. This is standard SW behavior—same as cross-origin iframe or image requests

This statement is not correct.  It's only true for non-subresource requests (documents, top level worker scripts).  Subresource requests are always intercepted by the service worker controlling the client that initiated the subresource request.  So for a cross-origin image request, then the service worker is also cross-origin to the image request.

 

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/service-worker-discuss/3f3128ea-032f-4039-8a3e-b96a6dc6278en%40chromium.org.

[Christian Biesinger]

Just to make sure we are on the same page, today FedCM requests do not get intercepted by any service worker (in particular, not by A.com's service worker) for privacy reasons -- an IDP should not know both the relying party and user credentials at the same time before the user gave permission.

In the spec, we accomplish this by setting service-workers mode to "none" (https://fetch.spec.whatwg.org/#request-service-workers-mode)

I believe payments also has a special service worker that it can trigger outside of regular web semantics (https://developer.mozilla.org/en-US/docs/Web/API/Payment_Handler_API#:~:text=Just%2DIn%2DTime%20(JIT)%20install%20the%20web%20app%20if%20necessary%2C%20registering%20the%20service%20worker) although their semantics are different from what we are proposing.

Christian

On Mon, Jan 12, 2026 at 11:21 AM Dominic Farolino <d...@chromium.org> wrote:

[Christian Biesinger]

Dom: Can you elaborate on the SOP concern? You are thinking of something like, origin A triggers the ID assertion request with some data, then origin B later makes such a request and retrieves that data?

Considering that:

a) these requests are credentialed

b) this requires IDP cooperation because it would be a servicer worker registered by the IDP

this is not really an issue, since the IDP could just return this data from the regular HTTPS request without a service worker. Also note that ID assertion requests are only made after user confirmation.

Does that sound reasonable?

Thanks,

Christian

[Dominic Farolino]

I understood that foreign fetch was ripped out in part because of security, hence my SOP concern. I could be wrong, it was before my time. One reason it got removed was due to keying complexity. If two sites A.com and B.com both make requests for Destination.com, in a double-key-cached world we'd need to store and execute two different Destination.com service workers: one under A.com's partition, and one under B.com's. See https://github.com/w3c/ServiceWorker/issues/1188.

The proposal here worries me because we're explicitly undoing any natural partitioning the keying would do, by always manufacturing a first-party storage key for SW look-up. The identity assertion request is a legitimate cross-origin request (impl), so why should it access anything behind a first-party key? I think it'd make more sense if the ID assertion request was just a genuine same-origin request to the IDP—but then I guess the IDP couldn't identify the RP from the request, is that bad?

a) these requests are credentialed

How true is this? The request is cross-origin, so it doesn't send any first-party cookies, right? I think it'd only send IDP cookies that are partitioned under the RP's storage partition. Either way, how is that relevant for first-party service worker lookup?

this is not really an issue, since the IDP could just return this data from the regular HTTPS request without a service worker. Also note that ID assertion requests are only made after user confirmation.

Very true. Anne pointed out on Matrix that now though, the IDP's service worker could execute script and access first-party storage when another origin makes this request to the IDP, which is novel. All of these cross-origin requests would end up in the same service worker, which might have privacy implications.

I honestly don't feel strongly about any of this, it's just a very peculiar carve-out that feels super special-case-y. Spec-wise though, I think you'd need to give the request a proper "client" to match a service worker, I think, because of how https://html.spec.whatwg.org/multipage/webappapis.html#concept-environment-active-service-worker is used in https://fetch.spec.whatwg.org/#ref-for-handle-fetch%E2%91%A0.

[suresh potti]

Question 1: Foreign Fetch Comparison & Storage Key Partitioning

Key Difference from Foreign Fetch:
Foreign Fetch allowed any third-party SW to intercept any cross-origin request. FedCM is fundamentally different:

User-mediated: Requests only happen after explicit user consent via browser UI
Limited scope: Only 3 specific endpoints (/accounts, /token, /disconnect)
IDP controls: The IDP's own SW handles requests to its own endpoints
Not arbitrary third-party interception: This isn't cdn.example intercepting requests from a.com and b.com.

Why First-Party Storage Key is Correct:

// This creates storage key from the DESTINATION (IDP's origin)

blink::StorageKey storage_key =

    blink::StorageKey::CreateFirstParty(url::Origin::Create(request.url));

The IDP's SW should access the IDP's own first-party storage because:
It's the IDP's endpoint - https://idp.example/token belongs to idp.example
IDP serves all RPs from single SW - One SW instance handles token requests for all RPs (similar to OAuth servers)

However, if security is the primary concern, then alternative approach is to implement partitioning, ensuring that SW instances are not shared.

Question 2: "Credentialed" Requests & Cookie Behavior

bool is_cross_origin = !net::registry_controlled_domains::SameDomainOrHost(

    relying_party_origin_, target_origin, ...);

if (IsFedCmServiceWorkerInterceptionEnabled() && is_cross_origin) {

  // Cross-origin: Use kOther with empty SiteForCookies

  resource_request->site_for_cookies = net::SiteForCookies();  // Empty

  // This BLOCKS SameSite=Strict/Lax cookies

}

Current Cookie State

• No first-party IDP cookies sent (SiteForCookies is empty)
• No RP cookies sent (different origin)
• Only SameSite=None cookies sent (if any)

Why "Credentialed":
The term refers to credentials_mode: kInclude, meaning the browser attempts to send cookies, but SameSite enforcement blocks most.

The relevant part for SW lookup is:
SW lookup uses first-party key regardless of cookie state because:

• SW routing is based on request destination, not cookie partitioning
• The IDP's SW should see all token requests to maintain session state/cache
• Cookie partitioning and SW partitioning serve different purposes

Question 3: Privacy Implications - IDP SW Accessing First-Party Storage

IDP’s Service Worker can:

• Execute JavaScript when the RP makes requests
• Access the IDP’s first-party storage
• Observe all requests from different RPs within a single SW instance

Why This Is Acceptable:

• No Additional Privacy Exposure: The IDP already has this capability through direct network requests. The Service Worker simply acts as an optimization layer.
• User Consent Is Required: Every FedCM request involves:
  • A browser-mediated permission prompt
  • The user explicitly selecting the IDP and account
  • Clear visibility of which RP is requesting access
• IDP Already Identifies RP: The request body includes client_id (RP identifier), so the IDP server already knows which RP initiated the request—the SW only sees the same data.
• Consistent With OAuth/OIDC Practices: Traditional OAuth servers maintain single-origin storage across all RPs for token caching, session management, and rate limiting.

Spec Compliance – “Client” Requirement

To align with the specification, the request must include a valid client to correspond with a service worker.

Current Behavior:
We currently pass empty client_id and resulting_client_id to ServiceWorkerFetchDispatcher.

Spec-Compliant Approach:
Instead, provide the RP’s client UUID as client_id to ensure proper compliance.

[Christian Biesinger]

On Thu, Jan 15, 2026 at 8:05 PM Dominic Farolino <d...@chromium.org> wrote:

I understood that foreign fetch was ripped out in part because of security, hence my SOP concern. I could be wrong, it was before my time. One reason it got removed was due to keying complexity. If two sites A.com and B.com both make requests for Destination.com, in a double-key-cached world we'd need to store and execute two different Destination.com service workers: one under A.com's partition, and one under B.com's. See https://github.com/w3c/ServiceWorker/issues/1188.

The proposal here worries me because we're explicitly undoing any natural partitioning the keying would do, by always manufacturing a first-party storage key for SW look-up. The identity assertion request is a legitimate cross-origin request (impl), so why should it access anything behind a first-party key? I think it'd make more sense if the ID assertion request was just a genuine same-origin request to the IDP—but then I guess the IDP couldn't identify the RP from the request, is that bad?

The IDP needs to know the RP's origin and client ID. It is not that important whether the RP origin is sent in the Origin header vs elsewhere though. (Of course, at this point, there are compat concerns if we were to change this)

Additionally, there was opposition to sending SameSite=Strict cookies for this request, which would happen if it were a same-origin request.

 

a) these requests are credentialed

How true is this? The request is cross-origin, so it doesn't send any first-party cookies, right? I think it'd only send IDP cookies that are partitioned under the RP's storage partition. Either way, how is that relevant for first-party service worker lookup?

This is tricky to spec correctly in a world where third-party cookies are disabled, I don't believe there is a way to say "send unpartitioned SameSite=None/Lax cookies for these requests". That was the intent here and is what Chrome implements.

 

this is not really an issue, since the IDP could just return this data from the regular HTTPS request without a service worker. Also note that ID assertion requests are only made after user confirmation.

Very true. Anne pointed out on Matrix that now though, the IDP's service worker could execute script and access first-party storage when another origin makes this request to the IDP, which is novel. All of these cross-origin requests would end up in the same service worker, which might have privacy implications.

Yes, I'm sure that's correct, but from a privacy perspective it seems like if you have unpartitioned cookies, even if limited to SameSite=None, this is no worse?

(BTW, was this a public matrix channel? Is that a place I should/could join?)

 

I honestly don't feel strongly about any of this, it's just a very peculiar carve-out that feels super special-case-y. Spec-wise though, I think you'd need to give the request a proper "client" to match a service worker, I think, because of how https://html.spec.whatwg.org/multipage/webappapis.html#concept-environment-active-service-worker is used in https://fetch.spec.whatwg.org/#ref-for-handle-fetch%E2%91%A0.

Hm, maybe my comment in https://github.com/w3c-fedid/FedCM/pull/787#issuecomment-3755636126 was wrong, I think what you are saying is that if the client is set up correctly then we would only trigger the IDP's service worker?

Thanks,

Christian 

[Ben Kelly]

On Fri, Jan 16, 2026 at 4:24 AM 'suresh potti' via service-worker-discuss <service-wor...@chromium.org> wrote:

Question 3: Privacy Implications - IDP SW Accessing First-Party Storage

IDP’s Service Worker can:

• Execute JavaScript when the RP makes requests
• Access the IDP’s first-party storage
• Observe all requests from different RPs within a single SW instance

Spec-Compliant Approach:

Instead, provide the RP’s client UUID as client_id to ensure proper compliance.

You are suggesting to use the IDP origin's service worker, but say its controlling an RP origin's client?  This would be very strange and nothing like what service worker currently does.

Regarding the questions about foreign fetch and SOP violations:

Foreign fetch did not violate SOP, but it did strongly break "block or partition 3P cookies" semantics.  Foreign fetch type behavior was like unpartitioned 3P cookies that also let the 3P run javascript potentially in the background.

It seems like this proposal has the same issue?  Do we give FedCM an exception on 3P cookie blocking/partitioning without the service worker involved?  If so, then I guess this kind of makes sense, but it needs a new spec definition as it's not something done currently.

 

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/service-worker-discuss/8a185d05-7815-46f5-a5e0-b3752b12a9f0n%40chromium.org.

[Christian Biesinger]

On Fri, Jan 16, 2026 at 2:20 PM Ben Kelly <wande...@chromium.org> wrote:

On Fri, Jan 16, 2026 at 4:24 AM 'suresh potti' via service-worker-discuss <service-wor...@chromium.org> wrote:

Question 3: Privacy Implications - IDP SW Accessing First-Party Storage

IDP’s Service Worker can:

• Execute JavaScript when the RP makes requests
• Access the IDP’s first-party storage
• Observe all requests from different RPs within a single SW instance

Spec-Compliant Approach:
Instead, provide the RP’s client UUID as client_id to ensure proper compliance.

You are suggesting to use the IDP origin's service worker, but say its controlling an RP origin's client?  This would be very strange and nothing like what service worker currently does.

Regarding the questions about foreign fetch and SOP violations:

Foreign fetch did not violate SOP, but it did strongly break "block or partition 3P cookies" semantics.  Foreign fetch type behavior was like unpartitioned 3P cookies that also let the 3P run javascript potentially in the background.

It seems like this proposal has the same issue?  Do we give FedCM an exception on 3P cookie blocking/partitioning without the service worker involved?  If so, then I guess this kind of makes sense, but it needs a new spec definition as it's not something done currently.

 

Yes, FedCM effectively has an exception from 3p cookie blocking.

Christian

[suresh potti]

It seems like this proposal has the same issue?  Do we give FedCM an exception on 3P cookie blocking/partitioning without the service worker involved?  If so, then I guess this kind of makes sense, but it needs a new spec definition as it's not something done currently.

Would introducing a new specification definition be sufficient to justify the design choices made for   FedCM Service Worker Interception - Google Docs  ? Additionally, should these amendments be incorporated into the Fetch spec or the Service Worker spec?