15:30:04 RRSAgent has joined #wpwg 15:30:04 logging to http://www.w3.org/2017/09/19-wpwg-irc 15:30:25 Meeting: Tokenization Task Force 15:30:27 Chair: Ian 15:30:35 present+ Chris_Marconi 15:30:37 present+ 15:30:40 present+ oyiptong 15:31:01 Agenda: https://lists.w3.org/Archives/Public/public-payments-wg/2017Sep/0032.html 15:31:06 RRSAGENT, make minutes 15:31:06 I have made the request to generate http://www.w3.org/2017/09/19-wpwg-minutes.html Ian 15:32:14 alyver has joined #wpwg 15:32:59 present+ Ken 15:33:21 present+ LauraTownsend 15:33:24 present+ alyver 15:33:27 regrets+ NickTR 15:34:00 Ken_ has joined #WPWG 15:34:22 regrets+ Manash 15:35:15 topic: Encrypted Card 15:35:16 https://github.com/w3c/webpayments-methods-tokenization/wiki/encrypted_card 15:35:29 Olivier: I updated some terminology 15:35:37 ...from Vault Provider to Key Provider 15:35:50 ...I added some descriptions to encryption mechanisms 15:36:25 https://user-images.githubusercontent.com/9365/30331535-f15110d6-978c-11e7-8ed0-a5aaa28547d6.png 15:36:52 ...the encryption exchange is either done right after the browser hands control to the payment handler, who contacts the key provider 15:37:10 ...or there's an option (3) where the payment method data includes the information necessary to generate the encrypted card data 15:37:22 ...that would be given via the parameters (shown in IDL) 15:37:24 https://github.com/w3c/webpayments-methods-tokenization/wiki/encrypted_card#3-encryption-options-specified-in-paymentmethoddata 15:37:38 ..and this data would plug into the Web Crypto API 15:38:04 ...the idea is that the merchant provides the key and algo information up front, but cannot decrypt the payload, and a key provider is in the loop later 15:38:13 ..so that merchant page is outside PCI-DSS scope 15:38:23 q+ 15:38:35 ack alyver 15:38:37 lte has joined #wpwg 15:38:46 alyver: Question on the three methods - from my experience #3 is the more common use cases 15:38:49 s/cases/case 15:39:00 ...when I think of Android pay, for example, #3 is how it's done 15:39:10 oyiptong: I think #3 is the best way to do this; it's easy 15:40:50 IJ: So have you been socializing this? Is it interesting? 15:41:11 oyiptong: From what I've understood, there is interest. E.g., option #3 is desirable for small merchants. It's simple and low-cost to implement. 15:41:21 ...we've also spoken with a payment processor who expressed interest. 15:42:22 IJ: Oliiver, what feedback would you most like? 15:42:37 oyiptong: Viability (e.g., from processor POV) 15:42:47 ...also feedback from merchants on the PCI DSS scope reduction 15:42:55 ..also whether the payment method data declaration makes sense 15:43:06 ..and also from traditional payment gateways on whether valuable. 15:43:48 ACTION: Chris to review the proposal and send comments. 15:43:49 Created ACTION-66 - Review the proposal and send comments. [on Chris Marconi - due 2017-09-26]. 15:44:09 IJ: You can use the issues list 15:44:20 q+ 15:44:24 ack oyiptong 15:44:37 oyiptong: One thing I want to clarify - the tokenization extension use case is only an EXAMPLE of an extension. 15:44:47 IJ: Please clarify the two parts 15:45:01 oyiptong: First part is proposal to encrypt card data (stops after "discussion" section). 15:45:29 ..the next part is called "tokenization extension use case" ... which is there for discussion but should not be considered part of the "encryption" part of the proposal (part 1). 15:45:58 IJ: How long for your review, Chris? 15:46:02 Chris: End of this week 15:46:09 Topic: Tokenization 15:46:23 IJ: Postponed until early October 15:48:04 Topic: Adrian Hope-Bailie idea 15:48:12 https://lists.w3.org/Archives/Public/public-payments-wg/2017Sep/0032.html 15:49:55 present+ Keyur 15:51:18 q+ 15:51:24 IJ: Any initial thoughts on the idea of an indirection through the gateway to avoid exposing PAN? 15:51:29 ==== 15:51:29 1) The handler sends the card details of a secure connection to 15:51:29 the gateway (using a URL provided in the payment request) and 15:51:29 gets back a reference of some kind which it passes to the 15:51:30 merchant in the PaymentResponse. 15:51:31 2) The merchant then submits the payment to the gateway with the 15:51:32 reference instead of the card details and also all of the other 15:51:34 contextual data that the gateway requires. The gateway would then 15:51:36 use the reference to loo kup the card details it has in temporary 15:51:38 storage and process the payment. 15:51:40 This is subtly different in that the reference would be a single 15:51:42 use value for a set amount. The gateway may also provide the 15:51:44 merchant with a customer identifier that is consistent across 15:51:46 multiple uses of the same card to assist the merchant with 15:51:48 customer engagement. 15:51:50 ==== 15:51:54 oyiptong: Payment method request data includes a URL, payment handler communicates with that URL, passes a ref back to the merchant. 15:52:01 ..sounds similar to the tokenization flow 15:52:01 q+ 15:52:08 ...to the tokenization extension use case. 15:52:21 ...minus the encryption part 15:52:34 https://w3c.github.io/webpayments-methods-tokenization/index.html 15:52:43 https://user-images.githubusercontent.com/9365/28303430-031ea6c8-6b48-11e7-8d41-f7558ddd76db.png 15:53:23 oyiptong: In that diagram, after the browser hands over control, the payment handler contacts a service (here, a gateway) 15:53:46 ...sends the PAN and gets back a reference. (Originally it was a token; AHB's proposal suggests that it's a reference possibly of another type) 15:54:35 ack aly 15:54:38 ack oy 15:54:54 alyver: This seems to be the same as the gateway tokenization flow we discussed before, as oyiptong pointed out. 15:56:21 IJ: There was not support for gateway proposal due to gateways not stepping up to do payment handlers. I'm not sure why this proposal is different. 15:56:47 alyver: There might be an opportunity to define a standard for what data is sent to the gateway 15:56:58 (IJ thinks Olivier had something like that in the gateway proposal) 15:57:14 ...I also think the browser could act as a payment handler here, and not integrate with N providers; just integrating with one API. 15:58:11 https://github.com/w3c/webpayments-methods-tokenization/wiki/gateway_params#data-exchanged-between-payment-app-and-tokenization-provider 15:59:23 Topic: Network tokenization 15:59:37 Keyur: We are having some discussions, and trying to implement in a real-life scenario 15:59:48 ...merchant can get a token and process it (or their PSP can) 16:00:01 ..right now we are looking at whether to use test system or production site for demo 16:00:36 ...right now we are using a custom payment method spec; we would break it back to the task force for discussion 16:00:57 topic: TPAC 16:01:19 https://github.com/w3c/webpayments/wiki/FTF-Nov2017 16:02:00 IJ: What should we present? 16:02:14 q+ 16:02:19 ack oyiptong 16:02:45 oyiptong: I would like to present encrypted card ... Browser implementation would be very interesting (autofill) 16:03:00 ...it would be great to get supporting statements 16:03:13 IJ: what is strategy for securing supporting statements? 16:03:18 oyiptong: Identify stakeholders 16:03:37 ...we can also ask browsers what would convince them (then get those statements) 16:04:00 IJ: What about code to show demo or ease of use by merchant? 16:04:28 oyiptong: I can implement a shim 16:05:37 ACTION: Olivier to implement some example code to show how it works 16:05:37 'Olivier' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., omaas, oyiptong). 16:07:32 q? 16:07:39 topic: Next meeting 16:08:15 Tuesday, 3 October 16:08:29 +1 16:08:45 RRSGENT, make minutes 16:08:48 RRSAGENT, set logs public 16:10:37 RRSAGENT, make minutes 16:10:37 I have made the request to generate http://www.w3.org/2017/09/19-wpwg-minutes.html Ian 16:10:38 RRSAGENT, set logs public 16:14:27 AdrianHB has joined #wpwg 16:52:53 alyver has joined #wpwg 18:06:42 AdrianHB has joined #wpwg 18:23:39 Zakim has left #wpwg 18:44:38 AdrianHB has joined #wpwg