15:16:13 RRSAgent has joined #wpwg 15:16:13 logging to http://www.w3.org/2017/05/09-wpwg-irc 15:16:25 Meeting: Tokenization Task Force 15:16:50 agenda: https://lists.w3.org/Archives/Public/public-payments-wg/2017May/0025.html 15:27:37 present+ 15:28:00 mweksler has joined #wpwg 15:30:17 present+ mweksler 15:31:02 present+ oyiptong 15:31:06 present+ holger 15:31:37 present+ Manash 15:31:55 present+ cweiss 15:32:34 present+ Roy 15:32:40 present+ Steve 15:34:06 present+ Sophie_Amex 15:34:34 Roy has joined #wpwg 15:34:52 shift4sms has joined #wpwg 15:34:54 present+ Sachin_Ahuja 15:35:00 Manash_Mastercard has joined #WPWG 15:35:27 zakim, who's here? 15:35:27 Present: Ian, mweksler, oyiptong, holger, Manash, cweiss, Roy, Steve, Sophie_Amex, Sachin_Ahuja 15:35:28 Sophie has joined #wpwg 15:35:30 On IRC I see Manash_Mastercard, shift4sms, Roy, mweksler, RRSAgent, Zakim, cweiss, adamR, davidillsley_, dlongley, manu, hober, dlehn, ShaneM, trackbot, schuki, Ian, mkwst, 15:35:30 ... Dongwoo, slightlyoff, adrianba, oyiptong, nicktr, emschwartz, JakeA 15:35:51 Sachin_Ahuja has joined #wpwg 15:35:58 present+ Keyur_MC 15:37:08 holger has joined #WPWG 15:37:13 keyur has joined #wpwg 15:37:37 Topic: check in on actions from last week 15:37:49 Sachin: Chatted with MichelW. Have some draft diagrams 15:38:10 ...need seems to be leaning toward a tokenization 15:38:47 ...solution enabling non-pci compliant merchants to 15:38:55 ...participate in this system reusing their existing PSPs 15:39:08 +1 15:39:46 Roy: Makes sense :) 15:39:51 +1 15:40:23 present+ Ken 15:41:12 [No opposition to that position] 15:41:23 Ken has joined #wpwg 15:41:55 Sachin: Within masterpass we have a construct of converting creds into an opaque identifier that we pass back to the merchant along with some identifying information about the payment method (e.g., last4 and brand ID) 15:42:12 ...the idea is that not only MC but other PSPs that provide hosted page functionality provide similar services 15:42:22 ...the idea was "let's try to see whether we can come up on the format" 15:42:47 ...would not impact merchants, but those participating from a wallet/PSP perspective would need to follow this 15:43:16 ..this is fundamentally not about network tokenization; that would happen behind the scene between PSPs and networks 15:43:46 [We review a flow diagram] 15:44:09 Keyur: User registers a payment method (via payment app) 15:44:33 ..note that wallet provider or PSP can provide payment apps 15:44:40 ....payment app stores credentials 15:44:46 ...merchant PSP does processing 15:44:57 ...mediator (browser or other) is user-controlled 15:45:06 ...there's also an acquirer 15:45:28 [User interaction phase] 15:45:46 ...merchant does canmakePayment..if ok then calls PR API 15:46:04 shift4sms_ has joined #wpwg 15:46:07 ...identifies a tokenization payment method 15:46:15 shift4sms has joined #wpwg 15:46:18 ...the data includes PSP identifier (which PSP the merchant supports) 15:46:43 shift4sms has joined #wpwg 15:46:59 IJ: Can that be a list of PSPs? 15:47:07 Keyur: Yes 15:47:49 Manash: So far the discussion has focused on gateway tokens and network tokens....are there other tokenization processes we should be considering? 15:48:21 Sachin: Good point. We've not delved into it. But one idea is that network token is "under the hood" 15:48:34 Manash: Another point is "what happens when tokenization is not supported" 15:48:43 ...eg., dynamic expiry and dynamic CVV 15:49:02 ...so we should be taking into account the available security mechanisms. 15:49:16 ...I think we should taken into account all these mechanisms that the merchant might accept 15:49:37 Sophie: I'm familiar with various token types. I am struggling to understand what "gateway token" means. 15:50:12 mweksler: That's more familiar to merchants who do "vaulting" whereby the merchant integrates with the PSP and lets the PSP collect card data from the user 15:50:22 ...the PSP then shares an opaque id with the merchant 15:50:34 Manash: Network token here refers to EMVCo token 15:51:25 Keyur: In the flow, when the merchant sends a payment request, the merchant does not know whether the PSP supports network tokens 15:51:33 ...so the merchant refers to the PSP(s) 15:52:10 ...so matching by mediator would include determination that "app supports communication with the PSP" 15:52:23 ...then the user chooses a payment app 15:52:31 ..there could be an option where some payment apps have multiple cards 15:53:04 ...user performs card selection 15:54:03 ...once app has been selected, payment request data + card identifier sent to payment app 15:54:27 ...payment app returns an opaque token identifying this translation, also card brand, last fours and setupURL 15:55:47 s/token identifying this transaction/token for the card/ 15:56:00 ...then payment response goes to merchant/PSP with token, etc. 15:56:41 ...when the token is generated by the payment app, it would look up the PSP .... then response indicates which PSP was used. 15:57:08 ..the returned token goes to that PSP 15:57:22 q+ to mention matching algo 15:57:29 q+ to ask more about PSP identifier 15:58:03 Keyur: PSP can act like a payment app (@@Ian missed it@@). But when PSP does not act like a payment app, 15:58:29 ...the PSP would get a URL, fetch the @@, sign it... 15:58:38 ..and this would let wallet verify identity of PSP 15:59:01 ...in the PSP supports a network token format, then the PSP would tell that to the payment app provider 15:59:14 ...so the PSP indicates support for network token (or not). 15:59:21 Sachin_Ahuja has joined #wpwg 15:59:27 ...if so, then the response (step 20) would be a network token 15:59:34 ...if not, then the response would be FPAN 15:59:44 ...the reason we are asking the PSP to give us the details (whether EMV supported or not) 15:59:54 ..because the PSP is the only entity integrated into the acquirer 16:00:25 q+ 16:00:49 Mweksler: AirBNB does use a PSP 16:01:12 oyiptong: We use PSPs, there's even a desire to use multiple PSPs 16:01:47 Manash: Depending on what token is being served, it changes the payload 16:01:59 ...e.g., EMV-based tokens would have different fields passed on to the PSP 16:02:18 Keyur: Yes, the payload would be different but the response format would support both result types 16:02:58 q+ 16:03:19 q+ 16:04:17 ack me 16:04:17 Ian, you wanted to mention matching algo and to ask more about PSP identifier 16:04:30 IJ: How does Payment App talk to PSP? What is the identifier about? a URL? 16:04:34 ack oy 16:04:45 oyiptong: Thanks for this diagram, I think it represents most of what we want to surface to merchants 16:05:25 ...being PCI/DSS compliant is a requirement on the backend and keeping the system separate is a valuable tool...I think this will interest other merchants 16:05:33 ...so as an area of focus, I like that we are talking about gateway tokens.... 16:05:43 ...is there any move towards "defining" the choices of PSPs 16:05:59 q? 16:06:01 ack mw 16:06:26 mweksler: I would really like to continue going through the diagram in more detail; lots of new concepts that probably make sense 16:06:37 ...I would like to have a better understanding of the Happy Path 16:06:42 ...but also of the StepUp path 16:06:59 q? 16:07:11 ack shi 16:07:28 q+ Ken requests that Ian reprint the link for the diagram, please... 16:07:46 Steve: Nobody has mentioned issuer today...has that been dropped off...how is that handled differently? 16:07:51 ...are there more use case examples for this? 16:08:00 q+ to requests that Ian reprint the link/URL for the diagram, please.. 16:08:05 ...I'm a gateway provider...I'm having a hard time knowing why I need to know the difference between token types 16:08:06 q? 16:08:29 Sachin: I think that we are focusing here on creating an opaque identifier that behaves more like a gateway token than anything else, but provides 16:08:35 support for network tokens 16:08:56 ...it will be the responsibility of payment app provider and PSP to exchange appropriate information. 16:10:31 IJ: I'd like some high-level prose and can help 16:10:33 +1 16:10:34 Mweksler: +1 16:10:41 q? 16:10:54 +1 on hour long 16:10:59 +1 16:11:02 +1 16:11:08 PROPOED: 1 hour long call starting next week 16:11:11 SO RESOLVED 16:11:21 ACTION: Ian to extend the call to one hour 16:11:21 '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:12:23 ack Ken 16:12:23 Ken, you wanted to requests that Ian reprint the link/URL for the diagram, please.. 16:12:30 IJ: Let's put diagram in repo 16:12:47 Topic: Next meeting 16:12:50 16 May, for 1 hour 16:13:07 RRSAgent, make minutes 16:13:07 I have made the request to generate http://www.w3.org/2017/05/09-wpwg-minutes.html Ian 16:13:10 RRSAgent, set logs public