15:31:56 RRSAgent has joined #wpwg 15:31:56 logging to http://www.w3.org/2017/06/06-wpwg-irc 15:32:02 Meeting: Tokenization Task Force 15:32:04 Chair: Ian 15:32:15 Agenda: https://lists.w3.org/Archives/Public/public-payments-wg/2017Jun/0001.html 15:32:20 present+ Clinton 15:32:21 present+ Ian 15:32:30 present+ Olivier 15:32:42 presnet+ Michel (CC) 15:32:52 present+ mweksler 15:33:01 present+ holger 15:33:02 present+ Michel (CC) 15:33:29 regrets+ AdrianHB 15:33:31 mweksler1 has joined #wpwg 15:33:33 present+ Roy 15:33:43 alyver has joined #wpwg 15:33:48 regrets+ Jean-Yves 15:33:59 present+ alyver 15:34:01 present+ Steve 15:34:50 not yet 15:34:57 present+ Manash 15:34:57 (password missing) 15:35:51 shift4sms has joined #wpwg 15:36:22 topic: Olivier's work on gateway params 15:36:36 https://github.com/w3c/webpayments-methods-tokenization/wiki/gateway_params 15:37:00 scribe: Ian 15:37:12 Ken_ has joined #wpwg 15:37:22 oyiptong: Michel and I met last week to talk about gateway params, we need to talk about server-side interactions 15:37:44 present+ Ken 15:38:02 oyiptong: We introduce the "gateway" into the network relationships 15:38:06 (We look at diagram) 15:38:10 https://cloud.githubusercontent.com/assets/9365/26812915/8dcef2bc-4a2f-11e7-98c3-eea00ea5b178.png 15:38:21 ...1. user requests a page from the merchant 15:38:34 ...2. merchant responds with a page with PR API that specifies gateway params 15:39:21 ...we need a merchantId, a public key to encrypt data, a gateway URL that the browser will invoke to send payload, and finally an optional param "environment" for testing 15:39:38 mweksler1 has joined #wpwg 15:40:00 ...if user chooses a payment app that supports the gateway payment method, the browser makes a request to the gateway 15:40:05 present+ Michel 15:40:25 ...the request has a few params (merchantId, card data (encrypted), environment) 15:40:46 ...we don't want data sent in the clear 15:40:56 ..the gateway then responds with a one-time use nonce 15:41:18 ...subsequently, the browser generates an id that it stores locally for subsequent uses 15:41:30 ..the browser then sends data back to the merchant 15:41:43 ...when the browser stores the ID it stores per merchant-origin, per gateway, and per instrument 15:41:43 q+ 15:41:59 ...the id is sent back to the merchant in the payment response 15:42:14 MANASH_MC has joined #WPWG 15:42:21 ...we also want a bank identification number so that merchants can do routing 15:42:37 ..the gateway nonce, the gateway URL (identifying the gateway) and contact information for the user 15:42:50 ...for sequent card uses, we can skip the gateway communication. 15:42:59 ..the payment request goes by without the nonce. 15:43:20 q+ 15:43:23 ...if there are any errors, it should appear as though the PR API has failed and the user should try again 15:43:29 ack me 15:44:27 IJ: Why is the browser doing things instead of the payment app (e.g., call out to the gateway and storage)? 15:44:43 oyiptong: We want this built into the browser. The payment method implementation would do this in a standardized way 15:44:46 ack Clinton 15:44:52 q+ 15:45:19 ClintonA: In subsequent requests, merchant makes a request to the browser, browser sends an ID back...how does the merchant know which gateway the token is associated with (initially or subsequently)? 15:45:38 oyiptong: The payment response includes a gateway identifier 15:46:07 ...it's returned by the browser for subsequent uses as well 15:46:25 q+ 15:47:16 ClintonA: If the relationship for uniqueness is gateway/merchant/product, there's a scenario which is that a cardholder for a particular merchant may be able to select a card for the merchant. But there may be three different gateways. The user simply selects the card..and the merchant says "I want a token for this gateway" 15:47:39 ..how does merchant say "I want token from his gateway" 15:47:47 oyiptong: Not part of this proposal but we could do so. 15:48:19 ...this proposal just shows one gateway Url but could be expanded for multiple 15:48:33 ..but ClintonA makes a good observation 15:48:42 ...the spec could take an array 15:48:43 q? 15:48:48 ack aly 15:49:06 mweksler1 has joined #wpwg 15:49:13 alyver: I'm still digesting this...I wanted to understand the gateway merchant identifier..it's the browser responsibility to store this? 15:49:18 q+ 15:49:21 oyiptong: Yes 15:49:28 alyver: I expect there to be pushback on this. 15:49:56 ...the list might be large...not sure if they want to store data 15:50:17 ...the nonces are typically single use and typically couldn't be reused 15:51:12 oyiptong: Agreed nonce is for one-time use. The browser only needs to store the uniqueness key (merchant origin + card info + gateway id) + gateway URL to send back 15:51:25 alyver: Where is the tokenized card ID coming from? 15:51:31 oyiptong: Generated by the browser for subsequent use 15:51:56 Browser == payment app 15:52:12 ...the merchant keeps track of the ID, and when calling PR API subsequently, the browser has it. 15:52:18 q+ 15:53:04 oyiptong: When the user selects the payment method, the gateway generates the token but does not send it to the client. When the merchant gets the nonce, it uses the nonce to get the token. The merchant and gateway communicate out of band for the actual token 15:53:05 q? 15:53:07 ack shift4sms 15:53:37 q+ on payment app handling 15:54:03 q? 15:54:08 queue+ shift4sms 15:54:10 ack MAN 15:54:11 Roy has joined #wpwg 15:54:29 MANASH_MC: oyiptong, michel, thanks a lot. 15:54:46 ...a couple of things around encryption - who is responsible for managing the encryption keys? 15:54:50 ...just the browser? 15:54:57 Payment app was mentioned. In my mind the browser and the payment app are one and the same - would this be correct? 15:55:09 oyiptong: We are using public keys. It's a good point that I need to mention in the document that the merchant/gateway have an understanding (and have generated a key pair) 15:55:31 ...the public key is used to encrypt the payload but the gateway has the private key 15:56:00 MANASH_MC: Different scenarios - card data stored in browser, in native wallet, or web-based wallet 15:56:20 ..native wallets will typically store tokens in hardware or cloud 15:56:33 ...web based wallets may store tokens..how will that happen? 15:56:46 ...e.g., can a gateway create a web-based wallet? 15:57:16 Also, some discussion on a token to merchant back-channel of some sort - is this solution requiring a multi-use token or does this back-channel allow for single-use tokens? 15:57:55 q? 15:58:09 MANASH_MC: How does this work with existing custom payment methods? 15:58:44 ...main point is to understand (1) who is responsible for encryption and (2) how do gateway tokens work if gateway distributes wallet? 15:58:47 q+ 15:58:49 ack ClintonA 15:59:21 ClintonA: When I look at the subsequent request v. the initial request, I see that 11 and 12 for initial request is the request for the actual token. Is the result of 12 a token or the actual PAN? 15:59:37 ...if step 11 and 12 are beyond the scope of this payment method 15:59:45 ...why is it defined in the payment response 16:00:00 ..I'm trying to figure out what exactly goes in 11 and 12 and why is that not included in the subsequent requests? 16:00:21 oyiptong: 11 and 12 are indeed server-to-server communication. It could also be a transaction where the merchant could be charging the card at this point. 16:00:28 ..the response will be a token to be used subsequently 16:00:51 ...as far as 13, the response, is concerned...the reason it is after communication between merchant/gateway is that there might be errors 16:00:58 ...the user can try again in error cases 16:01:45 ...in the diagram about subsequent use, there could be more arrows to show communication between merchant and gateway 16:01:45 q? 16:02:03 ian your line is breaking up 16:02:20 ack oyiptong: I wanted to mention ... Michel mentioned that we could also make the payment app handle the tokenization 16:02:30 ...we could create a handler so that the handler is responsible for generating and storing the id 16:02:33 q? 16:03:05 mweksler1 has joined #wpwg 16:03:08 Ian: I think we should write the spec to make clear what happens...and then it doesn't matter whether it's the browser or some other payment app that's implementing 16:03:18 oyiptong: Ok 16:03:45 "...the browser will contact the gateway " 16:03:55 say instead: ....the payment contacts the gateway 16:04:07 ..and the payment app could be a browser 16:04:09 oyiptong: Ok 16:04:12 q? 16:04:13 q- 16:04:16 +1 I think taking the approach of having Payment Apps being responsible for tokenization might be a good approach. 16:04:57 Shift4sms: Is this solution requiring a multi-use token or does this back-channel allow for single-use tokens? 16:05:16 steve: in our solution, single use is preferred 16:05:56 q+ 16:06:05 q+ 16:06:19 IJ: Am I understanding that at times gateways will say "don't store this for subsequent use". IS that a thing? 16:06:23 Mostly correct. We certify based on single use or multi use and if both are certified, then the payment app can request which. 16:06:27 oyiptong: Yes. It could be the gateway OR the merchant 16:06:35 IJ: What does the spec say about that? 16:06:35 q? 16:06:41 ack oyiptong 16:06:42 oyiptong, you wanted to comment on payment app handling 16:06:48 yes 16:06:52 ack shift4sms 16:06:54 ack ClintonA 16:07:00 zakim, close the queue 16:07:00 ok, Ian, the speaker queue is closed 16:07:18 ClintonA: Perhaps "gateway" is not the right word for "token provider" 16:07:31 ...there are other types ... don't have a better term. 16:07:32 IJ: Token provider? 16:07:33 +1 16:07:37 +1 16:07:43 +1 16:07:45 ack aly 16:07:46 +1 16:07:58 ack aly 16:08:15 alyver: Circling back to payment apps that tokenize....to play the devil's advocate... 16:08:30 ...suppose we only have third party payment apps to implement tokenization 16:10:01 IJ: I assume I would choose one from among all matching payment apps 16:10:18 q+ 16:10:56 ClintonA: What we are seeing with these questions is that the merchant has to be able to indicate how they expect to authorize the result of the payment rqeust 16:11:08 ...the parameter defines which gateway and whether they are are using network tokens 16:11:33 IJ: Next steps...take a second pass? 16:11:43 mweksler1 has joined #wpwg 16:11:52 oyiptong: We'll take feedback (payment app v. browser, token provider, some steps mentioned) 16:11:57 ...and support for N gateways 16:12:04 ...clarity around one-time use tokens 16:12:21 topic: Updates to the mission statement 16:12:49 IJ: When can you update the wiki, Manash, with next draft of mission statement? 16:13:09 MANASH_MC: I want to do a tiny bit of research of 3DS as well and will have the wiki updated by next week. 16:14:02 topic: Network tokens 16:14:43 IJ: Next steps? 16:14:43 roy: I was out for more than as week. Am now back! 16:14:53 ...we are planning to meet on Thursday after the main WPWG call. 16:15:07 ...I am available 8 June 16:15:15 (Regrets from IJ) 16:15:49 +1 on 8th or 15th 16:15:51 Roy: 11am-noon ET Thursdays to start...will adjust as needed 16:16:05 PROPOSAL: 8 June, 11-noon ET 16:16:30 +1 16:16:40 +1 16:16:51 mweksler1 has joined #wpwg 16:16:59 ACTION: Ian to send around a meeting announcement for a Thursday network tokenization call 16:16:59 '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:16:59 1 16:17:07 +1 16:17:10 +1 Want to attend, but can't this week...to clarify 16:18:00 ClintonA: I will bring my comment to the network tokenization call 16:19:17 MANASH_MC: In the gateway session last week, one pain point identified last week...gateway tokens are basically not inteorperable 16:19:29 ...Airbnb highlighted this. 16:19:44 q+ 16:19:49 zakim, open the queue 16:19:49 ok, Ian, the speaker queue is open 16:20:11 oyiptong: the gateway proposal has a standard way to get info from any token provider 16:20:15 ..it becomes easier to handle 16:20:27 ..the gateway to merchant backend communication is another interop issue 16:22:18 Manash: Network tokens should be reusable across gateways 16:22:46 ...let's identify the user stories in the gateway section of the mission page 16:23:10 q? 16:23:22 q? 16:23:29 Topic: Next call 16:23:37 Proposed:20 June 16:23:57 +1 16:24:03 +1 16:24:29 RRSAGent, make minutes 16:24:29 I have made the request to generate http://www.w3.org/2017/06/06-wpwg-minutes.html Ian 16:24:39 RRSAgent, set logs public 16:57:52 alyver has joined #wpwg 17:32:34 alyver has joined #wpwg 17:53:51 cweiss has joined #wpwg 18:19:11 alyver has joined #wpwg 19:16:34 alyver has joined #wpwg 19:26:44 alyver has joined #wpwg 20:35:45 alyver has joined #wpwg 20:50:22 alyver has joined #wpwg 21:01:07 alyver has joined #wpwg 22:44:52 cweiss has joined #wpwg