15:30:51 RRSAgent has joined #wpwg 15:30:51 logging to http://www.w3.org/2017/06/20-wpwg-irc 15:30:55 Zakim has joined #wpwg 15:31:12 Meeting: Tokenization Task Force 15:31:15 Chair: Ian 15:31:30 Agenda: https://lists.w3.org/Archives/Public/public-payments-wg/2017Jun/0021.html 15:33:06 Ken has joined #wpwg 15:33:18 regrets+ Roy 15:33:20 present+ 15:33:23 present+ oyiptong 15:33:25 present+ Clinton 15:33:30 present+ mweksler 15:33:33 present+ keyur 15:33:47 present+ Ken 15:33:51 present+ alyver 15:34:09 present+ michel_cc 15:34:16 alyver has joined #wpwg 15:34:37 Topic: Any updates to the Gateway Tokenization description 15:34:47 https://github.com/w3c/webpayments-methods-tokenization/wiki/gateway_params 15:34:54 (Changed recently!) 15:35:25 oyiptong: mweksler and I worked on the text a bit and we'd like to share it 15:35:30 present+ Steve 15:35:48 ...we took previous feedback into account 15:35:49 ...updated the diagram 15:36:03 ....e.g., moved from "browser" to "payment handler" 15:36:07 shift4sms has joined #wpwg 15:36:15 ...at step 7 the response from the tokenization response provider says its an instrument token 15:36:24 ...the order of operations remained roughly unchanged 15:36:36 ...now says clearly that comms between tokenization provider and merchant is outside of the scope of the spec 15:36:49 ...in the diagram, shown in a box 15:37:22 ...also added a diagram for a use case where tokenization provider is different from payment processor 15:37:31 ...there's an example flow showing how spec would work in this case 15:38:29 ...I also added an "optional feature" -> oneTimeUse boolean in the request 15:38:44 ....Optionally, the merchant could provide a oneTimeUse parameter, which signals to the payment app that this payment method is not to be saved for subsequent use. 15:38:57 ...in the response the server can override the preferences 15:39:28 ....how the client handles the onetimeuse request is to not store the ID 15:39:58 Keyur: On subsequent card usage if a onetime use token, it will still ask the token provider to generate a new token? 15:40:01 oyipton: Yes 15:40:48 Use case: Nonce passing 15:41:01 ..tokenization provider passes back a nonce 15:41:11 ..the payment handler sends payload, including nonce, back to the merchant 15:41:24 ...the merchant will know how to handle it due to out-of-band agreement with tokenizer and merchant 15:41:32 Use case: 15:41:32 Use case: 15:41:32 Direct Token Passing 15:41:45 ...in this case, actual token is sent 15:41:55 This behavior is entirely up to the merchant and the token provider. A token-provider-merchant-identifier is still generated and the token is never stored on disk by the Payment Handler. 15:42:02 This saves one roundtrip by the merchant to the token provider, at the cost of security, but gaining in convenience. 15:42:09 ...this satisfies a request on GitHub from Keyur 15:42:27 Keyur: Also ties into the EMVCo tokenization..t.hat's what I was trying to go towards 15:42:44 ...I am still looking at your request/response to accommodate EMVCo tokenization 15:43:10 ...which would mean there is only one gateway + EMV tokenization spec 15:43:26 Use case: Token Providers and Payment Processors are two different entities 15:43:57 ..in short - this is possible but out of scope for the spec 15:44:11 Keyur: Are we saying that the tokenization provider URL is the identifier for the tokenization provider 15:44:50 IJ: tokenProviderURL is serving two purposes - matching and contacting? 15:44:52 oyiptong: Yes 15:46:05 q? 15:46:59 IJ: Should direct and nonce use cases be moved up? 15:47:38 ...or a link to "more use cases" after first diagram 15:47:40 oyiptong: +1 15:48:07 IJ: Any pending edits from oyiptong / michel? 15:48:20 Keyur: How do we perform 3DS as a step-up? 15:48:48 ...are we saying that once we go back to merchant page where merchant can do 3DS based on processor capability? 15:49:28 https://github.com/w3c/webpayments-methods-tokenization/wiki 15:51:25 ...in the case of network tokens, it's already taken into account to pass auth data which is passed to the network 15:51:46 ..but for gateway tokens, ultimately what travels through payment processor is FPAN...and there is no auth data. 15:52:07 ...3DS is the only way right not to perform additional authentication....3DS 2.0 could be interesting 15:52:15 ....allows in-app step-up auth 15:53:33 ...this is a "v2" sort of thing by the way 15:54:04 ..my first statement is that when I go back to the merchant page after providing information (token or nonce)...in that case the merchant can, today, do 3DS...but it's out of scope for the W3C APIs 15:54:20 ...so the merchant is free to perform step -up (but out of scope for W3C0 15:55:24 q? 15:56:01 oyiptong: We could also discuss what the burden is on the merchant to display the information properly 15:56:11 ...what would it look like, e.g., for same card to be presented multiple times. 15:57:29 https://github.com/w3c/webpayments-methods-tokenization/issues 15:58:04 Topic: Network tokenization update 15:58:16 IJ: Any updates from recent conversation? 15:58:32 keyur: Work in progress...we are likely to add some params to gateway spec for network tokens 15:58:37 ...so hopefully by this weekend. 15:58:56 IJ: Where will edits happen? 15:59:17 Keyur: I would create a separate page to noodle on network tokens, then merge later in single tokenization spec. 15:59:27 https://github.com/w3c/webpayments-methods-tokenization/wiki/network_params 16:00:30 For questions while I am unavailable, contacting Mike Smith 16:00:38 or Philippe Le Hegaret 16:00:56 filed an issue: Payment Method declaration may show duplicate card descriptions https://github.com/w3c/webpayments-methods-tokenization/issues/9 16:00:59 q+ 16:01:00 thanks! 16:01:02 ack oyi 16:02:00 topic: Issue 8 16:02:07 oyiptong: Can we close with gateway params update? 16:02:11 Keyur: yes 16:02:14 RESOLVED: Close issue 8 16:02:22 RRSAGENT, make minutes 16:02:22 I have made the request to generate http://www.w3.org/2017/06/20-wpwg-minutes.html Ian 16:02:27 RRSAGENT, set logs public 16:02:40 Topic: Bin bank id 16:03:03 Clinton: Can use IIN and BIN 16:03:08 Less formal, but BIN is more common 16:03:11 IIN is managed by ANSI, BIN is less formal 16:05:11 oyiptong: Are you saying, Keyur, token provider should route? 16:05:15 I said ANSI.. ment ISO 16:05:24 Keyur: Let's keep it out until we have a use case where merchant needs BIN 16:06:19 ACTION: oyiptong will raise an issue about whether BIN is required (or something similar) in response. 16:06:20 Created ACTION-61 - Will raise an issue about whether bin is required (or something similar) in response. [on Olivier Yiptong - due 2017-06-27]. 16:06:40 Topic: Issue 5 16:06:41 https://github.com/w3c/webpayments-methods-tokenization/issues/5 16:06:58 issue for ACTION-61 https://github.com/w3c/webpayments-methods-tokenization/issues/10 16:07:13 IJ: Please look at issue 5, Keyur 16:08:23 Topic: Next meeting 16:08:26 Proposed 11 July 16:08:53 +1 16:09:00 SO RESOLVED 16:09:39 RRSAGENT, make minutes 16:09:39 I have made the request to generate http://www.w3.org/2017/06/20-wpwg-minutes.html Ian 16:09:47 RRSAGENT, set logs public 16:56:54 alyver has joined #wpwg 17:04:15 betehess has joined #wpwg 17:16:52 cweiss has joined #wpwg 17:32:35 alyver has joined #wpwg 17:52:27 betehess has joined #wpwg 18:11:44 alyver has joined #wpwg 18:27:57 Zakim has left #wpwg 18:30:32 alyver has joined #wpwg 18:30:59 alyver has joined #wpwg 18:42:47 cweiss has joined #wpwg 18:59:15 alyver has joined #wpwg 19:48:52 betehess has joined #wpwg 20:07:44 betehess has joined #wpwg 20:58:17 betehess has joined #wpwg 21:02:29 cweiss has joined #wpwg 21:02:47 betehess has joined #wpwg 22:34:50 betehess has joined #wpwg 22:43:16 betehess has joined #wpwg