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?

[Dominic Farolino]

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

Is there a spec bug filed for this? It seems pretty bad if Chromium and the spec significantly differ here.

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?j

Probably. That sounds reasonable to me. It's a shame the spec does not use unpartitioned cookies though? Maybe we need to piggy-back on some kind of requestStorageAccess infra? Not sure.

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

Check out https://whatwg.org/chat. It's the public WHATWG chat. 

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?

I'm saying what Ben said above. By default, the RP's SW gets triggered, unless extensive spec gymnastics are made to warp the request into one that's simultaneously cross-origin (fetched from the RP's origin) and finds the IDP's (target origin's) SW. I added a little bit more in https://github.com/w3c-fedid/FedCM/pull/787#issuecomment-3770036628.

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?

See my above comment on the spec. It would be good to read all of the relevant spec algorithms, and add a spec design section to the design document. But I think we really don't want to make this decision in a vacuum. I strongly suggest getting feedback on this from Chrome platform Privacy/Security folks, other browsers, and probably the TAG. I am happy to help review any public summaries of the feature / requests for comment.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/service-worker-discuss/4db26385-84ba-4dce-8f55-c78701647671n%40chromium.org.

[Yoshisato Yanagisawa]

Hi folks,

I apologize for the late response, as this thread has been quiet for nearly a month. However, the topic recently came up during our Service Worker editors' weekly sync, and I wanted to share my current perspective.

I should also clarify that when the FedCM team consulted me internally on this issue, I initially stated that I didn't see any serious concerns. At that time, I hadn't fully realized the proposal involved reusing the existing fetch handler for these specific requests. It was only after reading Ben Kelly's questions that I recognized the potential architectural issues I had overlooked. I apologize for not catching this sooner, and I’d like to provide my updated opinion on this point.

Having revisited the proposal and the concerns raised about partitioning and potential SOP violations, I believe we should carefully consider whether forcing this integration into the existing fetch handler is the right path. Manufacturing a first-party storage key for cross-origin requests — even if constrained — would likely require a "rigorous privacy and security review" and risks introducing behavior that "smells like a SOP violation".

From a Service Worker architecture standpoint, I’m concerned that the disadvantages of using the fetch handler for this use case may outweigh the benefits:

• Complexity and Misalignment: The fetch handler has a well-established philosophy. Attempting to warp it to handle these specific browser-initiated, cross-origin requests results in "spec gymnastics" that makes long-term maintainability more difficult.
• Developer Confusion: Reusing the existing handler requires developers to manually distinguish FedCM-intercepted requests from ordinary fetches. I share the concern that these "minor differences could lead to confusion among developers".
• A Dedicated Entry Point: A "separated entry point for this specific use case seems preferable". Introducing a dedicated functional event — similar to how the Payment Handler API functions — would likely be the "path of least resistance".

Ultimately, I believe providing a clear, explicit interface for FedCM is better for long-term maintainability than performing "spec gymnastics" to warp the fetch algorithm. Moreover, I suggest using the "Fire Functional Event" algorithm, as the Payment Handler API does.

Best regards,

Yoshisato

On Tuesday, January 20, 2026 at 11:03:07 PM UTC+9 Dominic Farolino wrote:

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

Is there a spec bug filed for this? It seems pretty bad if Chromium and the spec significantly differ here.

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?j

Probably. That sounds reasonable to me. It's a shame the spec does not use unpartitioned cookies though? Maybe we need to piggy-back on some kind of requestStorageAccess infra? Not sure.

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

Check out https://whatwg.org/chat. It's the public WHATWG chat. 

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?

I'm saying what Ben said above. By default, the RP's SW gets triggered, unless extensive spec gymnastics are made to warp the request into one that's simultaneously cross-origin (fetched from the RP's origin) and finds the IDP's (target origin's) SW. I added a little bit more in https://github.com/w3c-fedid/FedCM/pull/787#issuecomment-3770036628.

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?

See my above comment on the spec. It would be good to read all of the relevant spec algorithms, and add a spec design section to the design document. But I think we really don't want to make this decision in a vacuum. I strongly suggest getting feedback on this from Chrome platform Privacy/Security folks, other browsers, and probably the TAG. I am happy to help review any public summaries of the feature / requests for comment.

