15:30:02 RRSAgent has joined #wpwg 15:30:02 logging to http://www.w3.org/2017/05/23-wpwg-irc 15:30:05 zakim, clear agenda 15:30:05 agenda cleared 15:30:11 Meeting: Tokenization Task Force 15:30:13 Chair: Ian 15:30:25 Agenda: https://lists.w3.org/Archives/Public/public-payments-wg/2017May/0057.html 15:31:20 present+ Ian 15:31:22 present+ alyver 15:31:25 present+ SteveSommers 15:31:29 present+ Christian 15:31:35 present+ ClintonAllen 15:31:55 present+ Olivier 15:32:12 mweksler has joined #wpwg 15:32:22 stan has joined #wpwg 15:32:37 alyver has joined #wpwg 15:32:37 present+ 15:32:49 present+ michel 15:32:52 present+ alyver 15:32:54 present+ Roy 15:33:31 topic: Stan's gathering of request/respnose data 15:33:36 https://docs.google.com/spreadsheets/d/1v1BPvR7Z7apBrxSNgTF-ifYJAvLEECYh7tHW-cpSUq4/edit#gid=0 15:33:53 stan: I catalogued different inputs/outpus 15:34:06 ...comes with the caveat that I am not myself an expert in network tokenization 15:34:27 I am not able to access the spreadsheet... 15:34:28 ...having said that, there is some uniformity 15:34:34 Ken has joined #wpwg 15:34:38 present+ Ken 15:36:39 stan: Major caveat...some of the gateways don't support a REST API publicly 15:37:04 ..and stripe is moving toward not supporting tokenization through REST API publicly for PCI reasons...BUT moving to payment app would address that 15:37:20 ....apple/masterpass/visa follow a similar pattern 15:37:29 ...comes down to pre-agreed cert between merchant and PSP 15:38:06 ...and output involves encrypted DPAN + cryptogram 15:38:16 ...and when decrypted gives DPAN 15:38:37 ...so gateways are pretty in alignment and the network-based are also aligned 15:38:40 q? 15:39:15 Manash: Apple pay => secure element. ...other cases can be cloud 15:39:34 ...based on emvco standard, crypto can go into two fields 15:40:09 +1 15:40:39 Manash: PSP will have to mention the fields that they can take care of 15:40:59 q+ 15:41:03 Stan: I am hearing that there's an input param from the merchant "what field acceptance" 15:41:07 Manash: Yes 15:41:11 ...we can provide some more details later on 15:41:25 ...we are working on an EMVCo summary to share with the group that will have more details 15:41:46 Stan: One interesting thing I noticed on Masterpass is that the request token needs to be created server side 15:41:57 q+ 15:42:08 Manash: Masterpass supports EMV token but we also support our own version of gateway tokens 15:42:16 ...for merchants that want to reduce PCI exposure 15:42:21 ..that leads to handshake 15:42:27 ack aly 15:42:36 s/+1// 15:42:53 alyver: The merchants also have the responsibility in some cases of putting data in the right fields 15:43:01 ...in UCAP or some of the EMV fields 15:43:06 ...so not just gateways 15:43:12 Manash: +1 15:43:15 ack m 15:43:24 q+ mweksler 15:43:35 s/UCAP/UCAF 15:43:37 clinton: This is my first call. Could someone describe the distinction between the two token types 15:43:54 stan: I think the gateway tokens have existed for a long time...simple goal of removing PCI scope for merchants 15:44:04 ..the PAN is sent to the gateway server from the browser or payment app 15:44:16 ...in exchange it will get a token..merchant will only get a token 15:44:36 ....network tokens replace PAN with dynamic PAN with cryptogram 15:44:57 ...so the former is motivated by PCI scope, the latter by security 15:45:00 https://github.com/w3c/webpayments-methods-tokenization/wiki 15:45:40 q? 15:45:59 Clinton: My role in EMVCo is chair of the tokenization WG 15:46:08 ack mw 15:46:28 mweksler: Thanks for the spreadsheet, Stan! 15:46:32 ...great to be concrete. 15:46:52 ..am I understanding the spreadsheet correctly...talking about payment app and the backend to which it connects 15:46:58 ..is that the direction the spreadsheet was aimed at? 15:47:12 Stan: I think the goal was mostly to look at the interaction of the clients in both situations 15:47:36 ...this is browser and payment app 15:47:55 mweksler: That requires find-tuning. E.g., I can take a picture of my credit card to add to Apple Pay 15:48:12 ..there's a client that consumes the PAN and then somehow turns it into a token 15:48:12 What you are describing is the provisioning of the card in the "wallet" 15:48:24 ...we may need to add another column for "user agent" mechanism 15:48:32 ....we may need to clarify what we mean by client 15:48:47 Stan: I think that makes sense...the spreadsheet was focused on the client side library requirements 15:48:53 Manash_MC has joined #WPWG 15:49:02 +1 15:49:03 q+ 15:49:27 ack Cli 15:50:04 ClintonA: What you are highlighting here is associating a plastic card with a wallet is provisioning, which is decoupled from the transaction step 15:50:21 mweksler: I think we still need to address them both (provisioning, usage) 15:50:44 ...I think there is similarity in use, and deviation in provisioning 15:50:54 manash: Tokenization, provisioning, transaction 15:52:25 Stan: Gateway transactions are a representation of a card. They can be used or reused to create transactions. 15:52:47 ...whether network tokens, due to their single-use flavor (mostly true but not always) mostly represent a transaction, though in some cases you can create subsequent charges using them 15:52:49 q+ 15:53:14 ...Stripe creates a token, you can do a charge with the token and used for future charges 15:53:16 q+ 15:54:08 ack clin 15:54:20 IJ: I am hearing properties ... should we document? 15:54:36 ClintonA: Gateway tokens are generally identified within an ecosystem (e.g., a braintree token is for that ecosystem) 15:54:43 ..network tokens can be shared across multiple merchants/gateways 15:54:54 ..which highlights another distinguishing quality - they can exist without a cryptogram 15:55:14 ..when you introduce token+cryptogram creates a transactional combination 15:55:40 ..within the gateway space, each token is unique to an ecosystem and may not be used in a transaction 15:55:51 ...network protects transaction outside the acquiring space 15:56:16 roy: While things like "publishable key" and "merchant id" sound similar, they are different values by gateway 15:56:20 q+ 15:56:37 ...you don't get to reuse keys...which says to me each gateway might want its own PMI 15:56:39 ack aly 15:56:58 alyver: There was a comment earlier about gateway/network tokens behaving the same way once in the system...for network tokens there's a provisioning step 15:57:23 ...at that point stored in my wallet...then when I do a transaction, the encrypted payload is returned to the merchant who decrypted 15:57:56 ...in the case of a gateway token (I am thinking Android Pay / Chrome implementation of PR API).....gateway tokenization happens with downstream PSP and merchant gets back a gateway token 15:58:05 ...I'm not sure if we are also considering that flow 15:58:14 ack shif 15:58:20 q+ mweksler 15:58:30 q+ 15:58:46 steve: Regarding reuse of gateway tokens...not sure you can lump them all together. Our gateway has 2 forms of tokens in our API process... 15:58:51 ...whether single or multi use toikens 15:58:54 s/toikens/tokens 15:59:07 ...gateways can to multi-use tokens...not sure you can generalize the distinction 15:59:24 ...to me the only really diff between the two is that a gateway token can't really be used in a wallet scenario 15:59:36 ...not generally reusable 15:59:48 ...other than that, the features can be mixed and matched 16:00:04 mweksler: that's fair. Gateway tokens are "scoped" to the merchant that they were added under 16:00:19 Manash_MC has joined #WPWG 16:00:31 ...if I add a card through a web site and I use stripe as a PSP, I get back a token that is scoped to that site and I can't use with another site even though I am same user, might be same PSP, etc. 16:00:36 ...that is definitely a difference. 16:00:45 +q 16:00:47 +1 16:00:58 ...in terms of similarities, if we look at PR API, and say there is a tokenized payment handler 16:01:22 q+ gateway tokens + wallets 16:01:26 ...and we do some enrollment (let's put aside that for a moment), at that point, I get a token and payment handler is responsible for handing the right token back to the browser 16:01:37 ..that was the seemingly appealing similarity between the two approaches 16:01:39 ack mweksler 16:01:55 ...it does feel appealing to me - you have the same interaction regardless of gateway or network token 16:01:56 err, i messed up the queue, sorry, Ian 16:02:00 q? 16:02:04 ack stan 16:02:09 q+ 16:02:18 queue==ClintonA, oyiptong, Manash 16:02:46 (Suggest columns: "encrypted?" "scoped?" 16:02:57 stan: gateways have integrated with network tokenization solutions in many ways 16:03:11 ..even if we were to layer the two systems one on another, it would probably not be compatible with thew ays 16:03:19 ....that gateways get those tokens today 16:03:37 ...and so it feels like even if we wanted to layer systems to get a unified tokenized API it would nonetheless create complexity 16:03:59 ...we've been discussing internally at Stripe....current thinking is that it would be complex 16:04:26 ...feels complex to abstract all tokenization aspects 16:04:37 ....gateways expect network tokens today in non-standard ways 16:05:12 q? 16:05:14 ack Cli 16:05:32 ClintonA: Some of the language that I hear now is that network tokens do not have a common way of requesting/receiving tokens 16:05:37 ...that's helpful feedback for me 16:06:28 ...one of the things I'd like to clarify: when we look at token types...I think the problem to solve is "if you have a wallet that needs to store a cardholder's credentials, if you use a gateway token, that wallet scope is limited to the gateway..but if you use a network token, can be reused independent of gateway" 16:06:42 ...I hear the problem being how to reuse a token across merchants/acquirer 16:06:47 q+ 16:07:28 q- 16:08:04 ack oy 16:08:40 oyiptong: Thanks for the spreadsheet. I'd like to touch on something Steve said...he was saying that network tokens be stored in a wallet but gateway tokens cannot...I don't think that's quite accurate. I think we could store gateway tokens by origin 16:09:01 ...so while it's true that gateway tokens are scoped to PSP and merchant, but in a wallet you could store it for a specific (merchant) origin. 16:09:23 +1 16:09:24 ...for example, foo.com uses gateway token could be stored in my wallet specifically for Stripe+foo.com 16:09:51 ...but it is true that we lose interop in the sense that "same PAN cannot be reused on another origin even if they use the same PSP" 16:10:21 ...if we lived in a world where network tokens were the norm, we wouldn't need gateway tokens, but you'd still have the problem of storing token in wallet based on network used 16:10:22 q? 16:10:25 ack Ma 16:10:58 Manash: From the merchant perspective (or whoever is invoking PR API)...if I am merchant or say worldpay...what is the difference in terms of options 16:11:10 ....can that be standardized so that merchant does not have to create different options 16:11:14 ...that is one thought 16:11:34 ..the second is ... the response to the merchant...can that response be in a standard format independent of token type 16:13:08 Stan: If we look at what the user wants - an easy way to do multi-gateway tokenization without needing a central vault 16:13:14 ...that can be provided for outside of this effort 16:13:37 ...an alternative is to address network tokenization clearly today 16:14:22 mweksler: I want to mention a few things from our perspective...I am sure we agree we want to make it easy for users ...but from a merchant perspective, we already have the pipes that are mentioned in the spec (tokenizing things from the browser using PSPs)...but we need multiple integrations 16:14:26 ...this standard would just be one of those 16:14:46 ...network tokenization at the moment requires a lot of ceremony before it can be used..e.g., redirecting the user 16:14:50 q+ 16:14:52 ...a lot of steps are required 16:14:57 ..but that means more friction 16:15:17 ..I think that is perhaps the single most difficult aspect of the network tokenization schemes I've seen -- multiple steps to onboard a user. 16:15:26 ..but in the end they result to something that is very similar to the gateway tokens 16:15:47 +q 16:15:51 ...the merchant wants to process something, it gives a token to its integrated PSPs and the transaction goes through. 16:16:13 ..if we focus on that, and reduce the complexity stan refers to (and hide from users) we could come up with something easy to use and never requires merchants to see a PAN 16:16:14 ack stan 16:16:31 stan: I strongly agree on the goal of making using network tokenization easier with less integration for merchants 16:16:49 ..but having one single client side integration is an orthogonal goal and we can sequence them 16:17:02 ...could start with network and then build a layer on top to solve multiple merchant integrations 16:17:10 ...trying to solve all in one go makes it easier 16:17:20 mweksler: Why start with network tokenization over gateway? 16:17:51 stan: they are 2 different beasts...one is user interaction in user agent that generates a token (that's network). Whereas gateway tokenization is a representation of a card. 16:18:13 ...we can standardized the APIs for network tokenization (redirect based)...and once we get there, we can do gateway 16:18:19 q+ 16:18:30 ..there are also other payment methods (beyond cards) to look at 16:18:52 ...I think focusing on network tokens will reduce the problem space and then we can sequence...that's our current take 16:19:00 ..I am hearing other takes as well 16:19:02 ack Cl 16:19:53 ClintonA: I think that choosing gateway v. network is likely to be the wrong approach. I think that both types provide value. I think network tokens provide value where gateway tokens cannot ... security features outside of acquirer 16:20:05 ...I think layering the systems on one another would be helpful 16:20:15 ...but there are complexities 16:20:17 ack mweksler 16:20:31 mweksler: I wanted to take the two previous points and wrap them into the larger context of the other specs in play 16:20:46 ...by the way, I'd love to get a spec around network tokens; I agree it's a good idea... 16:21:01 ..but I think one of the reasons we started to look at gateway tokens has to do with the current state of the specs 16:21:10 ...Basic Card has PANs flowing freely between browser and merchant 16:21:51 ...a few of us felt that Basic Card was a reasonable way to start, but we need to fast forward to increasing security, does not expose merchant to PCI Scope 16:21:59 q+ 16:22:03 ..so an idea was "encrypt in the browser" and flow through existing channels 16:22:04 q+ 16:22:24 mweksler: one way to look at sequencing is that gateway tokens seem to provide an easier next step 16:22:39 Roy: I am hearing a lot of comments around network tokenization v. gateway..if you look at the current draft spec 16:22:46 ..it is very network-token oriented 16:22:59 ...maybe we can take the learnings from today and see how relates to existing text 16:23:03 +q 16:23:13 ...specifically around gateway tokens, does it make sense to look at a spec around gateway tokens? 16:23:15 ack shif 16:23:56 shift4sms: A lot of the discussion seems to be pulling some of the feature set of gateway and merging with some of the feature set of networks. A lot of features cross over...but network tokens for a majority of their usage today is single-use (there are exceptions) 16:24:03 +q 16:24:06 ...the gateway tokens are typically more for multi-use 16:24:40 ...we are talking about "merging" but keep in mind that once you start to make a gateway more reusable across merchants, you need to make sure we are not merely replacing sensitive information with more sensitive informaiton 16:24:47 ack me 16:27:39 IJ: Should we have parallel activities to see how similar the two approaches look in practice? 16:27:44 +1 on articulating as two parallel proposals 16:27:48 q- 16:27:56 Manash: I think we may need additional merchants to hear their needs 16:28:34 ...EMVCo has worked hard to create a token format that works across a lot of stakeholders and we should leverage that 16:29:02 ...we should probably get input from merchants (even outside of W3C) and get their feedback on the two tokenization approach 16:29:03 q? 16:29:05 ack Man 16:30:13 happy to help Stan 16:30:27 ACTION: Stan will take another pass on the spreadsheet to shed light on categories / similarities 16:30:27 Error finding 'Stan'. You can review and register nicknames at . 16:31:34 IJ: Are parallel efforts responsive to Stripe perspectie? 16:32:06 Stan: Taking our understanding, simplifying network tokenization was for us "most urgent and efficient" 16:32:13 ...so that aligns with current state of spec 16:32:43 q+ 16:33:12 IJ: Any interest for Airbnb + MasterCard to attack gateway spec? 16:33:15 ack oyiptong 16:33:23 oyiptong: It might be good to think about Airbnb to work on both 16:33:56 ....if stan's right and network is an easier way to start....worth it for us to think about both 16:34:06 ...or michel on network and me on gateway 16:34:17 Manash: I can work with folks on gateway tokens as well 16:34:58 I'm happy to participate in the network token discussion. 16:36:52 IJ: Roy are you still lead on the network side? 16:37:17 Roy: yes 16:37:25 +1 16:37:56 IJ: Olivier and Manash work out who takes lead for gateway 16:38:09 Manash: I think we should organize a demo of how network tokens work 16:38:37 IJ: Any update on updated flow diagram? 16:38:46 Manash: I will check 16:38:46 Topic: next meeting 16:38:56 q+ 16:38:59 ack clin 16:39:27 ClintonA: As you pointed out, I am hear with Amex affiliations but also participate in EMV in tokenization, remote commerce 16:39:31 ..happy to be part of conversations 16:40:15 Next meeting: 6 June 16:40:18 +1 16:40:18 +1 16:40:27 ...and in the meantime we will work to advance the gateway story 16:40:43 RRSAGent, make minutes 16:40:43 I have made the request to generate http://www.w3.org/2017/05/23-wpwg-minutes.html Ian 16:40:48 RRSAGent, set logs public 16:47:53 RRSAGent, make minutes 16:47:53 I have made the request to generate http://www.w3.org/2017/05/23-wpwg-minutes.html Ian 16:47:56 RRSAGent, set logs public 17:03:40 betehess has joined #wpwg 17:05:14 cweiss has joined #wpwg 17:49:34 cweiss has joined #wpwg 17:55:34 cweiss has joined #wpwg 18:03:58 stan has joined #wpwg 18:04:20 alyver has joined #wpwg 18:15:12 alyver has joined #wpwg 18:19:23 stan has joined #wpwg 18:28:25 stan has joined #wpwg 18:53:15 betehess has joined #wpwg 19:07:36 cweiss has joined #wpwg 19:13:51 cweiss has joined #wpwg 19:15:21 Zakim has left #wpwg 20:16:07 stan has joined #wpwg 20:47:14 cweiss has joined #wpwg 21:25:06 stan has joined #wpwg 21:29:36 stan has joined #wpwg 22:06:58 cweiss has joined #wpwg 22:24:27 stan has joined #wpwg 22:56:26 cweiss has joined #wpwg 23:03:59 stan has joined #wpwg 23:07:56 stan has joined #wpwg 23:12:10 stan has joined #wpwg 23:33:56 stan has joined #wpwg 23:40:25 stan has joined #wpwg 23:43:58 stan has joined #wpwg 23:54:08 stan has joined #wpwg 23:55:47 cweiss has joined #wpwg