15:33:01 RRSAgent has joined #wpwg 15:33:01 logging to http://www.w3.org/2017/09/05-wpwg-irc 15:33:06 Meeting: Tokenization Task Force 15:33:19 Agenda: https://lists.w3.org/Archives/Public/public-payments-wg/2017Sep/0003.html 15:33:26 Present+ Simon 15:33:30 present+ mweksler 15:33:33 present+ oyiptong 15:33:36 present+ 15:33:37 Chair: Ian 15:33:47 Toipc: encrypted card draft 15:33:48 https://github.com/w3c/webpayments-methods-tokenization/wiki/encrypted_card 15:33:54 s/Toipc/Topic 15:34:00 present+ Keyur 15:34:26 https://github.com/w3c/webpayments-methods-tokenization/wiki/encrypted_card 15:35:02 oyiptong: Data is Basic Card, but encrypted 15:35:04 Sachin has joined #wpwg 15:35:13 present+ Sachin 15:35:24 [oyiptong walks through flow diagram] 15:35:53 oyiptong: Payment handler contacts vault provider, gets a key, encrypts card, and sends back to the merchant. 15:36:00 ..the merchant can save the encrypted data (if it wants) 15:36:17 present+ Ken 15:36:46 oyiptong: The request data for this spec would add a couple beyond Basic Card 15:36:49 https://github.com/w3c/webpayments-methods-tokenization/wiki/encrypted_card#paymentmethoddata-specification 15:37:04 ..the first new param is valueProviderURL to contact the vault 15:37:38 ...the data that is encrypted is the Basic Card response 15:38:14 ...response data is cardholderName, suffix, encryptedCardData 15:38:28 ..."suffix" is important to merchant as it can be shown to the user (for card on file) 15:38:52 https://github.com/w3c/webpayments-methods-tokenization/wiki/encrypted_card#tokenization-use-case 15:40:05 [Tokenization use case] 15:40:06 https://github.com/w3c/webpayments-methods-tokenization/wiki/encrypted_card#tokenization-use-case 15:40:38 oyiptong: In this use case, the payment app can request a token; that token is returned to the merchant 15:40:46 ...for example, Braintree does this 15:41:23 Ken_ has joined #wpwg 15:41:30 ...if gets a token, that is used instead of encryptedCardData 15:41:49 IJ: Why do encryption instead of directly going to tokenization? 15:42:50 ...the encryptedCardDat is sent to the vault provider and storing that 15:43:52 Sachin: SO we are encrypting the data for the vault... 15:43:54 q+ 15:44:53 Sachin: what is the benefit of sending the encrypted blob to the gateway? 15:45:27 ack mwek 15:45:29 ack mw 15:45:39 mweksler: Benefit of encrypted card is to avoid PCI scope 15:46:04 q+ 15:46:43 mweksler: How do we get the card details from the browser into a pic-trusted environment without going through the merchant? 15:48:07 keyur: Communication between payment handler and backend would be completely dependent on the (independent) payment app 15:48:31 ...from w3c payment request perspective, we should not go into detail about how payment handler communicates with backend 15:48:32 q+ 15:48:55 mweksler: that is not something that the specification defines. what we are trying to define is to be able to handle this case within PR API 15:50:14 Sachin: The two proposals are (1) encrypted card and (2) token...I think introducing the "vault" is a source of confusion. 15:51:11 Michel:I don't mind renaming it...want to make clear it is not in PCI scope and not the merchant 15:53:21 IJ: Can we talk about first flow first? 15:53:35 IJ: Could we change "vault" (which implies storage) to "keyProvider"? 15:53:54 oyiptong: It's outside scope of W3C on how merchant charges the card...the parties here are just shown as an illustration 15:54:06 ...the keyProvider or vault could even be the merchant with a separate infrastructure just for keys 15:54:45 Keyur: "Payment Handler Backend" also ok 15:55:12 ...some payment handlers have authentication. If someone wants to implement user authentication, those payment apps have their own user experiences 15:55:23 ..what I'm thinking is that the payment handler scope is what we need to define here. 15:55:30 ..the payment handler can provide a payment response 15:55:37 ...can also provide "add card" inside the payment handler 15:58:13 IJ: My understanding is that the proposal is to use web standards to get a key from an identified origin. 15:58:35 Keyur: Network call may not be necessary; key may be available on the device. 15:58:52 q? 15:58:55 ack me 15:58:58 ack oy 15:59:05 q+ to say Ian is hearing more abstraction 15:59:38 oyiptong: I am hearing that the payment app is outside PCI scope, and as long as it returns an opaque thing, the merchant is outside PCI scope 16:00:55 IJ: How would the payment app get opaque information without more information from the merchant? 16:01:13 keyur: suppose braintree invokes payment request, and payment handler that is launched has 2 cards 16:01:26 ...the payment handler has its own navigation screen and could prompt user to add card 16:01:45 s/braintree invokes/airbnb invokes 16:02:25 mweksler: The user has a card in chrome form fill, for example. We want the card to be usable by the merchant....but only as basic card 16:02:49 ...the question is "what should Airbnb pass to PR API so that it is eventually able to launch the brains tree handler and send info to braintree in order to use it." 16:03:05 ...airbnb says "I use braintree" and what I get back needs to be usable by braintree. 16:03:18 keyur: That was part of gateway params (expressing preferences of provider) 16:03:29 ...once you pass through preference to PR API.... 16:03:39 ...this could be used for payment app matching 16:08:13 adamR has joined #wpwg 16:09:14 q+ 16:09:39 ack me 16:09:39 Ian, you wanted to say Ian is hearing more abstraction 16:09:55 IJ: Reminder - we are not doing gateway params 16:10:01 ..focused on encrypted cards 16:10:11 Sachin: Thanks for the clarification 16:10:27 ...I want to think about it more...the merchant can say "These are the providers I like" 16:10:34 s/providers/processors/ 16:10:54 Sachin: I think term "vault" threw us off...let's focus on processors 16:11:42 q+ 16:11:55 IJ: Is it isomorphic to refer to a key provider or a processor? 16:11:58 ack oyiptong 16:12:16 oyiptong: I don't think the spec should dictate that the key provider and the processor must be the same entity 16:13:13 What are the use cases for key providers? 16:13:15 * Via the web 16:13:17 * on a device 16:13:21 ...how should they be identified? 16:13:30 Oyiptong: URL works in both cases 16:14:05 Three use cases: 16:14:11 - third party key provider 16:14:17 - merchant running server that is pci controlled 16:14:21 - on device key storage 16:14:50 +1 16:15:46 q+ 16:16:28 IJ: Why conflate with tokenization? 16:16:46 oyiptong: I wanted to show that there's a way to do this if we wanted to (re: token back) 16:17:04 ...we may want to do this because some processors implement tokenization this way...and they might be able to migrate to this at lower cost 16:17:09 ack oyiptong 16:17:21 ack Sach 16:17:37 Sachin: I think it makes more sense to manage these two as separate specs 16:18:10 ... I think we should address encrypted card and network tokens separately for now 16:18:15 ..and later see if we want to merge 16:18:48 topic: Encryption 16:19:06 oyiptong: there are a few ways we could identify how to do the encryption 16:19:13 q 16:19:33 https://github.com/w3c/webpayments-methods-tokenization/wiki/encrypted_card#discussion-encryption 16:20:09 oyiptong: three approaches: 16:20:13 through the public key in the TLS certificate of the vault provider if a manifest is not found or the parameter is not found in the manifest 16:20:13 through a Web App Manifest parameter on the vault provider's origin, specifying a public key and list of ciphers as defined by WebCrypto 16:20:13 through a public key provided as part of the PaymentMethodData dictionary 16:21:01 Oyiptong: Payment method manifest is on key provider origin; compared to merchant-provided key 16:21:29 Sachin: I like the manifest approach the best 16:21:33 ...first, it's clean and clear 16:21:45 ...second, it means the key provider needs to do something to comply with the w3c spec 16:22:30 Sachin has joined #wpwg 16:22:36 keyur: The API from where we get the key from the key provider, could that have metadata for the encryption? 16:22:52 oyiptong: That could be a way to get the key...there could be a way to do an exchange 16:22:58 ...e.g., what ciphers are available 16:24:19 IJ: What level of granularity does the merchant need? 16:24:36 Sachin: If there is a standard, then both parties follow the standard 16:24:50 q+ 16:24:59 mweksler: A few thoughts 16:25:15 ...if we prescribe something in the standard about encryption, we need to keep it up to date 16:25:25 ..ideally the standard would remain silent on exactly what encryption algorithm to use 16:25:37 ...secondly, I think the merchant has less responsibility what encryption mechanism to use 16:25:46 ..it's between the payment handler and the key provider 16:25:51 ..it's up to them to negotiate which cipher to use 16:26:07 ..that was one of the appealing components of using TLS, which allows for lists 16:27:26 IJ: Seems like using certificates adds benefit of third party certification (if you buy that) 16:28:25 keyur: When we handle PCI data, we want both pipe and data encryption 16:29:15 ...if the public certificate can act like a public key and we can do encryption with that, that's good 16:29:39 mweksler: +1 to the extra layer of encryption 16:29:46 ...we can do closer to end to end that way 16:30:20 ...I think certs do add value..let us use existing standards to check certs are valued, climb up the ladder, consider cert revocation, etc. 16:30:40 oyiptong: Certs are used for integrity, confidentiality, and authenticity 16:30:50 ...the chain helps with authenticity 16:31:05 ...for integrity, we use digital signatures (outside of the scope of this proposal) 16:31:51 ...for confidentiality, I guess TLS uses this slightly differently - it uses public key encryption to do the cert exchange, and then uses a generated cert for symmetric encryption of inflight comms 16:31:56 ...we lose that with a public key 16:33:09 Topic: Network tokenization 16:33:22 IJ: My understanding is that based on experimentation, you'll come back at the end of the month 16:33:26 Keyur: I did update this: 16:33:50 https://github.com/w3c/webpayments-methods-tokenization/wiki/Network-Tokens 16:34:08 https://w3c.github.io/webpayments-methods-tokenization/index.html 16:34:13 "Tokenized Card Payment" 16:34:36 ---> https://github.com/w3c/webpayments-methods-tokenization/wiki/Network-Tokens 16:34:58 Topic: Next meeting 16:35:09 19 Sep 16:36:14 RRSAGENT, make minutes 16:36:14 I have made the request to generate http://www.w3.org/2017/09/05-wpwg-minutes.html Ian 16:36:33 RRSAGENT, set logs public 16:38:30 adamR has joined #wpwg 17:14:13 adamR has joined #wpwg 17:22:17 mweksler has joined #wpwg 17:43:05 mweksler has joined #wpwg 17:44:13 mweksler_ has joined #wpwg 17:57:09 mweksler has joined #wpwg 17:57:38 mweksler has joined #wpwg 18:04:07 mweksler_ has joined #wpwg 18:06:13 mweksler_ has joined #wpwg 18:44:20 Zakim has left #wpwg 18:47:46 adamR has joined #wpwg 18:53:02 adamR has joined #wpwg 18:53:12 mweksler has joined #wpwg 19:49:40 mweksler has joined #wpwg 19:50:06 mweksler has joined #wpwg