Update service-workers mode to all for credentialed requests

[will-bartlett]

Resolves #80 . Service workers enable powerful customizations for the identity provider (IdP). They must be restricted to the credentialed endpoints to maintain FedCM's privacy posture.

---

Preview | Diff

[cbiesinger]

Could you send the whitespace removal as a separate PR so that it's easier to see what is being changed here?

[TallTed]

@cbiesinger — GitHub provides a handy "hide whitespace changes" option. It reveals that the text of three lines was changed.

[will-bartlett]

Yeah, I can clean it if needed. I just have my editor set to "trim trailing whitespace"

[will-bartlett]

Now whitespace change free

[npm1]

Thanks Will! This PR needs more discussion before we merge it (from my side, I have started a thread with privacy)

[will-bartlett]

@npm1 sounds good, let me know how that goes

[EmLauber]

@npm1 any updates on the privacy discussion?

[npm1]

The reviewer asked some clarifications just this morning so I don't yet have an answer.

[pottis]

With proposed changes, spec still requires additional refinements to fully support the service worker flow.

Core Algorithm Changes

• "Create an IdentityCredential" section : Detect service worker context and skip all UI steps, allowing only auto-reauthentication with mediation: "silent" required

Connected Accounts Set

• "compute the connected account key": When in service worker context, use worker origin as both RP and embedder origin (no separate top-level frame)
• "create a connection between RP and IdP": Same origin logic modification - SW origin serves dual purpose as RP and embedder

Validation & Restrictions

• Mediation requirement check: Reject immediately with (failure, true) if service worker attempts FedCM without mediation: "silent"
• New "Service Worker Limitations" section: Document that no UI dialogs (account selection, permissions, continuation) are allowed in service worker contexts

Network Requests

• Network isolation documentation: Add notes that service worker requests use worker origin as top_frame_origin with target IDP as frame_origin, maintaining Sec-Fetch-Dest: webidentity header

Security & Privacy

• "Service Worker Security" section: Explain that no new tracking vectors exist since SWs require prior document-based user consent via connected accounts set

Documentation

• Service worker example code: Show navigator.credentials.get() call from SW with mediation: "silent" and error handling for missing consent
• IDP endpoint notes: Add service worker behavior notes to accounts, assertion, and disconnect endpoint documentation sections

Definitions & Concepts

• Auto-reauthentication path: Clarify this is the ONLY execution path available for service workers (all other paths return immediate failure)
• Global object type detection: Add logic to check if |globalObject| is ServiceWorkerGlobalScope vs Window throughout algorithms

[will-bartlett]

@pottis none of those changes are proposed. Where did all that come from?

I think you may have fundamentally misunderstood this PR. This PR allows the Identity Provider to set a service worker. This is the normal way fetch works - it is the origin of destination of the fetch request whose service worker is run as part of fetch. It is also not the intention that service workers require silent / no UI modes.

Your comments seem to relate to how a Relying Party could use install a service worker to invoke and or customize FedCM. That's a wholly separate topic.

[will-bartlett]

I will add an explanatory note here, to make this more clear.

[npm1]

Expanding security/privacy does seem applicable, but I agree that this doesnt introduce new UI or autosignin considerations

[cbiesinger]

This change is incorrect. It would let the RP's service worker intercept the requests, which is not what we want.

[cbiesinger]

@pottis none of those changes are proposed. Where did all that come from?

I think you may have fundamentally misunderstood this PR. This PR allows the Identity Provider to set a service worker. This is the normal way fetch works - it is the origin of destination of the fetch request whose service worker is run as part of fetch. It is also not the intention that service workers require silent / no UI modes.

Your comments seem to relate to how a Relying Party could use install a service worker to invoke and or customize FedCM. That's a wholly separate topic.

I understand that this is your intention but that is not what the PR does, because that's not how service workers normally work.

Because this is not how service workers normally work, this may require a monkey patch to the service worker spec, or perhaps describing more informally how this is supposed to work...

Essentially, this is a form of https://developer.chrome.com/blog/foreign-fetch

CC @domfarolino

[will-bartlett]

I understand that this is your intention but that is not what the PR does, because that's not how service workers normally work.

Thanks. You are right. @EmLauber fyi. I think I confused myself when reading about loginUrl. There, the FedCM spec emphasizes that the flow is a top-level traversable, i.e. it is not foreign fetch, but for the non-interactive requests, you are absolutely correct.

Perhaps there's a better way to factor this than as a service worker (and thus no need to monkey patch foreign fetch into service worker spec). The FedCM config file could simply point to some sort of javascript file (a web worker?), and the procedures for the various algorithms could optionally call the web worker, if supplied in the config file. I will try to find some time to play around with that factoring.