13:57:44 <RRSAgent> RRSAgent has joined #apps
13:57:44 <RRSAgent> logging to http://www.w3.org/2017/06/20-apps-irc
13:58:04 <Ian> Meeting: Web Apps Task Force
13:58:06 <Ian> Meeting: Payment Apps Task Force
13:58:08 <Ian> Chair: Ian
13:58:12 <Ian> Scribe: Ian
13:58:14 <Ian> Agenda: https://lists.w3.org/Archives/Public/public-payments-wg/2017Jun/0022.html
13:58:28 <Ian> agenda+ next meeting
14:00:07 <Ian> present+ Ian
14:00:09 <Ian> present+ Frank
14:01:35 <alyver> alyver has joined #apps
14:01:52 <Ian> present+ aylver
14:02:08 <Ian> present+ Ken
14:02:10 <Ian> present+ jnormore
14:02:13 <Ian> present+ AdrianHB
14:02:22 <Ken> Ken has joined #apps
14:02:28 <AdrianHB> AdrianHB has joined #apps
14:02:36 <AdrianHB> present+
14:02:54 <Ian> -> https://lists.w3.org/Archives/Public/public-payments-wg/2017Jun/0022.html Agenda
14:02:59 <rouslan> rouslan has joined #apps
14:03:00 <Ian> present+ rouslan
14:03:03 <frank> frank has joined #apps
14:03:20 <Ian> https://www.w3.org/2002/09/wbs/35125/TPAC2017/
14:03:51 <Ian> topic: Review of recent changes and issues closed from pull requests
14:03:57 <Ian>  175: Fix to PaymentRequestEvent.total in light of WebIDL rules
14:04:16 <Ian>    168: PaymentRequestEvent.openWindow should check origin before navigation instead of after navigation
14:04:46 <Ian> agenda+ Updating the TR draft
14:04:54 <Ian> https://w3c.github.io/payment-handler/
14:05:04 <Ian> https://w3c.github.io/payment-handler/#windows
14:05:24 <rouslan> q+
14:05:34 <Ian> IJ: Should we close 169, 115, 97?
14:05:52 <Ian> rouslan: I think that someone from Samsung is planning to reconcile the algorithms between this spec and service workers
14:06:09 <Ian> ACTION: Ian to reach out to @romandev to see about reconciliation of open window algorithms
14:06:30 <Ian> https://github.com/w3c/payment-handler/issues/169
14:07:26 <rouslan> q+
14:07:36 <Ian> ack rouslan
14:08:11 <Ian> https://github.com/w3c/payment-handler/issues/97
14:09:02 <rouslan> +1
14:10:17 <Ian> RESOLVED: Close 97 in favor of 115
14:10:20 <Ian> Topic: Implementation news
14:10:22 <rouslan> q+
14:10:25 <Ian> ack rouslan
14:10:41 <Ian> rouslan: We are still behind a flag in Canary. You can experiment with it. We have implemented the open window algorithm.
14:10:57 <Ian> ...it's looking good...there is a chrome custom tab with a reduced number of menu items
14:11:17 <Ian> ...some functionality was removed (e.g., can't open in regular browser frame)
14:11:32 <Ian> ...one thing that would not be possible to PREVENT is navigation around
14:11:41 <Ian> ...that would terminate connection to the service worker
14:11:56 <Ian> ...we don't know how to solve this issue; we don't consider it to be a big issue.
14:12:18 <Ian> ...page can also change its own URL (through JS) which would terminate connection to SW
14:12:28 <Ian> ...the samsung folks are implementing the permission request
14:12:33 <Ian> ...the spec is not clear on how it should work.
14:12:42 <Ian> ...they are using other permission request examples from other spec
14:12:55 <Ian> ...I have encouraged a PR for our spec
14:13:17 <Ian> https://github.com/w3c/payment-handler/issues/94
14:13:57 <Ian> (Rouslan has already cc'd @romandev)
14:14:11 <AdrianHB> q+ to mention interledger implementation work
14:14:33 <Ian> ack adr
14:14:33 <Zakim> AdrianHB, you wanted to mention interledger implementation work
14:14:46 <Ian> AdrianHB: We are working on an implementation of Payment Handler API with interledger
14:14:48 <Ian> ...ILPKit
14:14:54 <AdrianHB> https://github.com/interledgerjs/ilp-kit
14:16:00 <Ian> ...hope to have a demo by early next week
14:16:07 <Ian> ...we are working with Canara.
14:16:20 <Ian> IJ: How easy is it to do?
14:16:38 <Ian> AdrianHB: The android payment app was easy (done by Shopify); we are moving on to Web based; I'll let you know.
14:17:05 <Ian> IJ: Please bring feedback; thanks!
14:17:06 <Ian> q?
14:17:28 <Ian> topic: PR 170: Add CanMakePaymentEvent and AbortPaymentEvent. Any implementation experience to report?
14:17:46 <Ian> IJ: How is that going?
14:17:54 <Ian> rouslan: I haven't starting implementing it; thanks for comments so far.
14:18:08 <Ian> ...but I do think it's the correct approach.
14:18:18 <Ian> topic:    Issue 179: PaymentRequestEvent.total should be PaymentCurrencyAmount. Three people support this.
14:18:27 <Ian> https://github.com/w3c/payment-handler/issues/179
14:19:32 <Ian> RESOLVED: to change PaymentRequestEvent.total to type PaymentCurrencyAmount
14:19:52 <Ian> ACTION: Rouslan will do a pull request to make the type change for issue 179
14:19:58 <Ian> RRSAgent, make minutes
14:19:58 <RRSAgent> I have made the request to generate http://www.w3.org/2017/06/20-apps-minutes.html Ian
14:20:06 <Ian> RRSAgent, set logs public
14:20:29 <Ian> Topic:    Issue 178: Default handler icon? Ian suggested a sentence to help address this.
14:21:03 <Ian> https://github.com/w3c/payment-handler/issues/178
14:21:52 <Ian> This API defines mechanisms to specify icons and labels for the display of instruments. Other Web technology (e.g., Web app manifest) enables user agents to fetch icons, labels, and other "higher level" information about the payment handler.
14:22:08 <rouslan> q+
14:22:19 <Ian> ack rouslan
14:22:26 <Ian> IJ: The idea of the proposal was "we don't specify it here"
14:22:37 <Ian> rouslan: What happens if a payment handler does NOT have a web app manifest?
14:22:41 <Ian> ...I think the answer should be left to browsers
14:22:51 <Ian> ...e.g., Chrome will always use the web app manifest
14:23:32 <Ian> ...what happens if (1) doesn't exist (2) don't specify icons (3) icons can't be fetched.
14:23:43 <Ian> ...I think what we will do is to not show the payment handler in the list
14:24:07 <Ian> ...this is contentious because one way to view this behavior is that payment handler cannot predict UI behavior, which is subpar
14:24:11 <Ian> q?
14:24:44 <rouslan> q+
14:25:14 <AdrianHB> q+ to ask if a default icon is okay?
14:25:18 <Ian> IJ: How do implementations handle web app manifest errors?
14:25:27 <Ian> rouslan: We have been printing console warning messages
14:25:57 <Ian> ...e.g., if a page does not have a fav icon and uses payment request; we show a message that user experience will be subpar but we do show something
14:26:29 <Ian> ...we could show console warning to developers (in case of payment handler) and still not show payment app in the list
14:26:30 <Ian> ack rous
14:26:32 <Ian> ack AdrianHB
14:26:32 <Zakim> AdrianHB, you wanted to ask if a default icon is okay?
14:26:43 <Ian> AdrianHB: Couldn't we follow similar behavior to favicon?
14:26:49 <rouslan> q+
14:27:00 <Ian> AdrianHB: Seems extreme to me to not show payment handler if you can't find the icon
14:27:03 <Ian> ack rouslan
14:27:18 <Ian> rouslan: I guess we are already showing origin of payment handler underneath
14:27:31 <Ian> ...so maybe if we don't find label/icon we show origin
14:27:45 <Ian> ..and we put that lower in the list of matching payment apps
14:27:50 <jnormore> +1 to leaving it up to browsers to handle failure/degraded modes for this
14:28:12 <AdrianHB> +1 to not excluding but leave with browsers to decide how to best serve UI
14:28:13 <Ian> https://www.w3.org/TR/appmanifest/
14:28:22 <Ian> https://www.w3.org/TR/appmanifest/#example-manifests
14:28:48 <Ian> ===
14:28:49 <Ian> <!-- Startup configuration -->
14:28:49 <Ian> <link rel="manifest" href="manifest.webmanifest">
14:28:49 <Ian> <!-- Fallback application metadata for legacy browsers -->
14:28:49 <Ian> <meta name="application-name" content="Racer3K">
14:28:50 <Ian> <link rel="icon" sizes="16x16 32x32 48x48" href="lo_def.ico">
14:28:51 <Ian> <link rel="icon" sizes="512x512" href="hi_def.png">
14:28:53 <Ian> ====
14:30:01 <rouslan> +1
14:30:21 <Ian> Summary of spec text:
14:30:31 <Ian>  * State that other web technologies are used for app-level info
14:30:54 <rouslan> q+
14:31:05 <Ian>  * A statement about browser behavior in the absence of icons/labels
14:31:19 <Ian>  * Preferable for user agents to degrade the experience, and how browsers do so is up to the browser
14:31:40 <Ian> * Browsers should not omit payment apps entirely when there is no specified app-level display info
14:32:13 <rouslan> +1
14:32:14 <Ian> IJ: What about falling back to favicon in some cases?
14:32:17 <Ian> (Rouslan: +1)
14:32:45 <Ian> ACTION: Rouslan to noodle on proposal in GitHub thread for issue 178
14:32:55 <Ian> Topic: Issue 173
14:33:04 <Ian> Ability to set default instrument for given handler.
14:33:08 <Ian> https://github.com/w3c/payment-handler/issues/173
14:33:17 <Ian> Two parts:
14:33:41 <Ian> 1) Is there a need for payment handlers to know when an instrument has been selected "as a default" v. "alongside a full list"?
14:34:06 <Ian> 2) User experience that combines (1) ease of selecting a default with (2) ease of accessing a full list
14:34:24 <Ian> https://github.com/w3c/payment-handler/issues/173#issuecomment-308508202
14:36:14 <Ian> (IJ thinks Tommy's proposal is to launch payment app, not show a submenu of instruments)
14:37:24 <Ian> q?
14:37:45 <Ian> jnormore: My suggestion is to determine defaults.
14:37:58 <Ian> ..is to let the user agent determine defaults
14:38:40 <Ian> ack rous
14:40:32 <Ian> jnormore: I am not against defaultKey concept
14:40:42 <Ian> ...rather instrumentKey concept
14:41:13 <jnormore> I am against defaultKey concept*
14:41:26 <jnormore> not against instrumentKey
14:41:42 <Ian> AdrianHB: What I am worried about...as a payment handler, I like the idea of skipping instrument selection within my app
14:41:56 <Ian> ...I want users to be able to click once to pick the instrument and my app
14:42:11 <Ian> ...as soon as I tell the browser that one is a default, then every time that instrument comes through, I don't know whether the user
14:42:16 <Ian> ...was presented with all the options, or not.
14:42:30 <Ian> ...if the user does not want to use their default, they have no way of doing so unless the browser gives them the option for "all"
14:42:41 <Ian> ..I think it's a separate issue of "how we implement this concept"
14:43:10 <Ian> ...every instrument has an instrumentKey
14:43:20 <Ian> ..I can nominate one as a default for the payment handler
14:43:39 <Ian> ..when I get the payment request event, the browser tells me, e.g., "how many were presented" or "that was the only one presented.
14:43:49 <rouslan> q+
14:44:21 <Ian> ack rous
14:45:08 <Ian> rouslan: Currently in Chrome, when the merchant requests shipping address and does not provide shipping options, that indicates "I need shipping address first before I can compute total"
14:45:09 <rouslan> "Shipping address [SELECT]"
14:45:16 <Ian> ...so that's what we used to present
14:45:25 <Ian> ...we found that UI to be sub-optimal...so we changed it
14:45:31 <Ian> ...the improvement is:
14:45:47 <Ian> ....we add preview of addresses the user has
14:45:55 <rouslan> "Shipping addresss (123 Main st... and 2 others) [SELECT]"
14:46:09 <Ian> ...we found that type of user interface improves user engagement
14:46:20 <Ian> ...if we apply the same idea to payment handler
14:46:28 <rouslan> "BobPay [icon]"
14:46:28 <Ian> ...we might do something like this:
14:46:40 <Ian> * BobPay (Visa ***4132 and 5 others)
14:47:41 <Ian> rouslan: So one question is "what should the default be"?
14:48:07 <Ian> ...it's not obvious for browser to determine usage since we don't parse the response data
14:48:18 <Ian> ...so the payment app can specify a default
14:48:58 <Ian> IJ: I am hearing that:
14:49:05 <Ian> 1) Some payment apps may WANT to provide a default service and
14:49:27 <Ian> 2) User agents don't really have "frequency" information since they may not (or do not) parse response data to know what instruments have been selected.
14:50:05 <rouslan> q+
14:50:15 <jnormore> q+
14:50:15 <Ian> IJ: For shipping address, what's the UI for getting the whole list?
14:50:27 <Ian> rouslan: you get the default OR select to get the full list
14:50:36 <Ian> ack rouslan
14:51:03 <Ian> rouslan: For Bobpay, I don't think we will display the list of instruments, we will just launch the payment app
14:51:10 <Ian> ack jno
14:51:59 <Ian> jnormore: If the browser doesn't have access to the data about user experience, and browser is ok to launch the app, then my point is moot
14:52:11 <Ian> Summarizing:
14:52:44 <Ian> 1) We should give payment handlers the ability to specify a default instrument (and the handler gets the info about instrumentKey when selected as default)
14:52:44 <AdrianHB> If the browsers shows an option like: * BobPay (Visa ***4132 and 5 others) then they shouldn't pass an instrumentKey in the event
14:53:01 <jnormore> +1
14:53:12 <rouslan> +1
14:53:16 <jnormore> q+
14:53:42 <Ian> Three cases:
14:53:49 <Ian> 1) Default shown and selected
14:53:57 <Ian> 2) Default shown but not selected
14:54:16 <Ian> 3) All shown and an instrument is selected (which MIGHT be the "default")
14:55:01 <jnormore> q-
14:55:04 <Ian> AdrianB: Tommy's approach solves #2
14:55:52 <Ian> s/AdrianB: Tommy's approach solves #2//
14:56:23 <Ian> q?
14:57:09 <Ian> AdrianHB: I understood rouslan's proposal to say "which label to show in the display; but it does NOT mean that instrument is selected when I pick bob pay."....it's just a hint
14:57:29 <rouslan> +1
14:57:53 <Ian> IJ: How do you manage the default?
14:57:58 <jnormore> q+
14:58:11 <Ian> AdrianHB: +1 to leaving this to the browsers to display, but as long as we have enough information so that payment app is aware of what happened.
14:58:44 <Ian> ...so "Visa 4321" is clear to mean "Pick Bob pay AND Visa 4321"...payment handler needs ability to know what happened in the UI
14:58:46 <Ian> ack jnormore
14:59:37 <Ian> jnormore: Unless the browser provides a list of instruments or explicitly selected instrument, it's hard to pass that to the payment handler....but if the browser displays instruments, it can pass the individual keys
14:59:56 <Ian> ...so one problem is browser capturing data, and allowing payment handlers to provide  a default instrument key
15:01:02 <alyver> Jason and I can certainly noodle on this.
15:01:04 <Ian> ACTION: jnormore to write up some notes on handling the three cases in Github
15:01:11 <Ian> topic: Next meeting
15:01:16 <Ian> 11 July
15:01:37 <rouslan> +1
15:01:46 <jnormore> +1
15:01:47 <Ian> IJ: Feel free to do work on GitHub or meet by phone if you self-organize
15:02:08 <Ian> RESOLVED: Next phone call 11 July
15:02:15 <Ian> AdrianHB: I can chair a call if needed; let's play it by ear
15:02:28 <Ian> RRSAGENT, make minutes
15:02:28 <RRSAgent> I have made the request to generate http://www.w3.org/2017/06/20-apps-minutes.html Ian
15:02:33 <Ian> RRSAGENT, set logs public
15:03:16 <Ian> RRSAGENT, make minutes
15:03:16 <RRSAgent> I have made the request to generate http://www.w3.org/2017/06/20-apps-minutes.html Ian
15:03:17 <Ian> RRSAGENT, set logs public
15:17:36 <alyver> alyver has joined #apps
15:31:56 <alyver> alyver has joined #apps
16:56:54 <alyver> alyver has joined #apps
17:16:52 <cweiss> cweiss has joined #apps
17:32:35 <alyver> alyver has joined #apps
18:11:44 <alyver> alyver has joined #apps
18:30:32 <alyver> alyver has joined #apps
18:30:59 <alyver> alyver has joined #apps
18:42:47 <cweiss> cweiss has joined #apps
18:59:15 <alyver> alyver has joined #apps
21:02:29 <cweiss> cweiss has joined #apps