IRC log of wpwg on 2017-09-19
Timestamps are in UTC.
- 15:30:04 [RRSAgent]
- RRSAgent has joined #wpwg
- 15:30:04 [RRSAgent]
- logging to http://www.w3.org/2017/09/19-wpwg-irc
- 15:30:25 [Ian]
- Meeting: Tokenization Task Force
- 15:30:27 [Ian]
- Chair: Ian
- 15:30:35 [Ian]
- present+ Chris_Marconi
- 15:30:37 [Ian]
- present+
- 15:30:40 [Ian]
- present+ oyiptong
- 15:31:01 [Ian]
- Agenda: https://lists.w3.org/Archives/Public/public-payments-wg/2017Sep/0032.html
- 15:31:06 [Ian]
- RRSAGENT, make minutes
- 15:31:06 [RRSAgent]
- I have made the request to generate http://www.w3.org/2017/09/19-wpwg-minutes.html Ian
- 15:32:14 [alyver]
- alyver has joined #wpwg
- 15:32:59 [Ian]
- present+ Ken
- 15:33:21 [Ian]
- present+ LauraTownsend
- 15:33:24 [Ian]
- present+ alyver
- 15:33:27 [Ian]
- regrets+ NickTR
- 15:34:00 [Ken_]
- Ken_ has joined #WPWG
- 15:34:22 [Ian]
- regrets+ Manash
- 15:35:15 [Ian]
- topic: Encrypted Card
- 15:35:16 [Ian]
- https://github.com/w3c/webpayments-methods-tokenization/wiki/encrypted_card
- 15:35:29 [Ian]
- Olivier: I updated some terminology
- 15:35:37 [Ian]
- ...from Vault Provider to Key Provider
- 15:35:50 [Ian]
- ...I added some descriptions to encryption mechanisms
- 15:36:25 [oyiptong]
- https://user-images.githubusercontent.com/9365/30331535-f15110d6-978c-11e7-8ed0-a5aaa28547d6.png
- 15:36:52 [Ian]
- ...the encryption exchange is either done right after the browser hands control to the payment handler, who contacts the key provider
- 15:37:10 [Ian]
- ...or there's an option (3) where the payment method data includes the information necessary to generate the encrypted card data
- 15:37:22 [Ian]
- ...that would be given via the parameters (shown in IDL)
- 15:37:24 [oyiptong]
- https://github.com/w3c/webpayments-methods-tokenization/wiki/encrypted_card#3-encryption-options-specified-in-paymentmethoddata
- 15:37:38 [Ian]
- ..and this data would plug into the Web Crypto API
- 15:38:04 [Ian]
- ...the idea is that the merchant provides the key and algo information up front, but cannot decrypt the payload, and a key provider is in the loop later
- 15:38:13 [Ian]
- ..so that merchant page is outside PCI-DSS scope
- 15:38:23 [alyver]
- q+
- 15:38:35 [Ian]
- ack alyver
- 15:38:37 [lte]
- lte has joined #wpwg
- 15:38:46 [Ian]
- alyver: Question on the three methods - from my experience #3 is the more common use cases
- 15:38:49 [Ian]
- s/cases/case
- 15:39:00 [Ian]
- ...when I think of Android pay, for example, #3 is how it's done
- 15:39:10 [Ian]
- oyiptong: I think #3 is the best way to do this; it's easy
- 15:40:50 [Ian]
- IJ: So have you been socializing this? Is it interesting?
- 15:41:11 [Ian]
- oyiptong: From what I've understood, there is interest. E.g., option #3 is desirable for small merchants. It's simple and low-cost to implement.
- 15:41:21 [Ian]
- ...we've also spoken with a payment processor who expressed interest.
- 15:42:22 [Ian]
- IJ: Oliiver, what feedback would you most like?
- 15:42:37 [Ian]
- oyiptong: Viability (e.g., from processor POV)
- 15:42:47 [Ian]
- ...also feedback from merchants on the PCI DSS scope reduction
- 15:42:55 [Ian]
- ..also whether the payment method data declaration makes sense
- 15:43:06 [Ian]
- ..and also from traditional payment gateways on whether valuable.
- 15:43:48 [Ian]
- ACTION: Chris to review the proposal and send comments.
- 15:43:49 [trackbot]
- Created ACTION-66 - Review the proposal and send comments. [on Chris Marconi - due 2017-09-26].
- 15:44:09 [Ian]
- IJ: You can use the issues list
- 15:44:20 [oyiptong]
- q+
- 15:44:24 [Ian]
- ack oyiptong
- 15:44:37 [Ian]
- oyiptong: One thing I want to clarify - the tokenization extension use case is only an EXAMPLE of an extension.
- 15:44:47 [Ian]
- IJ: Please clarify the two parts
- 15:45:01 [Ian]
- oyiptong: First part is proposal to encrypt card data (stops after "discussion" section).
- 15:45:29 [Ian]
- ..the next part is called "tokenization extension use case" ... which is there for discussion but should not be considered part of the "encryption" part of the proposal (part 1).
- 15:45:58 [Ian]
- IJ: How long for your review, Chris?
- 15:46:02 [Ian]
- Chris: End of this week
- 15:46:09 [Ian]
- Topic: Tokenization
- 15:46:23 [Ian]
- IJ: Postponed until early October
- 15:48:04 [Ian]
- Topic: Adrian Hope-Bailie idea
- 15:48:12 [Ian]
- https://lists.w3.org/Archives/Public/public-payments-wg/2017Sep/0032.html
- 15:49:55 [Ian]
- present+ Keyur
- 15:51:18 [oyiptong]
- q+
- 15:51:24 [Ian]
- IJ: Any initial thoughts on the idea of an indirection through the gateway to avoid exposing PAN?
- 15:51:29 [Ian]
- ====
- 15:51:29 [Ian]
- 1) The handler sends the card details of a secure connection to
- 15:51:29 [Ian]
- the gateway (using a URL provided in the payment request) and
- 15:51:29 [Ian]
- gets back a reference of some kind which it passes to the
- 15:51:30 [Ian]
- merchant in the PaymentResponse.
- 15:51:31 [Ian]
- 2) The merchant then submits the payment to the gateway with the
- 15:51:32 [Ian]
- reference instead of the card details and also all of the other
- 15:51:34 [Ian]
- contextual data that the gateway requires. The gateway would then
- 15:51:36 [Ian]
- use the reference to loo kup the card details it has in temporary
- 15:51:38 [Ian]
- storage and process the payment.
- 15:51:40 [Ian]
- This is subtly different in that the reference would be a single
- 15:51:42 [Ian]
- use value for a set amount. The gateway may also provide the
- 15:51:44 [Ian]
- merchant with a customer identifier that is consistent across
- 15:51:46 [Ian]
- multiple uses of the same card to assist the merchant with
- 15:51:48 [Ian]
- customer engagement.
- 15:51:50 [Ian]
- ====
- 15:51:54 [Ian]
- oyiptong: Payment method request data includes a URL, payment handler communicates with that URL, passes a ref back to the merchant.
- 15:52:01 [Ian]
- ..sounds similar to the tokenization flow
- 15:52:01 [alyver]
- q+
- 15:52:08 [Ian]
- ...to the tokenization extension use case.
- 15:52:21 [Ian]
- ...minus the encryption part
- 15:52:34 [Ian]
- https://w3c.github.io/webpayments-methods-tokenization/index.html
- 15:52:43 [oyiptong]
- https://user-images.githubusercontent.com/9365/28303430-031ea6c8-6b48-11e7-8d41-f7558ddd76db.png
- 15:53:23 [Ian]
- oyiptong: In that diagram, after the browser hands over control, the payment handler contacts a service (here, a gateway)
- 15:53:46 [Ian]
- ...sends the PAN and gets back a reference. (Originally it was a token; AHB's proposal suggests that it's a reference possibly of another type)
- 15:54:35 [Ian]
- ack aly
- 15:54:38 [Ian]
- ack oy
- 15:54:54 [Ian]
- alyver: This seems to be the same as the gateway tokenization flow we discussed before, as oyiptong pointed out.
- 15:56:21 [Ian]
- IJ: There was not support for gateway proposal due to gateways not stepping up to do payment handlers. I'm not sure why this proposal is different.
- 15:56:47 [Ian]
- alyver: There might be an opportunity to define a standard for what data is sent to the gateway
- 15:56:58 [Ian]
- (IJ thinks Olivier had something like that in the gateway proposal)
- 15:57:14 [Ian]
- ...I also think the browser could act as a payment handler here, and not integrate with N providers; just integrating with one API.
- 15:58:11 [Ian]
- https://github.com/w3c/webpayments-methods-tokenization/wiki/gateway_params#data-exchanged-between-payment-app-and-tokenization-provider
- 15:59:23 [Ian]
- Topic: Network tokenization
- 15:59:37 [Ian]
- Keyur: We are having some discussions, and trying to implement in a real-life scenario
- 15:59:48 [Ian]
- ...merchant can get a token and process it (or their PSP can)
- 16:00:01 [Ian]
- ..right now we are looking at whether to use test system or production site for demo
- 16:00:36 [Ian]
- ...right now we are using a custom payment method spec; we would break it back to the task force for discussion
- 16:00:57 [Ian]
- topic: TPAC
- 16:01:19 [Ian]
- https://github.com/w3c/webpayments/wiki/FTF-Nov2017
- 16:02:00 [Ian]
- IJ: What should we present?
- 16:02:14 [oyiptong]
- q+
- 16:02:19 [Ian]
- ack oyiptong
- 16:02:45 [Ian]
- oyiptong: I would like to present encrypted card ... Browser implementation would be very interesting (autofill)
- 16:03:00 [Ian]
- ...it would be great to get supporting statements
- 16:03:13 [Ian]
- IJ: what is strategy for securing supporting statements?
- 16:03:18 [Ian]
- oyiptong: Identify stakeholders
- 16:03:37 [Ian]
- ...we can also ask browsers what would convince them (then get those statements)
- 16:04:00 [Ian]
- IJ: What about code to show demo or ease of use by merchant?
- 16:04:28 [Ian]
- oyiptong: I can implement a shim
- 16:05:37 [Ian]
- ACTION: Olivier to implement some example code to show how it works
- 16:05:37 [trackbot]
- 'Olivier' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., omaas, oyiptong).
- 16:07:32 [Ian]
- q?
- 16:07:39 [Ian]
- topic: Next meeting
- 16:08:15 [Ian]
- Tuesday, 3 October
- 16:08:29 [oyiptong]
- +1
- 16:08:45 [Ian]
- RRSGENT, make minutes
- 16:08:48 [Ian]
- RRSAGENT, set logs public
- 16:10:37 [Ian]
- RRSAGENT, make minutes
- 16:10:37 [RRSAgent]
- I have made the request to generate http://www.w3.org/2017/09/19-wpwg-minutes.html Ian
- 16:10:38 [Ian]
- RRSAGENT, set logs public
- 16:14:27 [AdrianHB]
- AdrianHB has joined #wpwg
- 16:52:53 [alyver]
- alyver has joined #wpwg
- 18:06:42 [AdrianHB]
- AdrianHB has joined #wpwg
- 18:23:39 [Zakim]
- Zakim has left #wpwg
- 18:44:38 [AdrianHB]
- AdrianHB has joined #wpwg