Tokenization Task Force

05 Sep 2017


See also: IRC log


Simon, mweksler, oyiptong, Ian, Keyur, Sachin, Ken


encrypted card draft


<oyiptong> https://github.com/w3c/webpayments-methods-tokenization/wiki/encrypted_card

oyiptong: Data is Basic Card, but encrypted

[oyiptong walks through flow diagram]

oyiptong: Payment handler contacts vault provider, gets a key, encrypts card, and sends back to the merchant.
... the merchant can save the encrypted data (if it wants)
... The request data for this spec would add a couple beyond Basic Card

<oyiptong> https://github.com/w3c/webpayments-methods-tokenization/wiki/encrypted_card#paymentmethoddata-specification

oyiptong: the first new param is valueProviderURL to contact the vault
... the data that is encrypted is the Basic Card response
... response data is cardholderName, suffix, encryptedCardData
... "suffix" is important to merchant as it can be shown to the user (for card on file)

<oyiptong> https://github.com/w3c/webpayments-methods-tokenization/wiki/encrypted_card#tokenization-use-case

[Tokenization use case]


oyiptong: In this use case, the payment app can request a token; that token is returned to the merchant
... for example, Braintree does this
... if gets a token, that is used instead of encryptedCardData

IJ: Why do encryption instead of directly going to tokenization?
... the encryptedCardDat is sent to the vault provider and storing that

Sachin: SO we are encrypting the data for the vault...
... what is the benefit of sending the encrypted blob to the gateway?

mweksler: Benefit of encrypted card is to avoid PCI scope
... How do we get the card details from the browser into a pic-trusted environment without going through the merchant?

keyur: Communication between payment handler and backend would be completely dependent on the (independent) payment app
... from w3c payment request perspective, we should not go into detail about how payment handler communicates with backend

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

Sachin: The two proposals are (1) encrypted card and (2) token...I think introducing the "vault" is a source of confusion.

Michel: I don't mind renaming it...want to make clear it is not in PCI scope and not the merchant

IJ: Can we talk about first flow first?
... Could we change "vault" (which implies storage) to "keyProvider"?

oyiptong: It's outside scope of W3C on how merchant charges the card...the parties here are just shown as an illustration
... the keyProvider or vault could even be the merchant with a separate infrastructure just for keys

Keyur: "Payment Handler Backend" also ok
... some payment handlers have authentication. If someone wants to implement user authentication, those payment apps have their own user experiences
... what I'm thinking is that the payment handler scope is what we need to define here.
... the payment handler can provide a payment response
... can also provide "add card" inside the payment handler

IJ: My understanding is that the proposal is to use web standards to get a key from an identified origin.

Keyur: Network call may not be necessary; key may be available on the device.

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

IJ: How would the payment app get opaque information without more information from the merchant?

keyur: suppose airbnb invokes payment request, and payment handler that is launched has 2 cards
... the payment handler has its own navigation screen and could prompt user to add card

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
... 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."
... airbnb says "I use braintree" and what I get back needs to be usable by braintree.

keyur: That was part of gateway params (expressing preferences of provider)
... once you pass through preference to PR API....
... this could be used for payment app matching

<Zakim> Ian, you wanted to say Ian is hearing more abstraction

IJ: Reminder - we are not doing gateway params
... focused on encrypted cards

Sachin: Thanks for the clarification
... I want to think about it more...the merchant can say "These are the processors I like"
... I think term "vault" threw us off...let's focus on processors

IJ: Is it isomorphic to refer to a key provider or a processor?

oyiptong: I don't think the spec should dictate that the key provider and the processor must be the same entity

What are the use cases for key providers?

* Via the web

* on a device

scribe: how should they be identified?

Oyiptong: URL works in both cases

Three use cases:

- third party key provider

- merchant running server that is pci controlled

- on device key storage

<oyiptong> +1

IJ: Why conflate with tokenization?

oyiptong: I wanted to show that there's a way to do this if we wanted to (re: token back)
... 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

Sachin: I think it makes more sense to manage these two as separate specs
... I think we should address encrypted card and network tokens separately for now
... and later see if we want to merge


oyiptong: there are a few ways we could identify how to do the encryption



oyiptong: three approaches:

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

through a Web App Manifest parameter on the vault provider's origin, specifying a public key and list of ciphers as defined by WebCrypto

through a public key provided as part of the PaymentMethodData dictionary

Oyiptong: Payment method manifest is on key provider origin; compared to merchant-provided key

Sachin: I like the manifest approach the best
... first, it's clean and clear
... second, it means the key provider needs to do something to comply with the w3c spec

keyur: The API from where we get the key from the key provider, could that have metadata for the encryption?

oyiptong: That could be a way to get the key...there could be a way to do an exchange
... e.g., what ciphers are available

IJ: What level of granularity does the merchant need?

Sachin: If there is a standard, then both parties follow the standard

mweksler: A few thoughts
... if we prescribe something in the standard about encryption, we need to keep it up to date
... ideally the standard would remain silent on exactly what encryption algorithm to use
... secondly, I think the merchant has less responsibility what encryption mechanism to use
... it's between the payment handler and the key provider
... it's up to them to negotiate which cipher to use
... that was one of the appealing components of using TLS, which allows for lists

IJ: Seems like using certificates adds benefit of third party certification (if you buy that)

keyur: When we handle PCI data, we want both pipe and data encryption
... if the public certificate can act like a public key and we can do encryption with that, that's good

mweksler: +1 to the extra layer of encryption
... we can do closer to end to end that way
... I think certs do add value..let us use existing standards to check certs are valued, climb up the ladder, consider cert revocation, etc.

oyiptong: Certs are used for integrity, confidentiality, and authenticity
... the chain helps with authenticity
... for integrity, we use digital signatures (outside of the scope of this proposal)
... 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
... we lose that with a public key

Network tokenization

IJ: My understanding is that based on experimentation, you'll come back at the end of the month

Keyur: I did update this:



"Tokenized Card Payment"

---> https://github.com/w3c/webpayments-methods-tokenization/wiki/Network-Tokens

Next meeting

19 Sep

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2017/09/05 16:37:45 $