IRC log of apps on 2017-01-10

Timestamps are in UTC.

14:58:08 [RRSAgent]: RRSAgent has joined #apps
14:58:08 [RRSAgent]: logging to http://www.w3.org/2017/01/10-apps-irc
14:58:22 [Ian]: Meeting: Payment Apps Task Force
14:58:24 [Ian]: Agenda: https://lists.w3.org/Archives/Public/public-payments-wg/2017Jan/0025.html
14:58:26 [Ian]: Chair: Ian
14:58:28 [Ian]: Scribe: Ian
14:59:49 [Ian]: present+ Ian
14:59:52 [Ian]: present+ DavidJ
14:59:56 [Ian]: present+ Jenan
15:01:09 [adamR]: adamR has joined #apps
15:01:26 [Ian]: present+ AdamR
15:01:34 [Ian]: regrets+ Tommy
15:01:41 [Ian]: present+ Pascal
15:02:01 [alyver]: alyver has joined #apps
15:03:32 [Ian]: topic: Next meetings
15:03:38 [Ian]: 12 Jan: Developer sync up (chaired by Conor)
15:03:38 [Ian]: https://lists.w3.org/Archives/Public/public-payments-wg/2017Jan/0017
15:04:15 [Ian]: Next call of this task force: 17 Jan
15:04:28 [Ian]: IJ: regrets for 17th?
15:04:30 [Ian]: [none]
15:04:38 [Ian]: Topic: Recent changes to Payment App API
15:04:50 [Ian]: https://github.com/w3c/webpayments-payment-apps-api/pull/80
15:05:30 [Ian]: present+ Andrew
15:05:35 [Ian]: present- Andrew
15:05:36 [Ian]: present+ Andre
15:08:01 [Ian]: https://w3c.github.io/webpayments-payment-apps-api/#payment-app-identification
15:08:12 [Ian]: We have:
15:08:14 [Ian]: * Payment apps
15:08:20 [Ian]: * Payment app manifests
15:08:26 [Ian]: * Service worker JS
15:08:39 [Ian]: (Payment method URLs and manifest files)
15:09:13 [Ian]: https://w3c.github.io/webpayments-payment-apps-api/#dfn-payment-app-identifier
15:09:45 [Ian]: + <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>
15:10:08 [Ian]: IJ: What should the spec say about payment app identifiers?
15:10:14 [Ian]: AdamR: The new text seems ok
15:10:21 [Ian]: present+ Evgeny
15:10:40 [Ian]: adamr: The service worker code is not sufficient for registration.
15:11:06 [Ian]: IJ: What does the registration function need?
15:11:54 [Ian]: adamr: The service worker provides payment app manifest data for registration
15:14:32 [pascal_bazin]: q+
15:14:39 [Ian]: AdamR: 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.
15:14:43 [Ian]: ack pas
15:15:02 [Ian]: pascal_bazin: Maybe the problem is that we didn't really what registration is. ...
15:16:06 [Ian]: + <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>
15:16:21 [Ian]: In this specification, registration means registration
15:16:21 [Ian]: +of a service worker with the user agent.
15:16:21 [Ian]: +Registration provides the user agent
15:16:21 [Ian]: +with access to a payment app manifest, which
15:16:21 [Ian]: +includes information such as names, icons, etc. Registration does <strong>not</strong> refer to how the user establishes a relationship with the
15:16:23 [Ian]: +payment service provider, for example by setting up an account with that
15:16:25 [Ian]: +provider.</li>
15:16:34 [Ian]: ====
15:17:30 [Ian]: AdamR: Let's look at a single example service worker....
15:17:37 [adamR]: https://github.com/mdn/sw-test/blob/gh-pages/app.js
15:18:04 [Ian]: ..I think that having a single URL for JS code is fine
15:18:09 [Ian]: ...as long as it knows to install itself.
15:23:11 [Ian]: merchant needs to provide a URL that identifies code from the payment app providers.
15:23:18 [Ian]: ..part of that code registers the service worker.
15:23:39 [Ian]: ..the question is whether we can put that code in the same file that contains the service worker code
15:24:05 [Ian]: q+ to ask what we call the wrapper code
15:24:24 [Ian]: ack me
15:24:24 [Zakim]: Ian, you wanted to ask what we call the wrapper code
15:24:32 [Ian]: IJ: What can we call the code shown in example 1?
15:25:11 [Ian]: "payment app registration code"
15:25:27 [Ian]: - A payment app identifier can be deferenced to get payment app registration code
15:25:37 [Ian]: - payment app registration code is responsible for service worker registration
15:25:55 [Ian]: - Implementation detail: can both the registration code and the SW code co-exist in one file?
15:27:42 [Ian]: 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?
15:29:18 [Ian]: 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."
15:30:03 [Ian]: IJ: Does the merchant provide code or pointer to JS?
15:30:05 [Ian]: AdamR: Pointer to JS
15:31:11 [Evgeny]: Evgeny has joined #apps
15:31:42 [Ian]: AdamR: Service workers have identifiers (domain + path)
15:32:32 [alyver]: Two URLS is easier for merchants to manage than having to manage actual code
15:32:45 [Ian]: AdamR: We may need to think of ways to make this cleaner
15:33:56 [Ian]: What should we call the URL? "Payment app registration URL"?
15:34:11 [adamR]: https://pastebin.mozilla.org/8961074
15:34:14 [Ian]: AdamR: I'd like to get someone who is familiar with service workers to look at this
15:35:17 [Ian]: ...also at registration time, when service worker succeeds, the service worker will be invoked and can trigger an "Install" event
15:35:38 [Ian]: ...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
15:36:06 [Ian]: ========
15:37:24 [Ian]: AdamR: Recommended apps can set manifest on "install" event.
15:37:54 [Ian]: IJ: So walk through the flow:
15:38:24 [Ian]: 1) The payment request includes one or more URLs that are payment app identifiers - they indicate service worker JS code
15:38:29 [Ian]: (along with name, icon)
15:38:48 [Ian]: 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
15:39:08 [Ian]: 3) If not presently installed, then we display it to the user.
15:39:22 [adamR]: navigator.serviceWorker.register('/exampleapp.js')
15:39:29 [Ian]: 4) If the user selects it, then the browser registers the service worker using that payment app identifier.
15:40:08 [Ian]: 5) On registration, the service worker would add an event listener for "install" which would then be called.
15:40:31 [Ian]: 6) Code in the service worker would call a function to set up the manifest
15:43:52 [Ian]: ===> 4) Upon selection, the code calls register on navigator.ServiceWorker.
15:44:36 [Ian]: IJ: Should we do the "install" routinely?
15:44:43 [Ian]: AdamR: If it works, doesn't seem like a bad pattern
15:46:05 [Ian]: ACTION: Ian to take a stab at revising the script based on this description.
15:47:05 [Ian]: https://developer.mozilla.org/en-US/docs/Web/API/ServiceWorkerContainer/register
15:47:12 [Ian]: ServiceWorkerContainer.register(scriptURL, options)
15:47:20 [Ian]: IJ: So is this a scriptURL for a service worker?
15:47:30 [Ian]: https://www.w3.org/TR/service-workers/#service-worker-container
15:47:55 [adamR]: https://www.w3.org/TR/service-workers/#service-worker-concept
15:48:09 [Ian]: "A service worker has an associated script url (a URL)."
15:48:44 [Ian]: IJ: I won't merge the edits yet; we'll do another round.
15:49:14 [Ian]: topic: Issue 79: How does the payee provide information about recommended payment apps?
15:49:35 [Ian]: IJ: This is a change to PR API.
15:50:31 [Ian]: (No volunteers yet)
15:51:54 [Ian]: ACTION: AdamR to draft how PR API would change to allow-payee recommended payment apps, due 2017-01-24
15:52:09 [Ian]: topic: Issue 73
15:52:19 [Ian]: Rouslan to look into how progress web apps could help us understand
15:52:19 [Ian]: how to manage UI in different contexts.
15:52:19 [Ian]: (Postpone)
15:52:30 [Ian]: topic: Issue 23: Analyse security properties of payment app execution environment
15:52:45 [Ian]: https://github.com/w3c/webpayments-payment-apps-api/issues/23
15:53:55 [Ian]: AdamR: I would hesitate to restrict too much
15:54:18 [Ian]: ...we will want access to web authentication here
15:54:31 [Ian]: ...the example I've been giving is "what if someone wants access to the camera for biometric auth"?
15:56:28 [Ian]: IJ: Let's leave open for now
15:57:46 [Ian]: topic: FPWD?
15:57:54 [Ian]: IJ: Do we still want to this month?
15:58:04 [Ian]: ..what else do we need in the spec in order to be happy to go to FPWD?
15:58:31 [Ian]: IJ: Proposed
15:58:41 [Ian]: * Finish "recommended app edits' (that includes IJ, AR actions)
15:58:52 [Ian]: * Finish openWindow action from Rouslan
15:59:03 [Ian]: * Resolve 81 and 82
15:59:44 [Ian]: IJ: Think about that this week for discussion at next call.
16:01:27 [Ian]: topic: Next meeting
16:01:34 [Ian]: 17 Jan
16:01:47 [Ian]: rrsagent, make minutes
16:01:51 [Ian]: rrsagent, make minutes
16:01:51 [RRSAgent]: I have made the request to generate http://www.w3.org/2017/01/10-apps-minutes.html Ian
16:01:53 [Ian]: rrsagent, set logs public
16:02:18 [alyver]: alyver has left #apps
17:33:47 [Zakim]: Zakim has left #apps
18:12:03 [Ian]: rrsagent, bye
18:12:03 [RRSAgent]: I see 2 open action items saved in http://www.w3.org/2017/01/10-apps-actions.rdf :
18:12:03 [RRSAgent]: ACTION: Ian to take a stab at revising the script based on this description. [1]
18:12:03 [RRSAgent]: recorded in http://www.w3.org/2017/01/10-apps-irc#T15-46-05
18:12:03 [RRSAgent]: ACTION: AdamR to draft how PR API would change to allow-payee recommended payment apps, due 2017-01-24 [2]
18:12:03 [RRSAgent]: recorded in http://www.w3.org/2017/01/10-apps-irc#T15-51-54