15:28:56 RRSAgent has joined #wpwg 15:28:56 logging to http://www.w3.org/2017/07/25-wpwg-irc 15:29:12 Meeting: Tokenization Task Force 15:29:14 Chair: Ian 15:29:17 Regrets: Roy 15:29:37 Agenda: https://lists.w3.org/Archives/Public/public-payments-wg/2017Jul/0050.html 15:30:32 present+ 15:30:35 present+ Clinton 15:30:39 present+ SteveSommers 15:31:16 present+ SimonDix 15:31:19 present+ Olivier 15:31:26 present+ MattSaxon 15:32:10 MattS has joined #wpwg 15:32:23 shift4sms has joined #wpwg 15:33:11 regrets+ Manash 15:33:31 ==> https://lists.w3.org/Archives/Public/public-payments-wg/2017Jul/0050.html Agenda 15:34:08 Topic: Gateway params updates 15:34:09 https://github.com/w3c/webpayments-methods-tokenization/wiki/gateway_params 15:34:37 olivier: No changes; need to sync up with Keyur 15:34:49 present+ Christian 15:35:52 https://github.com/w3c/webpayments-methods-tokenization/issues/10 15:35:55 topic: Issue 10 15:36:10 Reminder here is gateway params wiki => https://github.com/w3c/webpayments-methods-tokenization/wiki/gateway_params 15:36:20 simon_dix has joined #wpwg 15:36:29 https://github.com/w3c/webpayments-methods-tokenization/wiki/gateway_params#token-providers-and-iin-routing 15:36:32 oyiptong:I want to speak to this issue with a diagram 15:36:45 https://user-images.githubusercontent.com/9365/27572522-63cf432a-5ac1-11e7-939a-cfb155c52411.png 15:36:50 ..the diagram illustrates a flow 15:37:08 ...typically we have several gateways, each of which connects to an acquirer 15:37:20 ...we may still want to do routing do a different acquirer even if we have one gateway 15:37:39 ...e.g., we might want to use an acquirer familiar with portuguese cards to increase acceptance rate 15:37:50 https://github.com/w3c/webpayments-methods-tokenization/wiki/gateway_params#payment-request-response 15:37:51 ...so that's the rationale for including the IIN in the payment response 15:38:33 IJ: Which party is doing the routing? 15:38:44 oyiptong: The merchant, based on first 6 digits of the credit card 15:39:00 Simon: FYI, that standard is in flux...it will go from 6 to 8 15:39:02 Ken has joined #wpwg 15:39:03 ...ISO 7812 15:39:10 present+ Ken 15:39:24 ...there are some intentions to adopt the 8-digit IIN 15:39:42 q+ 15:39:56 ack shif 15:40:14 SteveSommers: I have a quick question about 8-digit IIN. Is that just for longer cards? 15:40:23 ...that won't leave lots of numbers to tokenize 15:41:05 SimonDix: There are also discussion about longer PANs 15:41:10 ...but some issues around that as well 15:42:14 [More discussion about PAN length..] 15:42:53 q? 15:43:29 q+ 15:43:36 ack clin 15:44:16 clintonra: I am looking at the diagram. If I understand correctly, the response from the payment handler includes the IIN. The expectation is that this will include some information that merchant can be used for routing. 15:44:18 q+ 15:45:02 clintonra: The payment handler gets a token back from the token provider. either the handler retains the IIN portion or something that can be used for oruting 15:45:21 oyiptong: Right now we use IIN for routing, but if something else comes up that we can use for routing, we would use that. 15:45:42 ...many merchants build models to improve acceptance through routing 15:45:47 q? 15:45:50 ack oyiptong 15:45:52 q+ 15:45:59 clintonra: I understand the use case. Thank you. 15:46:57 IJ: Should we talk about "routingInformation" here and allow for some flexibility? 15:47:05 q+ 15:47:12 oyiptong: I can see that. 15:47:31 IJ: Is there something else in practice? Would you need type information in addition? 15:47:33 ack Matt 15:47:36 ack ian 15:47:47 MattS: I think adding routing information at this phase is premature optimization. 15:48:00 ..I'd rather stick with IIN for now. 15:48:06 q+ 15:48:18 ack clinton 15:48:55 q+ 15:49:08 clintonra: I understand the need for routing information. But in the use cases diagram, the response back from the token provider...what I'm trying to figure out is that ...when you receive a token and you receive which token you are going to route, aren't you already inherently selecting the acquirer in the selection 15:49:26 ...I come back to the scope statement ... limiting token-to-processor as 1-1 relationship. 15:49:33 ..the routing is linked to whoever provided the token 15:49:40 ..in what situation would the routing be beneficial? 15:49:41 ack oy 15:50:13 oyiptong: One gateway gives us access to multiple acquirers. Most of our gateways allow us to choose which acquiring bank we want to use. So it's 1:1 with the gateway, but not the acquirer. 15:50:25 clintonra: And the assumption is that the merchant, not the gateway, needs to make the decision? 15:50:45 oyiptong: Yes. The gateway provides APIs but we (the merchant) have to choose the acquirer. 15:51:08 +1 15:51:21 +1 15:51:25 PROPOSED: Keep IIN in the spec 15:51:27 +1 15:51:27 +1 15:51:31 +1 15:51:36 SO RESOLVED 15:52:29 Topic: Issue 11 15:52:33 https://github.com/w3c/webpayments-methods-tokenization/issues/11 15:52:46 oyiptong: We discussed. I think it should not be in the spec for now. 15:53:08 +1 15:53:13 Question - might this be a gateway specific solution? As a gateway, we choose the routing for the merchant based on setup/negotiation with the merchant. From what I have seen of my competitors, I'm not aware of acquirer specific APIs through the gateway. 15:53:16 IJ: Please point to discussion in GitHub and close for now. 15:53:17 +1..... for now 15:53:51 q+ 15:53:59 ack MattS 15:54:25 MattS: Our gateway allows merchant to leave information out and Worldpay does routing, OR we allow merchant to provide routing rules 15:54:34 ..and we are aware of customers who have multiple gateways 15:54:42 ...so I agree this is a complex relationship. 15:56:30 Topic: Issue 12 15:56:30 https://github.com/w3c/webpayments-methods-tokenization/issues/12 15:57:19 Should the response data include an "expires" field? 15:57:33 q+ 15:57:36 q+ 15:57:41 ack shift4sms 15:57:52 SteveSommers: By expires are you referring to the token? 15:57:55 Ian: Yes. 15:59:18 https://github.com/w3c/webpayments-methods-tokenization/wiki 15:59:35 If it's optional, I would say yes, add it. 15:59:38 https://github.com/w3c/webpayments-methods-tokenization/wiki/Network-Tokens 16:00:37 MattS: If gateway params is where we do updates, I'm fine with that. But the structure of the article is discursive 16:00:53 ..I've raised some issues 16:02:40 MattS: Another observation ... one of the reasons I raised so many issues is that wikis don't lend themselves to PRs. 16:02:44 ..I suggest we move it into respec 16:03:01 +1 16:03:14 q+ 16:04:10 ack oy 16:04:26 Ian: My mild pref early in the life of a document is very easy editing 16:04:53 oyiptong: I think I feel it might be too early to make it look like a spec...but maybe I'm wrong 16:05:06 ..but if people want to move to respect (with light review) I am ok 16:05:14 MattS: I would say that the person who contributes the most choose choose the tooling. 16:05:37 oyiptong: I would punt a bit more until we have consensus with master card folks (at least) 16:05:44 ...+1 to moving to respec once more stable 16:06:36 q? 16:06:49 +q 16:06:53 ack oy 16:07:11 oyiptong: I want to give the merchant perspective on the expires field: I think it would be "nice" but sometimes it's hard to predict. 16:07:33 ..as far as we go, I think that we try a payment and if doesn't work we do something else. We might get an error response from the gateway and deal with it. 16:07:49 ...I think the expires field is "nice to have" but I'm not sure if it's the primary source of information for invalidation. 16:08:12 IJ: Please add a sentence to the GitHub issues list 16:08:16 ..on that topic 16:08:31 topic: Issue 20 16:08:32 https://github.com/w3c/webpayments-methods-tokenization/issues/20 16:08:44 q+ 16:09:00 MattS: If the merchant has saved the token, then it seems the merchant would want "expires". 16:09:15 ...for oneTime use, expires is less useful since you just got the token 16:09:23 ack oy 16:09:41 oyiptong: My intention was this - token would not be included in subsequent transactions. 16:09:59 mattS: Expiry can still be useful in oneTimeUse - you could use it later 16:10:10 ..you could authorize the transaction at one point and then capture the payment later using the same token. 16:10:15 oyiptong: We do use that pattern. 16:10:27 ..the timeout for this probably differs based on the processor. I think for us it's "within 3 hours" 16:10:36 MattS: That's why I think optionally it should be in the data 16:10:42 oyiptong: +1. I agree with you 16:10:59 MattS: A multi-use token COULD be provided again and again to a merchant for multi-use 16:11:11 ..if the merchant doesn't want to store it, you could argue that there are pros and cons from a security POV. 16:11:23 ..I think "MAY not be returns" is more accurate than "will not be returns" 16:11:40 oyiptong: I implemented a feature for this. Right above subsequent card info there is a tokenprovider-merchant identifier 16:11:51 ..this one is stored in the client by the payment handler 16:11:52 tokenProviderMerchantIdentifier 16:12:03 (see this issue => https://github.com/w3c/webpayments-methods-tokenization/issues/18 ) 16:12:25 mattS: Ah, I read this as the "merchant's identifier, at the token provider" not "the token's identifier" 16:12:34 oyiptong: The idea is that we don't want to store the token on the client either 16:12:41 ...the token could be obtained maliciously 16:13:00 ...so the token itself is not persistent. It is only sent the first time to the merchant 16:13:15 ..for subsequent use, the merchant gets an identifier 16:13:36 mattS: That wasn't apparent in the text. E.g., Apple Pay stores a token on the secure element of the phone, with an additional cryptogram 16:13:50 ...each time you create a one-time token based on the stored token 16:14:17 oyiptong: Right, this tokenProviderMerchantIdentifier is derived from the token. 16:14:24 +1 16:14:25 MattS: Please explain the usage of it in the document 16:14:45 (IJ: asks that oyiptong also look in the issues list and add explanatory notes) 16:15:15 IJ: How far did we get in answering 20? 16:15:51 MattS: I said "could be return multiple times" and oyiptong said "secure elements are sometimes used".... 16:15:55 ...effectively all the tokens are "one time" 16:15:59 ..I'm starting to get it! 16:16:09 ...I need to go back and think about it 16:16:41 Topic: Issue 16 16:16:42 https://github.com/w3c/webpayments-methods-tokenization/issues/16 16:16:49 Where does tokenisation occur in the the flow - and do we care? 16:17:26 (IJ reads from the issue) 16:18:06 q+ 16:18:32 IJ: I think things like the diagram need to be updated; tokenization can happen outside of flow or token might be cached. 16:18:35 ack clintonra 16:18:58 clintonra: There may be scenarios where the token that you retain independent of authorization would require additional information at time of authorization 16:19:26 ...it might be worthwhile to have an indicator whether a token is usable "ON ITS OWN" or whether more information is required "AT TIME OF AUTHORIZATION" 16:20:33 ...so there may be some scenarios where you can't simply use "what's stored" without more authorization 16:21:05 ...Let me use network tokens as an example. 16:21:46 q+ 16:21:55 ...suppose you receive a network token ... the token response might include information unique to the transaction...if the token is multi-use and it were decoupled from later authorization, the token might only be useful in conjunction with something else unique to each transaction (e.g., cryptogram) 16:21:57 ack oyiptong 16:22:12 oyiptong: in network token situation, if I am hearing, you may require some additional information for subsequent use 16:22:39 oyiptong: I think this is a point where network tokens and gateway tokens diverse 16:22:44 s/diverse/diverge 16:23:32 ..I think for gateway tokens we want for offline use...but it's not clear for me that this is the same use case for network tokens..if the user is online, the network token spec, I guess, could include information... 16:23:51 clintonra: Do we have anything documented around what "online use of token" means v "offline use of token" 16:23:59 oyiptong: My definition is "user is online at the time of transaction?" 16:24:19 ...more specifically: "a party can get more information from the user, e.g., for authorization" 16:24:32 MattS: Might reach user through text (instead of HTTP, for example) 16:25:06 clintonra: I like MattS's framing - whoever is responsible for cardholder authorization is available for interaction 16:25:20 oyiptong: I think it might be useful to think about this as synchronous / asynchronous 16:25:39 MattS: What about real-time (matter of seconds) v. non-real-time (matter of hours) 16:25:44 oyiptong: that's correct 16:26:08 oyiptong: regarding "additional information" mentioned by clinton, ideally for subsequent card usage, you want to minimize user interactions 16:26:23 ..it's hard to request that the user do something (complete challenges) in a non-real-time way 16:27:09 clintonra: Great point. the idea that within this token request API there is a sense of "real-time transaction"...from a payment request perspective, is there something that's necessary to enable the merchant to say what they expect to do with the response (e.g., to use over a short period of time or an extended period of time)? 16:27:18 q+ 16:27:43 ack oyiptong 16:28:05 oyiptong: I think that it might be partly a failure on my part to articulate this...the intention for having this ID for subsequent card usage is precisely for something like a subscription. 16:28:26 ...the merchant gets the token...for a single transaction there is an ID passed, but the ID is on the merchant side for subsequent use 16:28:51 ...the merchant has the token...and the intention is to charge the user later; I can add prose. 16:29:08 Can I suggest we articulate such prose as a set of scenarios 16:29:11 Topic: 8 August 16:29:16 in a separate wiki article 16:29:27 Topic: Next meeting 16:29:28 8 August 16:29:44 RRSAGENT, make minutes 16:29:44 I have made the request to generate http://www.w3.org/2017/07/25-wpwg-minutes.html Ian 16:29:49 RRSAGENT, set logs public 17:31:55 AdrianHB has joined #wpwg 17:36:06 AdrianHB has joined #wpwg 17:46:20 AdrianHB has joined #wpwg 19:31:53 adamR has joined #wpwg 23:31:50 cweiss has joined #wpwg