Tokenization Task Force -- 22 Aug 2017

Tokenization Task Force

IJ: (Recap of status)

Manash: Should we look at tokenization in the browser?

Q. Are browser vendors interested in implementing other payment methods than basic card?

Q. If we have the ability to encrypt, could browser encrypt otherwise unencrypted info?

Also: Encrypting might be generally useful across payment methods

Encrypted Card

Questions:

Are there gateways interested in consuming these encrypted blobs?

Encrypt PAN alone or the entire Basic Card data in the PR API response?

In theory a merchant could refer to multiple gateways, but, for simplicity, should we focus on one initially?

Should merchant pass a gateway key or a reference to such a key (to be fetched by the payment app that does the encryption)? We can leverage existing certificate mechanisms to increase security.

IJ: Does this sound interesting?

Manash: Are you envisioning a common encryption standard?

https://www.w3.org/TR/WebCryptoAPI/

IJ: I don't know whether Web Crypto features into this

oyiptong: We have not yet discussed how the encryption works
... I don't know whether web crypto is relevant here. We also talked to browser vendors about implementing this directly

IJ: I meant web crypto for web-based payment apps

Manash: Suppose that browser has stored card, and cvv is used for auth
... in the user experience you have in mind, will the browser store encrypted card, and pass on to merchant. Then the merchant passes the card data to the gateway directly, or will the merchant need to decrypt.

oyiptong: I think encrypted blob is passed on directly to gatewy

Mansh: And gateway decrypts.

oyiptong: Yes

Manash: Browser vendors could also convert card information to tokens

IJ: Yes; that sounds like a different payment method
... Any other ideas / interest in encrypted card method?

<oyiptong> +1

<scribe> ACTION: Olivier to write down an encrypted card proposal [recorded in http://www.w3.org/2017/08/22-wpwg-minutes.html#action01]

<trackbot> 'Olivier' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., omaas, oyiptong).

Network tokens next steps

IJ: How do we proceed? Should we base this on gateway (which has concepts like one-time and expiry) or existing network token spec?

Manash: Agreed that one-time is relevant here (both input and output data)
... with the prototype that we are building for Money 20/20 we are hoping to implement in the response format; we'd like to align with our discussions here.
...summary: yes, we would like to work with our colleagues at Amex so that merchant use cases are documented
... and our prototype will give us some clarity on the spec

IJ: What time frame do you have in mind?

Manash: End of September

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

scribe: we would like to experiment, then come back with proposal

Next meeting

<oyiptong> wait until the week after?

<alyver> +1 to Sept 5

(5 Sep?)

RESOLUTION: 5 Sep next meeting

https://github.com/w3c/webpayments-methods-tokenization/issues

Tokenization Task Force

22 Aug 2017

Attendees

Contents