W3C

Tokenization Task Force

22 Aug 2017

Agenda

See also: IRC log

Attendees

Present
Ian, oyiptong, Simon, alyver, manash, Ken
Regrets
Roy
Chair
Ian
Scribe
Ian

Contents


Tokenization Task Force

Agenda

Wiki updated: https://github.com/w3c/webpayments-methods-tokenization/wiki

https://github.com/w3c/webpayments-methods-tokenization/wiki#encrypted-card-payment-method

https://github.com/w3c/webpayments-methods-tokenization/wiki#encrypted-card-payment-method

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

Summary of Action Items

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

Summary of Resolutions

  1. 5 Sep next meeting
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2017/08/22 16:11:32 $