15:27:43 RRSAgent has joined #wpwg 15:27:43 logging to http://www.w3.org/2017/07/18-wpwg-irc 15:27:55 Zakim has joined #wpwg 15:28:01 Meeting: Tokenization Task Force 15:28:03 Chair: Ian 15:28:15 Agenda: https://lists.w3.org/Archives/Public/public-payments-wg/2017Jul/0022.html 15:29:08 agenda+ updated gateway params spec; next steps with EMV-type tokens? 15:30:17 Present+ 15:30:19 present+ Roy 15:30:21 present+ Steve 15:30:27 present+ oyiptong 15:30:55 present+ Clinton 15:31:57 regrets+ AdrianHB 15:34:29 present+ Manash 15:34:33 mweksler has joined #wpwg 15:34:46 present+ Michel 15:36:46 MattS has joined #wpwg 15:37:25 present+ MattS 15:37:49 => https://lists.w3.org/Archives/Public/public-payments-wg/2017Jul/0022.html AGenda 15:38:01 https://github.com/w3c/webpayments-methods-tokenization/wiki/gateway_params 15:38:33 present+ Key 15:38:50 IJ: Keyur updates? Olivier diagram updates? 15:39:04 Ken has joined #wpwg 15:39:16 Manash: Regarding network tokens, we have updated the first draft of the spec, but it's in unformatted state 15:39:26 ...this week we wanted to update the formatting. 15:39:33 ...but this week is tough due to meetings 15:39:50 ...so looks for this next week. 15:39:57 shift4sms has joined #wpwg 15:40:08 https://github.com/w3c/webpayments-methods-tokenization/wiki/gateway_params 15:41:06 How to organize material? 15:41:16 1) How many payment methods? 15:41:19 2) How many specs? 15:41:41 IJ: Input same; response data different? 15:41:53 q+ add IIN / multi tokenization providers up for discussion 15:42:06 q+ to add IIN / multi tokenization providers up for discussion 15:43:00 agenda+ issue 11 15:43:04 agenda+ issue 10 15:43:07 agenda+ issue 9 15:43:09 queue=== 15:43:10 queue== 15:43:13 agenda? 15:43:20 MANASH_MC has joined #WPWG 15:43:23 zakim, take up item 1 15:43:23 agendum 1. "updated gateway params spec; next steps with EMV-type tokens?" taken up [from Ian] 15:43:45 q+ 15:43:48 ack Mat 15:43:55 IJ: One spec or two? One payment method or two? 15:44:09 MattS: I plan to review the specs and the issues. 15:44:13 (IJ: Thanks!) 15:44:37 MattS: My off-the-cuff reaction to Ian's question is concern about premature optimization because the flows and use cases are different 15:45:01 ...so my suggestion is to keep them separate as long as possible and only combine once we see they are very similar. 15:45:29 ...so don't worry about 1 or 2 yet 15:45:45 ...in the case of credit transfer, we have two payment methods in a single spec. 15:45:53 ...that is because they are so similar there is a lot of reuse 15:46:03 ..but the reason we have two payment methods is the flows are very different (and responsible parties) 15:46:27 ...so despite the data similarity, the flow difference drove me to think of them as two payment methods 15:46:42 ..and at first glance flows are different in gateway/network 15:46:48 ...summary: keep separate until later 15:46:52 q? 15:46:53 q+ IMO the overall spec could be the same, but the outputs different 15:47:33 q+ to say, RE: scenarios, explain that the overall spec could be the same as network tokens, but the outputs different 15:47:46 ack oy 15:47:46 oyiptong, you wanted to say, RE: scenarios, explain that the overall spec could be the same as network tokens, but the outputs different 15:47:50 And I have no issue with that if that is the direction of travel 15:48:01 IJ: I would integrate for now (and then see how they look together) 15:48:18 oyiptong: +1 to going in current direction and see how different they look; so far looks workable as one spec. 15:48:20 q+ 15:48:30 ack M 15:48:46 MattS: the fact that it "could be" one spec does not imply that it "should be" 15:48:56 ...beware of spec size and challenge to consume it 15:49:09 Q+ 15:49:11 ..the primary audience for this spec is people writing payment handlers 15:49:22 ..but overall I agree with the idea "add it now and split out if needed" 15:49:23 ack Ken 15:49:56 Ken: At last call we suggested reaching out to worldpay and other acquirers. 15:50:11 ...I think the PSP perspective is very important here 15:50:21 ...better firsthand knowledge on the implementation side. 15:50:58 MattS: We have implementations today and a number of implementations in a number of different places 15:51:13 ..each different scenario that uses tokenization might be applied (differently) in different payment handlers. 15:51:23 ..I anticipate that there will be two specs; but need to review them 15:51:29 q? 15:51:58 ...we might incubate this as one spec, but when we package for a larger audience, separation may make more sense. 15:53:09 q? 15:53:30 q+ 15:53:35 https://github.com/w3c/webpayments-methods-tokenization/wiki/Network-Tokens 15:53:45 (IJ: does not know if that is up-to-date) 15:53:50 ack mw 15:54:12 mweksler: I agree premature optimization is a risk and we should not assume that the two modes of operation can be combined. 15:54:22 ...I think one practical matter is that many of the parameters are similar 15:54:34 ...and many of the use cases or, rather, the ways in which the payment request is going to be made are similar 15:54:56 ...so to me the most important part is "how do we ensure that the two methods use the same data / parameters" 15:55:07 ..I would not want the specs to diverge unnecessarily 15:55:10 ..or accidentally 15:55:32 q 15:55:33 ..so even if separate, let's make sure we use the same language and mechanisms in both, to enable future convergence 15:55:34 q+ 15:55:36 ack Mat 15:55:51 MattS: I'd like to better understand the reuse you have in mind. 15:56:14 ...one of the things I've been keen to suggest in the past is the ability to reuse WebIDL and data definitions in order to do things like superclass. 15:56:16 ...I would agree with that. 15:56:28 ...I also support the idea of sharing data definitions 15:56:35 ..or even just english language usage 15:56:44 mweksler: +1 to both of those 15:57:15 This may be up to date as of last week's call => https://github.com/w3c/webpayments-methods-tokenization/wiki/Network-Tokens 15:57:50 MANASH_MC has joined #WPWG 15:58:06 This may be up to date as of last week's call => https://github.com/w3c/webpayments-methods-tokenization/wiki/Network-Tokens 15:58:25 oyiptong: I did play with reordering of diagram last week...I think the network interactions between the different entities are very different 15:58:53 ...user has a lot bigger role (it seems) in network scenario 15:59:03 q+ 15:59:13 ...I will create an issue and put the diagrams side-by-side 15:59:15 ack Matt 15:59:36 MattS: Having a quick look online at the diagrams, it may be that we are using different names for the different parties in the flows 15:59:57 ...we will need to standardize on the parties involved 16:00:29 Have a look at these: 16:00:34 http://w3c.github.io/webpayments-methods-credit-transfer-direct-debit/#flow 16:00:51 +1 16:01:24 topic: Issue Allow merchant to specify multiple Tokenization Providers 16:01:27 https://github.com/w3c/webpayments-methods-tokenization/issues/11 16:01:39 oyiptong: I'd like to talk about specifying multiple tokenization providers 16:02:12 ...if a merchant has multiple tokenization providers, they should be able to identify them in an array 16:02:27 ...why do merchants have multiple tokenization providers? (1) redundancy (2) flexibility 16:02:31 q+ 16:02:42 ack clin 16:03:07 clintonra: The idea is that there is a need for merchants to identify for a transaction that they work with N token providers 16:03:21 ..and by requesting they will get back 1 response? All of them? 16:03:24 q+ 16:04:13 q+ 16:04:22 q- 16:04:35 ack Ian 16:05:13 IJ: I think this is a capability feature. Match on payment method, then capability matching on tokenization provider. User selection of payment instrument determines which token gets sent back. 16:05:26 +q 16:05:27 oyiptong: My thought was that merchant would get back N tokens. 16:05:32 q+ to say that doesn't wokr 16:05:40 ack clintonra 16:06:31 clintonra: I hear what you are both saying but it doesn't aling. 16:06:38 s/aling/align 16:06:39 q? 16:06:41 ack Ian 16:06:41 Ian, you wanted to say that doesn't wokr 16:06:49 q+ 16:07:36 ack Matt 16:07:46 IJ:I had not understood the intent to get back N tokens 16:08:06 MattS: I read the flow diagram as the merchant backend choosing from among N tokens 16:08:17 ...if that's correct, my observation is that it's overly complex at this phase 16:08:25 ...we don't have agreement on use cases yet 16:08:36 q+ to ask a clarification 16:08:37 +1 16:09:40 +q 16:10:03 IJ: Did you mean a single payment handler returns N tokens from N token providers? That would work 16:10:10 ack oyiptong 16:10:36 oyiptong: I did not mean that either...but that prospect is interesting...we are moving logic for routing into the client...but the way I was seeing it was that routing was done on the merchant side. 16:10:38 q? 16:10:41 ack me 16:10:41 Ian, you wanted to ask a clarification 16:10:44 ack clin 16:10:52 q+ clintonra 16:11:12 mattS: But the flow diagram the payment handler talking with both token providers...so that is, I think, what Ian was saying 16:11:39 ...the merchant could then choose from among the tokens returns (from a single payment handlers) 16:12:01 ..merchant might choose for a variety of reasons, including randomly alternating 16:12:12 ...and I do see the value of it..but is perhaps early to attack this use case. 16:12:15 ack cli 16:12:32 clintonra: On step 5, the payment instrument is selected 16:12:46 ...steps 6-9 is the payment handler talking with tokenization pvodiers 16:13:02 ...support all the tokenization providers come back with a positive 16:13:21 ...I would have assumed in later steps that the token would be generically associated with a token provider 16:13:50 oyiptong: I think token provider without the number should be one of the token providers 16:14:08 ..the diagram should show that at step 13 that it charges one of the 2 providers 16:14:34 clintonra: If the tokenization steps 6-9 are discrete functions that don't have to be done in concert with the payment request, why couldn't each one be done independently and subsequent to that you have the payment request. 16:14:41 ..why do they have to be combined? 16:14:56 ...wouldn't the payment app do a tokenization with a provider and later payment request happens? 16:15:19 q+ to explain acceptance rate, redundancy and flexibility 16:15:32 MattS: One use case is 1-time use with short timeout 16:15:36 ..we need clarity on use cases 16:15:39 ack Ian 16:16:01 clintonra: If the tokens are limited in use (1-time, or limited duration)...i understand the payment handler could collect a few of them (outside of transaction flow) 16:16:12 q+ 16:17:44 https://github.com/w3c/webpayments-methods-tokenization/issues/11#issuecomment-314483114 16:17:47 https://github.com/w3c/webpayments-methods-tokenization/issues/11#issuecomment-314483114 16:18:27 MattS: Some things to fix: 16:18:33 * 11 is "payment response" 16:18:40 +1 16:19:02 MattS: One scenario is 2 tokens for same underlying instrument 16:19:10 ...also a single wallet might have multiple instruments in it 16:19:35 ..a payment handler might allow a user to pay with a merge of payment instruments (e.g., one fails so other one is used) 16:19:48 ...I think the use case we are mostly discussing here is : single instrument with multiple tokens. 16:19:54 oyiptong: Yes, that's what I had in mind. 16:20:02 ..one reason for that is to increase acceptance rate 16:20:50 q+ 16:21:05 q+ 16:21:34 ack oyiptong 16:21:34 oyiptong, you wanted to explain acceptance rate, redundancy and flexibility 16:21:36 ack mweksler 16:21:59 mweksler: I agree that my interpretation of oyiptong's proposal was single instrument, multiple tokens 16:22:09 ..and also agree with rationale of redundancy and flexibility 16:22:21 ...I think we should start with single instrument, single token first then move to multiple tokens 16:22:26 +1 16:22:44 q? 16:22:46 ack clintonra 16:23:05 clintonra: One thing I would highlight looking at this initially is that you may have a token provider that FAILS...hence value of multiple 16:23:15 ..you may also want to affiliate with multiple payment processors 16:23:26 ..I would also argue that this problem might also be solved by network tokens. 16:23:44 ..if you have access to network tokens, then your one token would work across multiple providers 16:23:52 q+ 16:26:26 IJ: Do 13-18 mean "the token-like thing is not yet a token but can be given by the merchant to the token providers to get the "real" token' 16:26:38 oyiptong: Yes...that's to illustrate a use case. 16:27:17 +q 16:27:20 ack ian 16:27:21 ack oyiptong 16:27:22 ack clintonra 16:28:12 q+ to explain why we have numbered token providers 16:28:48 manash: I don't know from the gateway token whether there is a list of params to be passed in by merchants to get access to gateway tokens 16:28:51 ...that could be a key or ID 16:28:59 ack oyiptong 16:28:59 oyiptong, you wanted to explain why we have numbered token providers 16:29:19 oyiptong: I want to respond a bit about why we have numbered tokenization providers and separate processors 16:29:26 +q 16:29:29 ...my initial assumption was that they were one in the same 16:29:41 ...so they are shown as separate though they could be the same 16:29:43 ack clintonra 16:30:04 clintonra: Part of the scope statement is that we are not talking about token sharing across parties.... 16:30:19 +1 16:30:21 ...if you want to move forward with multiple token provider scenario you need to have 1:1 relationship with processor. 16:31:28 +2! 16:31:42 https://github.com/w3c/webpayments-methods-tokenization/wiki 16:32:38 IJ: what are next steps with the issue, diagrams? 16:32:39 q? 16:32:40 q+ 16:32:42 ack oyiptong 16:33:02 oyiptong: I wanted to have the discussion. As Michel said, I think this can be an evolution rather than first feature. Ok to start with one token provider first. 16:33:22 IJ: even with one token, you still face question Clinton had. 16:33:52 IJ: The question seems to be - how does it work when token provider not same as processor? 16:33:59 oyiptong: I think issue is more apparent when there are multiple 16:34:07 ...but there is an unstated assumption that there is a relationship 16:34:17 IJ: let's make that explicit 16:35:00 I'm comfortable with this, I agree we are trying to solve too many problems at once and should focus on a small set of scenarios 16:35:22 Ian you dropped off 16:35:31 +drop ian 16:46:07 Topic: Next meeting 16:46:13 25 July 16:46:15 RRSAGENT, make minutes 16:46:15 I have made the request to generate http://www.w3.org/2017/07/18-wpwg-minutes.html Ian 16:46:19 RRSAGENT, set logs public 17:13:11 mweksler has joined #wpwg 18:02:21 hober has joined #wpwg