16:01:45 RRSAgent has joined #apps 16:01:45 logging to http://www.w3.org/2017/01/12-apps-irc 16:01:50 Meeting: Payment App Dev Sync 16:01:53 Chair: Conor 16:01:56 Scribe: Ian 16:02:04 present+ 16:02:06 present+ Frank 16:02:07 rouslan has joined #apps 16:02:09 present+ Mathieu 16:02:11 present+ Rouslan 16:02:15 present+ Pascal 16:02:16 mathp has joined #apps 16:02:16 present+ Roy 16:02:34 present+ 16:03:17 present+ Conor 16:03:22 zakim, who's here? 16:03:22 Present: Ian, Frank, Mathieu, Rouslan, Pascal, Roy, mathp, Conor 16:03:24 On IRC I see mathp, rouslan, RRSAgent, Zakim, adamR, AdrianHB, Dongwoo, Ian 16:03:26 pascal_bazin has joined #apps 16:03:34 conorhwp has joined #apps 16:03:42 present- Mathieu 16:03:46 zakim, who's here? 16:03:46 Present: Ian, Frank, Rouslan, Pascal, Roy, mathp, Conor 16:03:49 On IRC I see conorhwp, pascal_bazin, mathp, rouslan, RRSAgent, Zakim, adamR, AdrianHB, Dongwoo, Ian 16:03:56 frank has joined #apps 16:04:58 present+ AdamR 16:05:34 topic: Update from browser 16:05:38 topic: Update from app developers 16:05:43 topic: Highlights and blockers 16:05:51 topic: Payment app spec changes? 16:06:10 agenda+ Update from browser 16:06:17 agenda+ Update from app developers 16:06:22 agenda+ Highlights and blockers 16:06:32 agenda+ Payment app spec changes? 16:06:35 agenda+ Next steps 16:06:39 zakim, take up item 1 16:06:39 agendum 1. "Update from browser" taken up [from Ian] 16:06:51 q+ to talk about payment app status 16:07:15 adamr: We are moving forward internally but don't have updates for you yet 16:07:50 q? 16:08:01 ack rous 16:08:01 rouslan, you wanted to talk about payment app status 16:08:27 rouslan: Payment App API status in Chrome - we are attacking both native apps and service-worker based apps 16:08:39 ...for native, partially implemented behind AndroidPaymentApps flag 16:08:51 ...if you use that you should be able to write an android app that talks to PR API 16:08:59 ...next steps would be to download the manifest file 16:09:15 q+ to ask Rouslan about the native interface 16:09:16 ..I think there's a patch from Samsung that will pre-query apps to see if they are ready to pay 16:09:33 ..meanwhile on Service-worker based apps, Opera and Samsung are implementing changes. 16:09:42 ...it's currently behind a flag 16:10:02 ..in there, service workers can register as payment apps and, I believe that the app names can be displayed (but not yet the options) 16:10:14 ...working on how to invoke the payment apps 16:10:15 ack adam 16:10:15 adamR, you wanted to ask Rouslan about the native interface 16:10:35 adamR: Last time we looked into this it wasn't possible for another browser to hook into the native app api. 16:10:53 Rouslan: I received feedback that my spec was not specific enough. I started to add more WebIDL type information to the spec 16:11:10 ..I also plan to add more algorithms, which would make it easier for other browsers to implement the spec without looking at Chrome code 16:11:27 ..the spec is still changing...we noticed some issues from developers where we should really be following more of a service-worker based approach 16:11:36 ...so the spec is available but is changing based on that feedback 16:11:42 [Spec URL from Rouslan] 16:11:50 https://groups.google.com/a/chromium.org/forum/#!msg/chromium-dev/fsslHD1Gf88/K2KpikS6BwAJ 16:11:55 q? 16:12:00 zakim, who's here? 16:12:00 Present: Ian, Frank, Rouslan, Pascal, Roy, mathp, Conor, AdamR 16:12:02 On IRC I see frank, conorhwp, pascal_bazin, mathp, rouslan, RRSAgent, Zakim, adamR, AdrianHB, Dongwoo, Ian 16:12:09 present+ AdrianHB 16:13:14 zakim, close item 1 16:13:14 agendum 1, Update from browser, closed 16:13:15 I see 4 items remaining on the agenda; the next one is 16:13:15 2. Update from app developers [from Ian] 16:13:17 zakim, take up item 2 16:13:17 agendum 2. "Update from app developers" taken up [from Ian] 16:13:23 q+ conor 16:13:26 ack conor 16:14:03 Conor: I tested Tommy's implementation of the service-worker based payment apps into Chromium. It worked well. I was able to host my own payment app and use alongside Tommy's and use either to make a payment 16:14:11 ...so that was cool (even though still early) 16:14:24 ...is the work that Tommy has released the same work that Rouslan mentioned here? 16:14:31 Rouslan: Same 16:14:45 ...his work will end up at some point in Chromium source code 16:15:06 Conor: It would be great to have one build of Chromium that supports both the native and service-worker bits 16:15:16 Rouslan: It will be available in an upcoming Chrome canary release 16:15:47 Conor: For native android apps, what if I wanted to launch a native windows or MacOS app 16:15:54 ...do you foresee support for that at some point? 16:16:03 ...if not, could it be triggered through a scheme host? 16:16:23 q+ 16:16:25 ...could you launch a native app in a native app in mac and have a service worker communicate with it (e.g., via localhost)? 16:16:30 q+ 16:16:38 ...the native app could do the work and the service worker could do the communication 16:16:54 ack ad 16:17:25 adamR: Is it possible to install web extensions? They could act as service workers and call out to native apps 16:17:32 ...that's the writeup that I threw together in london 16:17:35 ack rous 16:17:45 rouslan: We haven't looked explicitly into extensions as payment apps 16:17:58 ..I think that the service worker approach is not as hacky as you think...it's flexible and powerful 16:18:18 ...because service workers can show a page in the browser AND talk to server (which can reach out to devices or apps on devices) 16:18:39 ...I think the solution that you have described is not only reasonable, but I think I would prefer this approach 16:18:51 q+ 16:18:57 Conor: Ok, I'll look into this further and perhaps share a proof of concept 16:19:05 ack ad 16:19:23 adamR: If you have things that you want to do that you can't accomplish with the web platform, it's probably best to raise those as gaps in a W3C context 16:19:37 Ian: +1 16:19:41 q? 16:19:50 {rouslan has to leave} 16:20:23 Conor: other app developer stories? 16:20:33 q+ 16:21:06 q+ to mention app we'd like to develop for FTF to demo Interledger via PaymentRequest 16:21:11 Conor: My other question (for Google) is about a web payment app developed by google shared on a google+ page 16:21:42 https://groups.google.com/a/chromium.org/forum/#!msg/chromium-dev/fsslHD1Gf88/K2KpikS6BwAJ 16:22:09 https://drive.google.com/drive/u/0/folders/0B9_TYWUgXNVFS093UmZXUlEwcVE ? 16:22:24 doc is evolving 16:22:59 q? 16:23:02 ack Pas 16:23:14 https://polykart-credential-payment.appspot.com/ ? 16:23:30 Pascal: I am working on a third party payment app using our SDK for banks 16:24:06 q? 16:24:13 q+ on web payment apps 16:24:15 ack AdrianHB 16:24:15 AdrianHB, you wanted to mention app we'd like to develop for FTF to demo Interledger via PaymentRequest 16:24:44 AdrianHB: Our team at Ripple would like to connect inter ledger work with payment apps 16:24:54 ...we are hoping to put together either a web app or android app or both 16:24:59 ...to show at the FTF meeting 16:26:20 IJ: I can easily see Evan and Stefan at the FTF. :) 16:26:21 q? 16:26:23 ack mat 16:26:23 mathp, you wanted to comment on web payment apps 16:26:31 mathp: I have a question about web payment apps 16:27:00 ...has the group considered a repo where we can share information about payment app implementations? 16:27:06 q+ 16:27:13 good idea 16:27:15 q+ 16:27:16 ack con 16:27:31 conorhwp: I have discussed this internally. We plan to release some source code for payment apps that we're working on 16:27:40 ...we will likely release both a web-based and native app 16:28:03 ...client side code would be released 16:28:08 ...would be on github 16:28:14 ack me 16:28:30 Experimentation part of our wiki: 16:28:30 https://github.com/w3c/webpayments/wiki#experimentation-and-implementation 16:29:09 Mathieu: Yes, that's what I was looking for. 16:29:42 ACTION: Ian to write to the web payments WG and suggest that people list their projects there (when they can) 16:31:03 q? 16:31:23 Frank: We are still playing around with Tommy's work 16:31:34 ...we are trying to get our proper payment app in there....no feedback yet 16:31:40 q? 16:31:44 zakim, close this item 16:31:44 agendum 2 closed 16:31:45 I see 3 items remaining on the agenda; the next one is 16:31:45 3. Highlights and blockers [from Ian] 16:31:53 zakim, take up item 3 16:31:53 agendum 3. "Highlights and blockers" taken up [from Ian] 16:32:17 Conor: Seems like there is some good implementation experience (both native and web) 16:32:49 https://github.com/w3c/webpayments-payment-apps-api/issues 16:33:57 https://github.com/w3c/webpayments-payment-apps-api/issues/73 16:35:07 IJ: Any experimentation around opening windows? 16:35:28 Mathp: We'll look into this 16:36:39 IJ: Any experimentation around the use of HTTP Link headers to get from payment method URL to manifest file 16:37:18 https://github.com/w3c/webpayments-payment-apps-api/issues/14 16:37:45 Roy has joined #apps 16:37:56 Is anybody implementing "Launch when there is only one match" 16:38:27 AdamR: Regarding the feature, we have some problematic privacy issues. I am ok as long as the user opts into the behavior 16:39:34 ..note that calling payment request API does not itself require user interaction. 16:39:39 ...can be done "on load" 16:39:49 Mathp: I think we should leave to browsers to figure it out. 16:40:08 +1 to leave to browsers 16:40:25 IJ: I was not suggesting a requirement, only asking if people are experimenting around this 16:41:37 https://w3c.github.io/webpayments-payment-apps-api/#selection 16:41:47 AdamR: We should not encourage inherently unsafe behavior 16:42:50 IJ: I need to fix this: "If the user selects an unregistered recommended payment app, the user agent SHOULD offer the user an opportunity to register it." 16:42:54 ..that is now how it works. 16:43:26 q? 16:43:40 IJ: Should we say anything in 9.2? 16:44:00 Mathp: Where the spec could bring value is around security (e.g., origin information) 16:44:23 ..if we encourage implementers to display origin or security status, it mitigates the issue around selecting and facilitating selection of payment apps 16:44:43 https://w3c.github.io/webpayments-payment-apps-api/#selectable-app-information-display 16:46:02 IJ: Is the requirement to display origin information about each payment app? 16:47:19 Mathp: Maybe the requirement is not during *selection* but rather when the app is running 16:47:31 https://w3c.github.io/webpayments-payment-apps-api/#payment-app-authenticity 16:47:54 IJ: I could see advice there that payment apps should show users their origins when running 16:47:57 Mathp: +1 16:48:14 Action: Ian to write up a proposal for a security consideration on payment app origin 16:48:17 q+ 16:48:24 ack roy 16:49:31 /me missed the question 16:50:28 Roy: For tokenized spec (and possibly other payment methods), app implementers don't have merchant information 16:50:35 ...these are requests from "the internet at large" 16:50:45 ..have we thought about providing origin information to the payment app 16:51:26 https://w3c.github.io/webpayments-payment-apps-api/#dfn-app-request-data 16:51:34 10.1 Payment App Request Data 16:51:57 IJ: Origin information of merchant is available to payment app 16:51:59 q? 16:52:48 Proposed: Close issue 14 with no change 16:52:52 https://github.com/w3c/webpayments-payment-apps-api/issues/14 16:53:47 AdrianHB: The security risk is that users accidentally set defaults to pay 16:54:39 IJ: The flow I hear that is harmful is: 16:54:47 - merchant calls PR API without user interaction 16:54:57 - app is launched automatically since one matching app only 16:55:18 - app automatically returns card information since configured to do so for that origin without further user interaction 16:55:53 AdrianHB: I think we need to say something about user agents taking into account both origin and payment method when the user sets up a default payment app 16:57:48 q+ 16:57:51 +1 I don't think we should PREVENT anything but provide some guidance on security issues to watch for 16:58:17 IJ: Feels to me that the whole flow from pr API to payment response data has to have SOME user interaction 16:58:28 AdamR: But buttons can be mislabeled 16:58:54 Mathp: I am hearing for PR API that there needs to be explicit confirmation from the user to pay (e.g., "You are about to pay with Amex. Is that ok?" 16:58:57 ack con 16:59:08 conorhwp: I need to go....thanks all! 16:59:23 I have made the request to generate http://www.w3.org/2017/01/12-apps-minutes.html Ian 16:59:25 Have to go too I'm afraid 17:00:00 Ian: Explicit or Implicit confirmation -> user sees the pre-selected payment app 17:00:29 IJ: Does someone want to raise the PR API issue? 17:00:43 https://github.com/w3c/browser-payment-api/issues 17:00:59 IJ: Should I register an issue? 17:01:17 Mathp: I can have a look at the spec and raise and issue if needed 17:01:34 ACTION: Mathieu to review PR API to see if required user confirmation is there, otherwise raise and issue 17:02:38 IJ: Then Payment App API spec can say "If the app is configured to return response data automatically, user agent needs to take into account confirmation per PR API." 17:02:53 AdamR: We explicitly want to enable 1-click scenarios. 17:03:30 ...the model I have in my head is camera access 17:03:40 ...the way it works today is "for this origin, don't ask me, just do it." 17:04:03 ...I am proposing we can give the user a stateful config but absent that there needs to be confirmation 17:04:30 Mathp: So I am hearing a combination of a payee origin + payment app origin is sufficient for automation 17:04:41 AdamR: If the user says "yes, for this origin always grant access to this payment app" 17:05:27 ...automatic payment is analogous to a merchant with card on file using it to get paid without further interaction from me. 17:05:37 I need to roll out, see you all next thursday 17:06:06 rrsagent, make minutes 17:06:06 I have made the request to generate http://www.w3.org/2017/01/12-apps-minutes.html Ian 17:06:11 rrsagent, set logs public 17:25:54 rrsagent, bye 17:25:54 I see 3 open action items saved in http://www.w3.org/2017/01/12-apps-actions.rdf : 17:25:54 ACTION: Ian to write to the web payments WG and suggest that people list their projects there (when they can) [1] 17:25:54 recorded in http://www.w3.org/2017/01/12-apps-irc#T16-29-42 17:25:54 ACTION: Ian to write up a proposal for a security consideration on payment app origin [2] 17:25:54 recorded in http://www.w3.org/2017/01/12-apps-irc#T16-48-14 17:25:54 ACTION: Mathieu to review PR API to see if required user confirmation is there, otherwise raise and issue [3] 17:25:54 recorded in http://www.w3.org/2017/01/12-apps-irc#T17-01-34 17:25:59 zakim, bye 17:25:59 leaving. As of this point the attendees have been Ian, Frank, Mathieu, Rouslan, Pascal, Roy, mathp, Conor, AdamR, AdrianHB 17:25:59 Zakim has left #apps