To unsubscribe from this group and stop receiving emails from it, send an email to service-worker-discuss+unsub...@chromium.org.

[suresh potti]

Hi,

I've incorporated your feedback and created alternative approaches, including the PaymentHandler API (Approach B).

Could you review Approaches B and C and let me know your thoughts as well as the suggested next steps?
Link: Enabling IDP Interception in FedCM Request - Extended - Google Docs

Thanks,
Suresh
   

On Wednesday, February 18, 2026 at 9:01:01 AM UTC+5:30 yyana...@chromium.org wrote:

Hi folks,

I apologize for the late response, as this thread has been quiet for nearly a month. However, the topic recently came up during our Service Worker editors' weekly sync, and I wanted to share my current perspective.

I should also clarify that when the FedCM team consulted me internally on this issue, I initially stated that I didn't see any serious concerns. At that time, I hadn't fully realized the proposal involved reusing the existing fetch handler for these specific requests. It was only after reading Ben Kelly's questions that I recognized the potential architectural issues I had overlooked. I apologize for not catching this sooner, and I’d like to provide my updated opinion on this point.

Having revisited the proposal and the concerns raised about partitioning and potential SOP violations, I believe we should carefully consider whether forcing this integration into the existing fetch handler is the right path. Manufacturing a first-party storage key for cross-origin requests — even if constrained — would likely require a "rigorous privacy and security review" and risks introducing behavior that "smells like a SOP violation".

From a Service Worker architecture standpoint, I’m concerned that the disadvantages of using the fetch handler for this use case may outweigh the benefits:

• Complexity and Misalignment: The fetch handler has a well-established philosophy. Attempting to warp it to handle these specific browser-initiated, cross-origin requests results in "spec gymnastics" that makes long-term maintainability more difficult.
• Developer Confusion: Reusing the existing handler requires developers to manually distinguish FedCM-intercepted requests from ordinary fetches. I share the concern that these "minor differences could lead to confusion among developers".
• A Dedicated Entry Point: A "separated entry point for this specific use case seems preferable". Introducing a dedicated functional event — similar to how the Payment Handler API functions — would likely be the "path of least resistance".

Ultimately, I believe providing a clear, explicit interface for FedCM is better for long-term maintainability than performing "spec gymnastics" to warp the fetch algorithm. Moreover, I suggest using the "Fire Functional Event" algorithm, as the Payment Handler API does.

Best regards,

Yoshisato

On Tuesday, January 20, 2026 at 11:03:07 PM UTC+9 Dominic Farolino wrote:

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

Is there a spec bug filed for this? It seems pretty bad if Chromium and the spec significantly differ here.

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?j

Probably. That sounds reasonable to me. It's a shame the spec does not use unpartitioned cookies though? Maybe we need to piggy-back on some kind of requestStorageAccess infra? Not sure.

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

Check out https://whatwg.org/chat. It's the public WHATWG chat. 

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?

I'm saying what Ben said above. By default, the RP's SW gets triggered, unless extensive spec gymnastics are made to warp the request into one that's simultaneously cross-origin (fetched from the RP's origin) and finds the IDP's (target origin's) SW. I added a little bit more in https://github.com/w3c-fedid/FedCM/pull/787#issuecomment-3770036628.

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?

See my above comment on the spec. It would be good to read all of the relevant spec algorithms, and add a spec design section to the design document. But I think we really don't want to make this decision in a vacuum. I strongly suggest getting feedback on this from Chrome platform Privacy/Security folks, other browsers, and probably the TAG. I am happy to help review any public summaries of the feature / requests for comment.

[Yoshisato Yanagisawa]

Hi Suresh,

Thank you for sharing the updated draft and the new approaches.

As my recommendation was to follow the Payment Handler model, I focused my review on Approach B and left comments there. Unfortunately, I feel it doesn't fully utilize the "Fire Functional Event" algorithm that I had suggested. I still believe using the "Fire Functional Event" as the boundary is the best way to ensure a clear separation of responsibilities between the specifications.

Best regards,
Yoshisato

2026年2月26日(木) 13:19 'suresh potti' via service-worker-discuss <service-wor...@chromium.org>:

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/service-worker-discuss/8ae1cd48-971f-4bac-8834-d19b41355cdcn%40chromium.org.