Bring back "serviceworker" member

[mgiuca]

The "serviceworker" member was removed from manifest in November 2019 (w3c/manifest#825), see discussion on w3c/manifest#800.

This was done because, the understanding was at the time, it was specced for years but nobody ever implemented it. Well it turns out that it is being used, specifically by payment handlers, to install handler apps without actually ever running the HTML code for the site (installing the service worker directly from the manifest), and when we deleted the "serviceworker" member, we accidentally made that reliant on something that doesn't exist in a spec.

I'm a little unclear on the details here. @rsolomakhin can hopefully explain in more detail.

It looks like Chromium (at least) is actively using this (source code). (Aside: I think the reason we didn't detect this in November is because Chromium has a separate manifest parser for payment handlers than the main manifest parser; there is now a tracking bug to fix this.)

I'm trying to find somewhere in the specs that rely on this, and I didn't find anything normative. In the Payment Method Manifest spec, there is a non-normative note that references the now-deleted member:

In the future, the plan is for there to be a user-agent-independent way to use the resulting processed web app manifest, by consulting its serviceworker field and using that to install a web-based payment app conforming to the Payment Handler API specification.

It's possible that Chromium is going out ahead of the spec here and implementing that "future plan". That makes it a bit hard to justify restoring this feature to the manifest spec (if it's not actually referenced by normative text in the Web Payments specs). @rsolomakhin is there a plan to make this behaviour normative?

The other thing is that it's a bit weird to have a "serviceworker" member, which nominally allows a service worker to be installed directly from a manifest, but which in practice is only used for payment handlers. Perhaps this gives us the impetus to actually implement this more generally, and allow service workers to be installed without having to be imperatively registered by the JavaScript on a page.

@marcoscaceres, you're also on Payments. Do you have thoughts about this?

[marcoscaceres]

Was talking with @rsolomakhin recently that we might be able to do it without it. I can't recall the exact details though.

[mgiuca]

Let's wait for his reply. I chatted to him over email about this, but not about the fact that there's no reference to it from the payments specs.

[marcoscaceres]

sounds good... I seem to recall the solution was that they payment manifest would just point directly to the service worker file instead.

[mgiuca]

Effectively saying "move the serviceworker member from Web App Manifest into Payment Manifest". Which seems like a reasonable solution, if it's specific to payments.

[rsolomakhin]

The "serviceworker" field is used for just-in-time installation. For a demo, see https://rsolomakhin.github.io/pr/skip-ui/, which will install a service worker from https://bobpay.xyz. This is almost equivalent to a merchant using window.open("https://bobpay.xyz") and then https://bobpay.xyz installing it's service worker on page load.

Background: https://www.w3.org/blog/wpwg/2018/08/20/further-streamlining-the-payment-request-user-experience/#jit

Original decision to not spec just-in-time install: https://github.com/w3c/payment-handler/issues/240

New discussions to spec it: https://github.com/w3c/payment-handler/issues/346

Moving "serviceworker" field to https://w3c.github.io/payment-method-manifest/ does not sound exactly right to my ear, because Web Payments also uses multiple fields in web-app manifest, some of which are not used anywhere else. For example:

• "name"
• "icons"
• "prefer_related_applications"
• "related_applications.platform"
• "related_applications.id"

Only used in Web Payment, as far as I know:

• "related_applications.min_version"
• "related_applications.fingerprints.type"
• "related_applications.fingerprints.value"

These fields appear to make more sense to me in the web-app manifest, but maybe I'm biased. What's the right thing to do?

[sahel-sh]

Would it make sense to have a "payment" field inside Web App Manifest? The field can contain payment specific fields like "serviceworker". Another use case can be for a Just-In-Time installable payment app to declare the list of its supported delegations: https://github.com/sahel-sh/shipping-contact-delegation/blob/master/Explainer.md#edit-just-in-time-jit-installation

[mgiuca]

Would it make sense to have a "payment" field inside Web App Manifest? The field can contain payment specific fields like "serviceworker".

The problem with this is that the other cited examples are nested within another existing member (related_applications). But that is one option. It feels weird to me having both a Payment Method Manifest and a payment dictionary within the Web App Manifest.

So the options are:

1. serviceworker inside the Payment manifest.
2. serviceworker inside the Web App Manifest, but only used by payments for now.
3. serviceworker inside the Web App Manifest, intended to be used generally to install a service worker without loading a page. (i.e., its original intention)
4. payment.serviceworker inside the Web App Manifest.

The difference between 2 and 3 is perhaps not a spec difference, just implementation. The payment spec might mandate that serviceworker is used, but the web app manifest spec would not mandate its use for general installation, though user agents would be able to use it for that (for example, a store listing could install the service worker without having to load the page).

I would be in favour of 2 (which basically means reverting this), but then I think w3c/payment-handler#346 needs to be resolved so that there's an actual client of this in a spec (not just in a browser).

[marcoscaceres]

I'd be inclined to initially go with:

1. serviceworker inside the Payment manifest.

As an extension to web manifest spec.

However, rationale and issues for why we removed serviceworker in the first place remain (the declarative model being somewhat inflexible).

There are also some unresolved/premature presuppositions around "JIT" installation payment handlers, which don't have multivendor consensus in the Payments WG. IMO, although there are some excellent ideas underpinning payment handler JIT, it would be premature to codify those in a standard without support from a second implementation (particularly because there are still concerns regarding privacy/security of arbitrarily installing these payment handlers in a JIT-manner).

[sahel-sh]

IIRC, there is not a 1:1 mapping between payment methods and payment apps. How would moving serviceworker to the payment method manifest work when there are multiple JIT installable apps available for a given payment method?

[marcoscaceres]

sorry, I meant define serviceworker for Web Manifest in the other spec (as an extension), not for Payment Method Manifest.

... when there are multiple JIT installable apps available for a given payment method?

I'm not sure. We would need to work that out in Payment Method Manifest.

[sahel-sh]

Thanks @marcoscaceres for explaining. I don't know how the extension would work. Since it seems like keeping "serviceworker" as a generic member of web app manifest is preferred, I opened a separate issue for payment app specific properties.

[mgiuca]

Discussed with editors. We are leaning towards option 2 as I outlined above (simply restore it back to the way it was, but with a note that this is currently only used for payments).

However, since it currently only has one implementation, we've decided to omit it from the first CR for the spec. Deferring this until the next release.

[aarongustafson]

Thinking about this a bit more, it seems like having access to the serviceworker key could be useful for digital storefronts prompting installation too, no? Would it make sense to move it to App Info?

[marcoscaceres]

Thinking about this a bit more, it seems like having access to the serviceworker key could be useful for digital storefronts prompting installation too, no?

What would be the use case?

Would it make sense to move it to App Info?

It depends if the manifest can be decoupled from the document. But it gets quite messy so I would caution against it. Service workers are inherently responding to events generated by "scoped" documents (e.g., fetch, payment, install, etc.).

[mgiuca]

The use case in theory is pretty clear (and I believe why this was designed in the first place): a store front has an "install" button which registers a SW and creates a local app installation from just a manifest + SW, with no document.

In practice, though, well at least Chromium's app install and service worker registration mechanisms are highly coupled to a document. You can't do either of those things unless you have a document loaded, and that won't change without a major refactor. So in practice, this flow isn't feasible for us. (Though desirable.)

[marcoscaceres]

The use case in theory is pretty clear

Yes, sorry, I misunderstood @aarongustafson's comment - I misread as the use case was for the storefront, not for the app.

So in practice, this flow isn't feasible for us.

Same.