Add Request Soft Update algorithm for use by other specifications

[monica-ch]

Part of #1846.

Change

Introduces a new exported Request Soft Update algorithm. The existing Soft Update remains unexported — external specifications must go through the wrapper.

Design decisions

• Storage key as input, not environment. Yoshi's original suggestion allowed either. FedCM has no environment settings object (it operates from UA-side code), so storage key is the only workable input type.
• "Coalesce, throttle, or ignore" language. Explicit UA discretion. "Coalesce" allows deduplication of redundant requests; "throttle" allows rate-limiting; "ignore" is the escape hatch.
• Soft Update is not exported. Callers must go through the wrapper. This ensures the storage-key check and UA-discretion clause always apply to external calls.
• forceBypassCache is optional. It defaults to false, but calling specifications can request cache bypass when their use case requires it.

Adoption implications

• Signature (registration, requestingStorageKey, forceBypassCache = false) becomes an implicit stability commitment.
• FedCM (Add initial Identity Handler SW Registration Tie In. w3c-fedid/FedCM#842) and Payment Handler can bind to Request Soft Update directly.
• UAs gain explicit authority to throttle or ignore, so implementations can add reasonable rate-limiting without violating the spec.

Related

• Export SW primitives needed by FedCM and Payment Handler for JIT registration #1846 — umbrella issue
• Add initial Identity Handler SW Registration Tie In. w3c-fedid/FedCM#842 — motivating consumer; confirmed compatible with this design
• Add Register a Service Worker algorithm for use by other specifications #1848 — sibling PR (Register a Service Worker)
• Add Unregister Service Workers algorithm for use by other specifications #1849 — sibling PR (Unregister Service Workers)

---

Preview | Diff

[monica-ch]

@yoshisatoyanagisawa Will you take a look at this change?

@Brandr0id FYI

[yoshisatoyanagisawa]

I have two main concerns regarding exporting the Soft Update algorithm directly:

1. DoS and Lifecycle Thrashing: Exposing this allows arbitrary triggers that could lead to excessive resource usage for both the browser and the site (essentially a form of DoS or lifecycle thrashing).
2. Privacy / Security: We need to prevent arbitrary sites or contexts from triggering an update if they somehow obtain a registration that doesn't belong to their partition.

Because external callers like FedCM genuinely need to fetch the latest script, relying on updateViaCache is not a viable workaround here.

Therefore, I suggest we introduce and export a wrapper algorithm (e.g., Request Soft Update) instead of directly exporting the raw Soft Update.

This wrapper algorithm could do the following:

• Require the calling environment (or storage key) as an argument to strictly enforce a storage key match against the registration.
• Explicitly state that the browser may ignore or throttle the update request. This gives User Agents the authority to prevent excessive resource consumption and mitigate DoS attacks.

What do you think?

[monica-ch]

.

Thanks for the review — I reworked this around the Request Soft Update wrapper and tightened the user-agent discretion wording in 49711d1.

• The wrapper requires the requesting storage key and returns when it does not match the registration's storage key.
• The user agent may return before running Soft Update, allowing it to decline requests to protect against excessive resource use.
• A note explains that implementations can rate-limit requests or treat several nearby invocations for the same registration as one.
• The note also makes the best-effort contract explicit: callers cannot rely on an update check occurring.
• The underlying Soft Update algorithm remains unexported.

I used return deliberately: WHATWG's algorithm-writing guidance uses it to exit an entire algorithm, whereas “abort these steps” is intended for nested or parallel substeps. Keeping coalescing and rate limiting in the explanatory note avoids making an undefined implementation strategy look like an executable algorithm step.

FedCM can use this wrapper with its UA-derived identity-handler storage key; the request remains intentionally best-effort rather than guaranteeing that every invocation starts an update.

Agreed and make sense. Thanks for the feedback @yoshisatoyanagisawa. I reworked this to export a  Request Soft Update  wrapper instead of exposing Soft Update directly.

It takes a storage key because callers such as FedCM may not have an environment available, but can supply the UA-derived storage key for the request. The wrapper enforces a match with the registration and gives the UA discretion to decline, rate-limit, or coalesce update requests. Callers therefore cannot assume every invocation triggers an update check.

@Brandr0id could you confirm that this best-effort contract works for the FedCM identity-handler flow?

[yoshisatoyanagisawa]

LGTM with comments.