15:25:37 RRSAgent has joined #wpwg 15:25:37 logging to http://www.w3.org/2017/05/16-wpwg-irc 15:25:41 Zakim has joined #wpwg 15:25:51 Meeting: Tokenization Task Force 15:25:53 Chair: Ian 15:26:03 agenda: https://lists.w3.org/Archives/Public/public-payments-wg/2017May/0046.html 15:30:19 shift4sms has joined #wpwg 15:30:49 present+ SteveS 15:30:52 present+ 15:30:55 present+ oyiptong 15:30:58 present+ cweiss 15:32:19 present+ Ken 15:32:22 regrets+ Roy 15:32:34 present+ Manash 15:32:36 shift4sms has joined #wpwg 15:32:36 zakim, who's here? 15:32:36 Present: SteveS, Ian, oyiptong, cweiss, Ken, Manash 15:32:38 On IRC I see shift4sms, Zakim, RRSAgent, cweiss, betehess, adamR, Dongwoo, emschwartz, adrianba, davidillsley_, dlongley, manu, hober, dlehn, ShaneM, trackbot, schuki, Ian, mkwst, 15:32:38 ... slightlyoff, oyiptong, nicktr, JakeA 15:32:52 Manash_MC has joined #WPWG 15:32:55 Ken has joined #wpwg 15:33:04 present+ Keyur 15:33:06 present+ Sachin 15:33:21 present+ alyver 15:33:22 alyver has joined #wpwg 15:33:34 regrets+ MattS 15:33:59 https://github.com/w3c/webpayments-methods-tokenization/wiki 15:34:05 Topic: Mission statement 15:34:06 https://github.com/w3c/webpayments-methods-tokenization/wiki 15:35:16 stan has joined #wpwg 15:35:44 present+ Michel 15:35:47 mweksler has joined #wpwg 15:35:47 present+ Stan 15:36:09 IJ: How does this sound to people? 15:36:16 Manash: Thanks for sharing the draft. 15:36:20 ..I think overall this looks pretty good 15:36:31 ..we might come back to you with recommendations on edits based on things like "issuer tokens" 15:36:38 ...what should we say about issuer tokens? 15:36:48 ...we have mentioned merchant-specific and PSP tokens 15:37:09 ...one target audience would be bank-based payment apps. 15:37:14 ...so want to mention issuer tokens explicit 15:37:23 agenda+ common data fields for tokenization spec 15:38:22 Manash: An action item from our end would be to come back to you before next week with some specific text edits 15:38:40 ...but I think we are moving in a good direction. 15:38:45 Keyur: I sent some feedback. 15:39:09 +1 on mission statement 15:39:14 IJ: Thanks! I have incorporated. 15:40:16 IJ: Stripe folks? 15:40:25 cweiss: Not yet. 15:40:45 Stan: I have a question about the benefits of this effort. Saying that it will make it easier for PSPs to interact with more merchants 15:41:05 ...it hints at the fact that we would allow to merchants to interact with PSPs they don't have a relationship with. 15:42:11 IJ: I would distinguish business relationships v. technology friction. Let's make that clearer. 15:42:18 q+ 15:42:26 Stan: +1 to scoping this to providing standardized APIs for collecting tokens from PSPs. that makes sense 15:43:21 q+ 15:43:53 mweksler: I agree with Ian (about the standard pipe, not the token shape). A business relationship is still necessary; we may or may not need to say that in the mission statement. 15:44:05 ...but I agree that a business relationship is still necessary 15:44:07 ack mw 15:44:09 ack shift4sms 15:44:28 q+ 15:44:32 shift4sms: Yes,agree. I think the goal in this document should be to give vendors on what data they need to accommodate for, now how to do it. 15:44:51 ...give merchants a heads-up on data requirements. 15:44:54 agenda? 15:45:59 IJ: I think we need to figure out whether we can come up with common data set. 15:46:01 ack Ken 15:46:12 +1 15:46:26 Ken: Please call out relationship to EMVCo 15:46:32 IJ: +1 15:47:05 Ken: What does this solve for that EMVCo spec does not? 15:47:15 ....whatever the answer, let's include that. 15:47:30 q? 15:48:27 Ken: Meanwhile, I like the initiative and in principle am supportive of it. 15:48:33 Manash: We can take a stab at a FAQ entry 15:49:00 IJ: At the bottom of this -> https://github.com/w3c/webpayments-methods-tokenization/wiki 15:49:48 mweksler: how are we editing? 15:50:40 IJ: for now I'm cool with people editing directly in the wiki 15:50:48 +1 15:51:15 https://github.com/w3c/webpayments/wiki/How-the-Working-Group-works 15:53:28 IJ: Let's use issues list for discussion and perhaps important or controversial text proposals 15:53:40 IJ: welcome other people's contributions to the wiki 15:53:47 q? 15:54:43 Keyur: We could mention in the mission statement that our mission is to leverage existing token schemes supported by issuers, PSPs, and networks, and make it easier for merchants and PSPs to process payments with these existing schemes. 15:55:08 ACTION: Manash to work on a FAQ entry about relationship of this work to EMVCo specs 15:55:09 Created ACTION-57 - Work on a faq entry about relationship of this work to emvco specs [on Manash Bhattacharjee - due 2017-05-23]. 15:55:47 topic: Diagram 15:56:06 Keyur: Summary of discussion was that there are device tokens that can be given to merchant...so we don't need an intermediate PSP token in those cases 15:56:07 http://www.plantuml.com/plantuml/proxy?fmt=svg&src=https://raw.githubusercontent.com/w3c/webpayments-methods-tokenization/gh-pages/diagrams/w3cpayment.pu 15:56:13 ...we need to update the diagram 15:56:48 ...we want to enable merchant to say what kind of tokens the merchant's PSP(s) support 15:57:00 present- Sachin 15:57:23 https://github.com/w3c/webpayments-methods-tokenization/blob/gh-pages/diagrams/w3cpayment.pu 15:59:25 IJ: How do we get this easy communications among parties? 15:59:35 Keyur: Payment method can talk about merchant-supported token types 15:59:43 ..the list could be defined in the payment method. 15:59:59 ..."psp", "network", and maybe "issuer" 16:00:15 Manash: Some issuers can issue virtual card numbers 16:00:25 Manash: Should we look at dynamic CVV, dynamic expiry? 16:00:33 q+ 16:00:43 ...we should be sure to cover those as well 16:01:13 Keyur: Internally, MC and Visa support dynamic expiry and dynamic cvv 16:01:34 ...the wallet can generate dynamic value that is a random number and that's what's given to the merchant in addition to the card number 16:01:49 ..the merchant processes payment with pseudo PAN, CVV, Expiry 16:01:54 ...the network translates 16:02:06 ...as I think of this, it seems closest to basic card...merchant doesn't need to know that it's a goken 16:02:09 s/goken/token 16:02:31 Manash: Agree mostly. If a merchant is willing to accept dynamic CVV, they have to specify that they ask for CVV 16:03:01 ack alyver 16:03:32 alyver: (Catching up)....I think that dynamic cvv and expiry fits best with basic card 16:04:06 ...would the merchant have to specify their PSPS and whether they support network or gateway tokens, there are a lot of merchants who have no ideas. 16:04:09 s/ideas/idea/ 16:04:20 +1 on merchants not knowing token type to ask for 16:04:22 ...they might know they support *PAY due to integration of code 16:04:30 ...or similar for Masterpass or Visa Checkout 16:04:48 q+ 16:04:57 ack mweksler 16:05:11 mweksler: I want to add some color to the conversation and highlight some of the potential needs. 16:05:35 ...to begin, I think that the fact that the network tokens can at times fit into basic card is great...for those cases, we would not need another spec. 16:05:43 q+ 16:05:44 (IJ THINKS WE SHOULD CALL THIS OUT IN THE WIKI) 16:05:59 correction: I was suggesting that dynamic expiry and cvv fit into basic card. token are different. 16:06:17 mweksler: Many merchants, however, have integrations that don't look like basic card. AirBNB doesn't see PANs. All that info is shipped to a PSP. They provide AirBNB with a token 16:06:28 q+ 16:06:37 ...that pattern of integration is the one that we are discussing here and doesn't fit with basic card. It does require a different integration on the front end and the back end. 16:06:57 ...on the front end, the mechanism for capturing info needs to be able to ship info to a PSP and return a token to the merchant 16:07:11 ..and on the backend, the merchant needs to have a relationship with the PSP who can process the token 16:07:16 ack shift4sms 16:08:17 shift4sms: Regarding format preserving tokenization, this is not a format my company supports in particular. PCI has a clause in their scoping document about tokenization. If you have format preserving tokens, you need to be able to distinguish them from regular card numbers...that's why I lean towards non format-preserving tokens 16:08:23 ...so we should call out pros and cons 16:08:33 ..the other problem with format-preserving tokens is collisions with real data... 16:08:49 ...there's a higher chance of collision when your data needs to fit within the confines of a data number 16:08:49 q+ 16:08:52 ack aly 16:09:12 alyver: Thanks for the clarification. I was referring mostly to dynamic cvv/expiry fitting with basic. 16:09:25 q+ 16:09:35 ...if we are talking about stripe or braintree types, etc. if that's the problem we are trying to solve, that's fine. 16:09:54 ..I think in the case of gateway tokens, there is an assumption of backend integration for merchants to work with PSPs. 16:10:10 ..if you look at android pay for mobile spec, they have bits on support for gateway tokens....that's a good example 16:10:52 (IJ: plans to add a bit on basic card and dynamic data to the wiki) 16:10:56 ack oy 16:11:11 oyiptong: Why are we talking about format-preserving tokens v. non format preserving? 16:11:17 ...I don't think we are constraining tokens. 16:11:47 re: Google's support for gateway and network tokens https://developers.google.com/web/fundamentals/discovery-and-monetization/payment-request/android-pay 16:11:48 oyiptong: I think we should try to write a spec to be token-type agnostic 16:12:01 ...merchant will specify supported tokenization schemes 16:12:07 ..does it matter what format the token is in? 16:12:09 q+ 16:12:12 q+ 16:12:33 ack stan 16:12:43 stan: I want to touch base on the basic card spec. 16:12:56 ...I think the motivation here was to enable network-level tokens and issuer tokens to circulate 16:13:08 ...maybe there's a world in which we manage to handle network tokens in basic card spec 16:13:18 ...and that we we don't try to solve network and PSP tokens at the same time 16:13:34 ...these things operate at very different levels 16:13:47 q+ to speak about why it could be useful to allow for more 16:14:09 ...feels like we may wish to tackle these separately 16:14:43 ack shi 16:15:01 shift4sms: I've heard a few comments about merchant specifying token type 16:15:17 ...to me, it seems that "network" and "issuer" token are the same....are they different in practice? 16:15:29 ..if you say "I cannot support a network/issuer token" do you really have a choice at that point? 16:16:02 q+ 16:16:43 q- 16:16:44 Keyur: Regarding issuer/network token...in the draft tokenization spec, there is a distinction between issuer and network token 16:16:57 ....I hear from Manash that issuer tokens are more like virtual cards 16:17:09 ...virtual cards don't address our PCI/compliance issue 16:17:23 ...someone should dig into this question of whether issuer and network tokens are materially different 16:17:35 ..if it's a virtual card, it should be done via basic card 16:18:05 q? 16:18:15 Q+ 16:20:54 q+ 16:21:20 ack me 16:21:20 Ian, you wanted to speak about why it could be useful to allow for more 16:21:21 ack Ken 16:21:28 thanks, Ian 16:22:18 IJ: I think that it is interesting to try to see if we can handle lots of use cases where tokens of all types come from the user side, and it's easy for merchants to get tokens without knowing their exact format. Hard question for me is whether we can abstract across request data. 16:22:30 Ken: I think network/issuer distinction is about who runs the vault. 16:22:40 ...I want to make sure we are not replicating existing tokenization specs. 16:23:04 q? 16:23:19 ack stan 16:24:03 stan: I want to add some perspective. If the effort is to provide a simple solution for merchants to get PSP tokens, then we need a bigger spec since these tokens can represent lots of other payment methods 16:24:24 ...I think that it may make sense to think of "EMVCO" (which might fall into basic or not)...and then handle PSP differently 16:24:51 ...merchants might not be happy to have one spec for "cards" and have to do other things for other payment types 16:25:03 https://github.com/w3c/webpayments-methods-tokenization/wiki 16:25:10 The focus of this Task Force is tokenized card payments. 16:25:10 " 16:26:33 IJ: Great question - whether we tackle smaller problem first and learn, etc. 16:26:48 Stan: Maybe we can live with crossing abstraction boundaries, but I want to be explicit 16:27:11 mweksler: +1 to crawling before we walk. If we start focusing on something that is well-scoped, I think we might achieve something that will work. 16:27:33 ...but stan makes a good point 16:27:50 +1 on mweksler's comment 16:30:13 agenda? 16:31:18 IJ: Anybody want to look at data requirements in preparation for next week's call? 16:31:28 mweksler_ has joined #wpwg 16:31:34 Stan: I can take an action item to write down input data from different providers. 16:31:35 \o/ 16:32:09 ACTION: Stan to look at input data requirements across a few token providers 16:32:09 Error finding 'Stan'. You can review and register nicknames at . 16:32:11 q? 16:32:23 Topic: Next meeting 16:32:33 23 May 16:32:39 RRSAgent, make minutes 16:32:39 I have made the request to generate http://www.w3.org/2017/05/16-wpwg-minutes.html Ian 16:32:43 RRSAgent, set logs public 16:33:14 mweksler has joined #wpwg 16:33:32 RRAgent, actions? 16:33:37 RRSAgent, actions? 16:33:37 I'm logging. Sorry, nothing found for 'actions' 16:33:40 zakim, actions? 16:33:40 I don't understand your question, Ian. 16:33:46 actions? 16:47:20 mweksler has joined #wpwg 17:44:06 mkwst has joined #wpwg 18:08:39 cweiss has joined #wpwg 18:45:31 mweksler has joined #wpwg 19:02:51 mweksler has joined #wpwg 19:21:48 mweksler has joined #wpwg 19:58:42 cweiss has joined #wpwg 20:04:50 mweksler has joined #wpwg 20:49:00 stan has joined #wpwg 21:02:41 mweksler has joined #wpwg 21:07:39 mweksler_ has joined #wpwg 21:15:48 mweksler has joined #wpwg 21:32:38 stan has joined #wpwg 22:15:51 stan has joined #wpwg 22:25:13 mweksler has joined #wpwg 22:31:42 mweksler has joined #wpwg 22:33:01 mweksler_ has joined #wpwg 22:33:24 mweksler has joined #wpwg