[w3c/ServiceWorker] Export SW primitives needed by FedCM and Payment Handler for JIT registration (Issue #1846)

monica-ch created an issue (w3c/ServiceWorker#1846)

FedCM (see [w3c-fedid/FedCM#842](https://github.com/w3c-fedid/FedCM/pull/842)) and Payment Handler both need to perform just-in-time (JIT) service worker registration/unregistration from their own spec algorithms. The current SW spec exposes only a handful of exported algorithms — [`Handle Fetch`](https://w3c.github.io/ServiceWorker/#on-fetch-request-algorithm), [`Fire Functional Event`](https://w3c.github.io/ServiceWorker/#fire-functional-event-algorithm), [`Match Service Worker Registration`](https://w3c.github.io/ServiceWorker/#scope-match-algorithm), [`Request Matches Cached Item`](https://w3c.github.io/ServiceWorker/#request-matches-cached-item-algorithm), and [`Lookup Race Response`](https://w3c.github.io/ServiceWorker/#lookup-race-response-algorithm). The register/update/unregister primitives are all internal, so external specs currently have no stable way to programmatically manage service worker registrations.

@yoshisatoyanagisawa flagged this on the FedCM PR ([comment](https://github.com/w3c-fedid/FedCM/pull/842#issuecomment-3159938167)), and @Brandr0id proposed three additions ([comment](https://github.com/w3c-fedid/FedCM/pull/842#issuecomment-5149038173)).

This issue tracks adding three exported primitives to the SW spec so external specifications can integrate cleanly.

## Proposed exports

### 1. Export `Soft Update`

Add the `export` attribute to the existing [`Soft Update`](https://w3c.github.io/ServiceWorker/#soft-update-algorithm) dfn, plus small clarifying Notes for external callers (fire-and-forget contract; job-equivalence collapses duplicate calls). No algorithm behavior change.

### 2. New exported `Register a Service Worker`

A thin wrapper around `Create Job` + `Schedule Job` with `job type = register`, taking (storage key, script URL, scope URL, worker type, update via cache mode). Fire-and-forget; passes `null` for both client and job promise, so the resulting job has no referrer. Includes a Note that the same-origin gate against the referrer is skipped, so callers must satisfy the same-origin precondition themselves.

### 3. New exported `Unregister Service Workers`

Bulk unregister by storage key: iterate the `registration map` for matching storage key entries, parse the serialized scope URL, and schedule an unregister job for each.

## Rationale

Both FedCM and Payment Handler already do effectively this from their own specs, but by calling non-exported SW primitives directly. Providing exported wrappers:

- Keeps external spec text stable across future SW internal refactors
- Encapsulates the SW-internal job-scheduling model behind a stable interface
- Follows the same pattern as `Fire Functional Event`, which is already the exported entry point for functional event dispatch

## Non-goals

- No changes to any internal algorithms
- No new capabilities exposed to JS-facing APIs
- No Payment Handler-specific coordination — Payment Handler can adopt independently
- Not a redesign of the job queue or registration lifecycle

## Proposed PR split

- PR 1: Export `Soft Update` (small, uncontroversial editorial change)
- PR 2: Add `Register a Service Worker`
- PR 3: Add `Unregister Service Workers`

## Related

- w3c-fedid/FedCM#842 — original motivation
- FedCM's follow-up PR (not yet filed) will use `Fire Functional Event` for event dispatch (already exported)
- Payment Handler ([w3c/payment-handler](https://github.com/w3c/payment-handler)) has the equivalent gap


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1846
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/issues/1846@github.com>