13:59:53 RRSAgent has joined #wpwg 13:59:53 logging to http://www.w3.org/2017/09/21-wpwg-irc 14:00:06 Meeting: Web Payments Working Group 14:00:18 AdrianHB has joined #wpwg 14:00:30 Chair: AdrianHB 14:00:32 Agenda: https://github.com/w3c/webpayments/wiki/Agenda-20170921 14:00:35 Scribe: Ian 14:01:08 present+ 14:01:10 present+ NickTR 14:01:14 present+ Manu 14:01:14 present+ Manu 14:03:01 present+ DaveLongley 14:03:31 present+ Ken 14:03:34 present+ ChrisMarconi 14:04:00 present+ AdrianHB 14:04:02 present+ alyver 14:04:03 present+ 14:06:41 Topic: Digital Bazaar Polyfill 14:07:21 Ken has joined #wpwg 14:07:51 Manu email: https://lists.w3.org/Archives/Public/public-payments-wg/2017Sep/0042.html 14:08:31 present+ DavidLehn 14:08:38 Ken has joined #wpwg 14:08:46 Manu: We are trying to hit as many browsers as we can, with different form factors 14:08:52 ...UNTIL there is native support for PR API 14:09:02 lte has joined #wpwg 14:09:03 ...addresses both PR API and Payment Handler 14:09:06 ...three scenarios: 14:09:12 1) Neither PR API nor PH implemented 14:09:17 present+ David_Lehn 14:09:18 2) PR API implemented but not PH 14:09:48 3) Third party payment handlers supported 14:10:00 ...polyfill does its best to maximize functionality 14:10:29 ...in today's demo we run the polyfill in Safari. Safari does not have service workers 14:10:46 ...what this demonstrates is that even with some core functionality missing, this is still possible 14:10:55 present+ Roy 14:11:02 q? 14:11:16 present+ LauraTownsend 14:12:36 [Manu adds cards] 14:12:52 present+ dezell 14:13:05 q? 14:13:20 [Part II of demo - click on the buy button] 14:13:58 Manu: We do some pre-caching to speed up user experience 14:15:40 Manu: deployable now 14:15:56 ...target audience is 2.8B people 14:16:20 ...polyfill almost entirely JavaScript 14:16:30 ...nothing server side 14:16:53 ... v fast to iterate and release within a week 14:17:04 q+ 14:17:24 q+ 14:17:34 ack de 14:18:01 Manu: There is no backing database 14:18:08 dezell: what's not js? 14:18:12 ...we chose not to do that; information is stored in indexdd or or lock storage 14:18:17 s/lock/local 14:18:27 Manu: only the web server 14:18:30 ack ken 14:18:35 Ken: This is very interesting; thank you 14:18:55 Ken: How does this affect top of wallet selection by the user? 14:19:09 Ken: How would this affect the value proposition for merchants, payment instruments? 14:19:27 Manu: Regarding top-of-wallet...that's a topic of ongoing discussion in the group. 14:19:34 ...whatever consensus there is, we can impelment. 14:19:41 ...we are preferring what the user wants 14:20:05 ...some options: 14:20:09 1) Show the entire list, randomized 14:20:38 2) Sort the cards based on what the user has selected most frequently 14:20:53 ...we could store user information client side 14:21:10 3) Merchants can signal preferences which are reflected on the user side 14:21:24 ...we would only do that if there is WG consensus 14:21:32 ...so at a high level, we will defer to the WG 14:21:56 Manu: regarding value proposition 14:22:01 ...I don't think much changes for merchants here 14:22:49 ...the polyfill is not quite ready, but in a few months after testing, etc. the WG can promote the API with the polyfill as a transition path 14:23:06 ...there are security and performance advantages of native implementation 14:23:16 ...but I think the value proposition for DEVELOPERS goes up 14:23:30 ...they can start to experiment 14:24:32 present+ AnaGrace 14:24:59 q+ to ask about hosting and origin security 14:25:00 Ken: My understanding is that this is intended as an interim solution. But I see this as potentially being used on a permanent basis. 14:25:27 Manu: The plan is that if the WG's features are implemented, then native implementations will take over, and the polypill will defer to native 14:26:07 ...there is a possibility that, if some of the browser vendors decide they don't want to implement something like payment handlers, the polyfill could support third party payment apps in those browsers. 14:26:24 ...it could also support experimentation 14:26:46 ...if there are enough people wanting to experiment with something behind a flag, the polyfill could still support it 14:27:15 ...we could also extend the polyfill to support other features not discussed in the WPWG 14:27:24 ..one example could be around credential handling 14:28:00 ..there is a lot of similarity between handing payment information to the merchant and handing assertions to the merchant 14:28:47 ...we could use this polyfill framework to exchange social data. 14:29:09 (Ian thinks that where the polyfill departs from WG activity; that should be signaled somehow) 14:29:25 AdrianHB: It would make sense for this to be hosted at the same origin irrespective of where used 14:29:36 ...does this need to be hosted in one place, or could merchants host it themselves and still expect it to work? 14:29:54 Manu: Our biggest concern about the polyfill, there needs to be a payment mediator website. 14:29:57 ..there should only be one of those 14:30:04 ...we are suggesting that we use one payment mediator site 14:30:09 ..there's a security concern 14:30:35 ...if someone were to get access to that site, because we do things like basic card and don't do end-to-end encryption, people could read data 14:30:45 ...through a man-in-the-middle attack. 14:30:56 ..if we had end-to-end encryption, details would not be available 14:31:16 ...this is no different from someone injecting a script on other sites 14:31:25 q+ to ask about E2E 14:31:43 ...we use mitigations like code signing, continuous monitoring (of hashes of scripts) 14:32:10 ...we can do things like use service workers for browsers that have them to only download the polyfill code once unless manually reloaded 14:32:24 ..we'd like to share the burden of running the polyfill site with other companies 14:32:24 q+ 14:32:30 ack AdrianHB 14:32:30 AdrianHB, you wanted to ask about hosting and origin security 14:32:30 ack me 14:32:51 Manu: There are parts of the polyfill hosted on the merchant site, and parts hosted on the payment handler side. 14:33:04 ..the only part we can't do that with is the mediator code, which is small but centralized 14:33:16 AdrianHB: The mediator code is client-side JS, right? 14:33:35 ...it seems like you could resist tampering with hash-based protections 14:33:43 ..sub resource integrity 14:33:44 ack de 14:33:44 dezell, you wanted to ask about E2E 14:34:00 dezell: What is in your mind regarding end-to-end encryption? 14:34:12 ...do you think some of the tokenization discussions in the WG would help? 14:34:26 Manu: There are two levels of the concern. One is doing the bare minimum in protecting the card data.... 14:34:32 ...tokenization would help 14:34:45 ..what we'd really like to see is complete end-to-end encryption 14:35:03 (See the nascent encrypted card spec => https://github.com/w3c/webpayments-methods-tokenization/wiki/encrypted_card ) 14:35:26 Manu: this is probably a new payment method 14:35:36 ack me 14:35:45 Ian: Just wanted to get a clarification... 14:36:15 Manu: Data passes through a third party, which is the mediator web site 14:36:32 IJ: Is that a source of concern? 14:36:43 Manu: It acts in the same role as the browser 14:36:54 ....the benefit for the payment mediator is that all the code can be verified 14:37:11 ...so it's a bit more open that proprietary browser code 14:37:16 ...but I do expect this to be a topic of debate 14:37:45 ..orgs that aren't comfortable with this don't have to use the polyfill. 14:38:10 Ian: Similarly, concerns raised as things going in the clear is the same as web forms are submitted today. 14:38:25 AdrianHB: Thanks Manu! 14:38:49 topic: TPAC 2017 14:39:05 Please register 14:39:06 https://www.w3.org/2002/09/wbs/35125/TPAC2017/ 14:39:51 https://www.w3.org/2017/11/TPAC/ 14:39:53 Ian: We are going up against DreamForce ... please reserve... room blocks are precious. 14:39:55 6 October break point 14:40:07 Ian: After that date, registration fee goes up, it gets harder and harder to attend. 14:40:20 https://github.com/w3c/webpayments/wiki/FTF-Nov2017 14:40:56 Ian: Rechartering the WG is something we'll discuss at TPAC. 14:40:57 topic: Draft Charter 14:40:57 https://w3c.github.io/webpayments/proposals/charter-2017 14:41:45 Ian: One of the gaps in the charter is new topics that the group should pick up... I'd like to work up introductory proposals so the group can go through them at the F2F meeting. 14:42:23 Ian: Let's get a sense from people about what they'd specifically like to be covered in the charter. W3C Members like specific deliverables... open ended charters create concerns around patents. 14:42:52 Ian: People that are interested in us covering certain topics should reach out to Chairs and me - we should make sure they're on the Agenda. You can type things in on the Agenda that you'd like to discuss. 14:43:11 Manu: When is the charter going to be finalized? 14:43:43 Ian: The Agenda will be finalized a week before the meeting... 14:44:25 IJ: I would like to start review in Dec and extend group; expect rechartered by Feb 14:44:26 q? 14:44:29 Ian: Charter expires on Dec 31st... I'd like to take a charter to management by 3rd week of November... start the review, which would go into January. When review starts, group extension is probably provided. 14:45:00 topic: Marcos' todo list before TPAC for PR API 14:45:00 https://github.com/w3c/payment-request/issues?q=is%3Aissue+is%3Aopen+label%3ACR-Exit 14:45:03 marconi has joined #wpwg 14:45:04 Would encourage everyone to review the the proposed revised charter 14:45:48 AdrianHB: We asked for comments on these before end of TPAC 14:45:58 IJ: Let's start walking through in calls up to TPAC 14:46:24 Roy: Not up to speed 14:46:43 ACTION: AdrianHB and chairs to check with Editors on how to manage this list 14:46:46 Created ACTION-67 - And chairs to check with editors on how to manage this list [on Adrian Hope-Bailie - due 2017-09-28]. 14:47:28 Ian: My interpretation of that date ... a couple of functions. We want substantive comments in as early as possible. It sets an expectation that we won't advance to PR until after that date. 14:47:37 Ian: I don't believe it means people can't comment after that date. 14:47:48 q+ to note that we don't want to cut comments off... 14:48:07 Ian: We set that date w/ TPAC in mind... to prompt comments. 14:48:25 Manu: Let's not use that date to say "we cannot further accept comments" 14:49:18 Ian: That's not the date that says we're going to leave CR... it's just a minimal date. 14:49:41 Ian: I don't think the process authorizes the group to stop listening to input, but the group... over time... is increasingly licensed to postpone things because the spec is maturing. 14:50:09 Ian: People can raise issues at PR, they can be taken into account, but it becomes more socially expected that things raised late in the process may not lead to changes. 14:50:51 AdrianHB: I think that interpreting it as a "minimum" time is the right way to do it 14:51:01 AdrianHB: I've done a blog post on the feature at risk 14:51:15 https://medium.com/@ahopebailie/currencysystem-is-at-risk-d29aebafdd38 14:51:47 Topic: Payment Apps Task Force next steps 14:51:53 AdrianHB: the task force has disbanded 14:51:59 ...henceforth those topics will move to this agenda 14:52:07 Topic: next meeting 14:52:24 AdrianHB: I suggest we meet next week and focus on TPAC agenda and charter 14:52:39 IJ: Let's also consider https://github.com/w3c/payment-request/issues?q=is%3Aissue+is%3Aopen+label%3ACR-Exit 14:52:52 Next meeting: 28 September 14:52:55 https://medium.com/@ahopebailie/currencysystem-is-at-risk-d29aebafdd38 14:53:02 [No regrets signaled] 14:53:05 RRSAGENT, make minutes 14:53:05 I have made the request to generate http://www.w3.org/2017/09/21-wpwg-minutes.html Ian 14:53:09 RRSAGENT, set logs publicd 14:53:11 RRSAGENT, set logs public 14:53:27 AdrianHB: Thanks Manu and Dave 14:53:33 RRSAGENT, make minutes 14:53:33 I have made the request to generate http://www.w3.org/2017/09/21-wpwg-minutes.html Ian 14:53:36 Thanks everyone, esp manu and dlongley 16:02:00 AdrianHB has joined #wpwg 16:48:15 Zakim has left #wpwg