15:31:08 RRSAgent has joined #wpwg 15:31:08 logging to http://www.w3.org/2017/08/08-wpwg-irc 15:31:11 Zakim has joined #wpwg 15:31:15 Meeting: Tokenization Task Force 15:31:57 mweksler has joined #wpwg 15:32:07 Chair: Ian 15:32:13 Present+ 15:32:15 present+ oyiptong 15:32:18 present+ mweksler 15:32:37 present aylver 15:33:11 present+ alyver 15:33:18 zakim, who's here? 15:33:18 Present: Ian, oyiptong, mweksler, alyver 15:33:20 On IRC I see mweksler, Zakim, RRSAgent, alyver, AdrianHB, cweiss, adamR, pea13, canton_, dlongley, manu, dlehn, hober, nicktr, emschwartz, adrianba, Ian, trackbot, Dongwoo, mkwst, 15:33:20 ... oyiptong, JakeA, ShaneM, natasha, slightlyoff 15:33:21 agenda: https://lists.w3.org/Archives/Public/public-payments-wg/2017Aug/0004.html 15:39:34 https://github.com/w3c/webpayments-methods-tokenization/wiki 15:42:10 Topic: Who would implement the tokenization payment method? 15:42:14 IJ: Who? 15:42:41 mweksler: The network tokenization spec is the longterm direction of the industry 15:42:53 ...the move is towards one-time transactions with strong auth and away from card on file 15:43:16 ...so the network tokenization spec aligns with that long term vision 15:43:33 ..but during a transition period, there is a question of how to onboard merchants 15:44:12 ...gateway tokenization spec is a transition piece while there is still card on file 15:44:21 ...slightly more secure than raw PAN 15:44:32 q+ 15:44:44 ...we should also talk with more gateways 15:44:52 ack aly 15:45:22 alyver: I think any non-consumer brands will not expect to appear in payment apps 15:45:47 ...browsers could implement the tokenization spec 15:45:57 q+ 15:46:02 ack oyiptong 15:46:27 oyiptong: I think that browsers could play a role here. 15:48:55 q+ 15:49:46 IJ: Maybe we recast this as "network tokens from lots of payments apps" and "transition basic card+" with more browser role 15:49:47 ack oyiptong 15:50:21 oyiptong: I was wondering what's going on in the payment app realm. I something like gateway tokenization lowers cost of payment app development. 15:53:12 IJ: Perhaps we could think about browsers taking basic card data from payment apps and encryption 15:53:27 mweksler: There are different ways merchants will use data on the back end 15:53:31 ...with gateway tokens they need to have a relationship with gateways 15:53:43 ...so in that sense, it's a bit more than "basic card+" 15:53:47 ..due to these relationshiops 15:55:45 q+ 15:56:16 IJ: Can we talk about different use cases: (1) easier comms with gateways (2) pci scope (e.g., "just encryption") 15:56:25 q- 15:56:42 q+ 15:56:46 mweksler: Would be good if PAN can be encrypted in way only gateway can decrypt 15:57:16 ...freeing merchant of PCI scope 15:57:18 ack oyiptong 15:57:29 oyiptong: My thought was originally more of Basic Card+ 15:58:16 ...benefit is activation cost is much lower 16:00:21 q+ 16:00:51 IJ: I am hearing three things: 16:00:55 1) Browser encryption of PAN 16:01:03 2) Gateway tokens (we don't have clamoring yet) 16:01:11 3) Network tokens (makes sense from variety of apps) 16:01:14 ack alyver 16:01:47 alyver: In case of Android pay, merchant passes in key, google encrypts with key, merchant decrypts payload. 16:01:57 ..with apple pay, there is a certificate signing dance 16:02:23 ...to help with PCI scope, the gateway needs to do the key parts 16:05:52 mweksler: Parties won't want to do one implementation per gateway; need sense that gateways would be interested in supporting this 16:07:28 Framing is: easier for people to vault cards 16:07:34 q+ 16:07:41 Manash_MC has joined #WPWG 16:09:27 q+ 16:09:33 IJ: Encryption and PCI go together. What are other ways to make it easier to let merchants take up gateway services? 16:09:34 ack me 16:09:35 ack oyiptong 16:10:14 oyiptong: there is technology overhead and registration overheard 16:10:20 s/overheard/overhead 16:12:21 IJ: How do we lower integration costs (as a benefit)? 16:12:34 mweksler: If you accept basic card, you have a relationship with a gateway. 16:13:09 ..if you do basic card+ you need to provide merchant account information and make a different API call with the response data you get back from PR API 16:15:01 ========= 16:15:28 1) PAN encryption using merchant-specific key from gateway 16:15:36 a) Payment app returns basiccard+1 16:15:59 b) Browser returns basiccard+ (this is at least transitional0 16:16:41 2) Longer term vision is network tokens 16:16:55 3) Gateway tokens not part of the discussion 16:17:07 q+ 16:17:11 ..but we would seek gateway support for basiccard+ 16:17:17 ack oy 16:17:31 oyiptong: I was wondering about this longer term vision for network tokens 16:17:46 ..how does network token solve subscription use cases? 16:17:50 present+ manash 16:18:12 manash: There are two forms of network tokens - first is cloud-based, limited data sent to merchant; second is hardware based with more data 16:18:26 ...data includes information about 1-time v. recurring 16:18:55 (IJ: Maybe we add a fourth bullet, like "and next layer would involve strong auth signals") 16:19:32 ...when 3ds 2.0 is launched, at transition time, the 3DS 2.0 flow would be initiated for the first time, but the same AAV can be used for subsequent transactions. 16:21:21 Q. In encryption case is the entire basic card respond blog encrypted or just the PAN? 16:21:43 Manash: Valid point about payment apps. You don't want to increase the merchant burden. 16:22:08 ..the format that is returned should be the same whether encrypted PAN or EMV Token 16:22:47 ...each browser would have to create a dynamic PAN and cloud-based crypto and expiry for that token. 16:24:38 q+ 16:25:47 ack mwek 16:27:04 mweksler: +1 to making it easy to encrypt basic card data 16:27:08 q? 16:27:41 Topic: Any updates? 16:28:01 Manash: We'd like to create an end-to-end experience leveraging some token specs we have 16:28:27 ...I am also looking at how 3DS 2.0 functions 16:28:37 ...in this ecosystem 3DS is mandatory in some markets 16:29:23 ...3DS 2.0 may include some caching for better user experience 16:29:34 ...probably in the next month we will have a high-level flow we can share with the group 16:31:31 IJ: I would like to invite our FIDO colleagues to chat about FIDO + payment request + 3DS 2.0 16:31:33 +1 16:31:40 ACTION: ian to reach out to FIDO colleagues to set up a call 16:31:40 'ian' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., IFSF-EFT-WG-Lead, ijacobs, ijmad). 16:32:59 q+ 16:33:08 Topic: Next steps 16:33:15 IJ: Reframe gateway? Reframe mission statement? 16:33:30 oyiptong: I will take a look; reframing makes sense 16:35:54 ACTION: Ian to update the mission statement with the above narrative 16:35:55 'Ian' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., IFSF-EFT-WG-Lead, ijacobs, ijmad). 16:36:05 ACTION: oyiptong to review the gateway params spec and reframe it 16:36:06 Created ACTION-64 - Review the gateway params spec and reframe it [on Olivier Yiptong - due 2017-08-15]. 16:36:13 Topic: Next meeting 16:36:15 22 August 16:36:20 RRSAGENT, make minutes 16:36:20 I have made the request to generate http://www.w3.org/2017/08/08-wpwg-minutes.html Ian 16:36:22 RRSAGENT, set logs public 16:41:15 mweksler has joined #wpwg 16:49:08 alyver has joined #wpwg 17:21:16 alyver has joined #wpwg 17:32:17 alyver has joined #wpwg 18:05:21 alyver has joined #wpwg 18:28:29 alyver has joined #wpwg 18:33:37 adamR has joined #wpwg 18:35:44 alyver has joined #wpwg 18:38:24 alyver has joined #wpwg 19:08:41 Zakim has left #wpwg 20:50:14 oyiptong? 20:50:26 Ian: ? 20:50:29 got a few mins? 20:50:41 yes 20:50:44 \o/ 20:50:44 one sec 20:50:47 let me get a room 20:50:51 ok 20:52:43 i'm here 20:52:46 webrtc? 20:58:34 AdrianHB has joined #wpwg 20:59:43 AdrianHB has joined #wpwg 22:33:28 dlehn has joined #wpwg