See also: IRC log
<scribe> Scribe: Ian
12 Jan: Developer sync up (chaired by Conor)
https://lists.w3.org/Archives/Public/public-payments-wg/2017Jan/0017
Next call of this task force: 17 Jan
IJ: regrets for 17th?
[none]
https://github.com/w3c/webpayments-payment-apps-api/pull/80
https://w3c.github.io/webpayments-payment-apps-api/#payment-app-identification
We have:
* Payment apps
* Payment app manifests
* Service worker JS
(Payment method URLs and manifest files)
https://w3c.github.io/webpayments-payment-apps-api/#dfn-payment-app-identifier
+ <li>We expect to identify Web-based payment apps with URLs. Dereferencing a payment app identifier will provide service worker code for the payment app.</li>
IJ: What should the spec say about payment app identifiers?
AdamR: The new text seems
ok
... The service worker code is not sufficient for
registration.
IJ: What does the registration function need?
adamr: The service worker
provides payment app manifest data for registration
... We could specify that in the JS file, there is a function
with a specific name that is responsible for registering the
service worker if it's not already registered.
pascal_bazin: Maybe the problem is that we didn't really what registration is. ...
+ <li>It defines mechanisms that may be used to support Web-based payment apps. We anticipate that various platforms will offer proprietary alternatives to this specification (e.g., for payment app registration or invocation). Proprietary payment apps lie outside the scope of this specification.</li>
In this specification, registration means registration
+ of a service worker with the user agent.
+ Registration provides the user agent
+with access to a payment app manifest, which
+ includes information such as names, icons, etc. Registration does <strong>not</strong> refer to how the user establishes a relationship with the
+ payment service provider, for example by setting up an account with that
+ provider.</li>
====
AdamR: Let's look at a single example service worker....
<adamR> https://github.com/mdn/sw-test/blob/gh-pages/app.js
AdamR: I think that having a
single URL for JS code is fine
... as long as it knows to install itself.
merchant needs to provide a URL that identifies code from the payment app providers.
scribe: part of that code
registers the service worker.
... the question is whether we can put that code in the same
file that contains the service worker code
<Zakim> Ian, you wanted to ask what we call the wrapper code
IJ: What can we call the code shown in example 1?
"payment app registration code"
- A payment app identifier can be deferenced to get payment app registration code
- payment app registration code is responsible for service worker registration
- Implementation detail: can both the registration code and the SW code co-exist in one file?
IJ: I think the payment app identifier needs to be in either the registration code or the service worker code so that the browser can tell whether the user already has a merchant-recommended payment app?
AdamR: When we have a recommended app, we need the merchant to say "here's the service worker app I want you to use...and if it's not installed already, here's the registration code."
IJ: Does the merchant provide code or pointer to JS?
AdamR: Pointer to JS
... Service workers have identifiers (domain + path)
<alyver> Two URLS is easier for merchants to manage than having to manage actual code
AdamR: We may need to think of ways to make this cleaner
What should we call the URL? "Payment app registration URL"?
<adamR> https://pastebin.mozilla.org/8961074
AdamR: I'd like to get someone
who is familiar with service workers to look at this
... also at registration time, when service worker succeeds,
the service worker will be invoked and can trigger an "Install"
event
... for payment apps that are expected to operate in a
recommended app context, the pattern could be that you listen
on install and set the manifest at that time
========
AdamR: Recommended apps can set manifest on "install" event.
IJ: So walk through the flow:
1) The payment request includes one or more URLs that are payment app identifiers - they indicate service worker JS code
(along with name, icon)
2) When that's passed to the browser, the browser looks to see whether the user has already registered a service worker with that id
3) If not presently installed, then we display it to the user.
<adamR> navigator.serviceWorker.register('/exampleapp.js')
4) If the user selects it, then the browser registers the service worker using that payment app identifier.
5) On registration, the service worker would add an event listener for "install" which would then be called.
6) Code in the service worker would call a function to set up the manifest
===> 4) Upon selection, the code calls register on navigator.ServiceWorker.
IJ: Should we do the "install" routinely?
AdamR: If it works, doesn't seem like a bad pattern
<scribe> ACTION: Ian to take a stab at revising the script based on this description. [recorded in http://www.w3.org/2017/01/10-apps-minutes.html#action01]
https://developer.mozilla.org/en-US/docs/Web/API/ServiceWorkerContainer/register
ServiceWorkerContainer.register(scriptURL, options)
IJ: So is this a scriptURL for a service worker?
https://www.w3.org/TR/service-workers/#service-worker-container
<adamR> https://www.w3.org/TR/service-workers/#service-worker-concept
"A service worker has an associated script url (a URL)."
IJ: I won't merge the edits yet; we'll do another round.
IJ: This is a change to PR API.
(No volunteers yet)
<scribe> ACTION: AdamR to draft how PR API would change to allow-payee recommended payment apps, due 2017-01-24 [recorded in http://www.w3.org/2017/01/10-apps-minutes.html#action02]
Rouslan to look into how progress web apps could help us understand
how to manage UI in different contexts.
(Postpone)
https://github.com/w3c/webpayments-payment-apps-api/issues/23
AdamR: I would hesitate to
restrict too much
... we will want access to web authentication here
... the example I've been giving is "what if someone wants
access to the camera for biometric auth"?
IJ: Let's leave open for now
IJ: Do we still want to this
month?
... what else do we need in the spec in order to be happy to go
to FPWD?
... Proposed
* Finish "recommended app edits' (that includes IJ, AR actions)
* Finish openWindow action from Rouslan
* Resolve 81 and 82
IJ: Think about that this week for discussion at next call.
17 Jan
rrsagent, make minutes