Tokenization Task Force

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

Who would implement the tokenization payment method?

IJ: Who?

mweksler: The network tokenization spec is the longterm direction of the industry
... the move is towards one-time transactions with strong auth and away from card on file
... so the network tokenization spec aligns with that long term vision
... but during a transition period, there is a question of how to onboard merchants
... gateway tokenization spec is a transition piece while there is still card on file
... slightly more secure than raw PAN
... we should also talk with more gateways

alyver: I think any non-consumer brands will not expect to appear in payment apps
... browsers could implement the tokenization spec

oyiptong: I think that browsers could play a role here.

IJ: Maybe we recast this as "network tokens from lots of payments apps" and "transition basic card+" with more browser role

oyiptong: I was wondering what's going on in the payment app realm. I something like gateway tokenization lowers cost of payment app development.

IJ: Perhaps we could think about browsers taking basic card data from payment apps and encryption

mweksler: There are different ways merchants will use data on the back end
... with gateway tokens they need to have a relationship with gateways
... so in that sense, it's a bit more than "basic card+"
... due to these relationshiops

IJ: Can we talk about different use cases: (1) easier comms with gateways (2) pci scope (e.g., "just encryption")

mweksler: Would be good if PAN can be encrypted in way only gateway can decrypt
... freeing merchant of PCI scope

oyiptong: My thought was originally more of Basic Card+
... benefit is activation cost is much lower

IJ: I am hearing three things:

1) Browser encryption of PAN

2) Gateway tokens (we don't have clamoring yet)

3) Network tokens (makes sense from variety of apps)

alyver: In case of Android pay, merchant passes in key, google encrypts with key, merchant decrypts payload.
... with apple pay, there is a certificate signing dance
... to help with PCI scope, the gateway needs to do the key parts

mweksler: Parties won't want to do one implementation per gateway; need sense that gateways would be interested in supporting this

Framing is: easier for people to vault cards

IJ: Encryption and PCI go together. What are other ways to make it easier to let merchants take up gateway services?

oyiptong: there is technology overhead and registration overhead

IJ: How do we lower integration costs (as a benefit)?

mweksler: If you accept basic card, you have a relationship with a gateway.
... if you do basic card+ you need to provide merchant account information and make a different API call with the response data you get back from PR API

=========

1) PAN encryption using merchant-specific key from gateway

a) Payment app returns basiccard+1

b) Browser returns basiccard+ (this is at least transitional0

2) Longer term vision is network tokens

3) Gateway tokens not part of the discussion

scribe: but we would seek gateway support for basiccard+

oyiptong: I was wondering about this longer term vision for network tokens
... how does network token solve subscription use cases?

manash: There are two forms of network tokens - first is cloud-based, limited data sent to merchant; second is hardware based with more data
... data includes information about 1-time v. recurring

(IJ: Maybe we add a fourth bullet, like "and next layer would involve strong auth signals")

scribe: when 3ds 2.0 is launched, at transition time, the 3DS 2.0 flow would be initiated for the first time, but the same AAV can be used for subsequent transactions.

Q. In encryption case is the entire basic card respond blog encrypted or just the PAN?

Manash: Valid point about payment apps. You don't want to increase the merchant burden.
... the format that is returned should be the same whether encrypted PAN or EMV Token
... each browser would have to create a dynamic PAN and cloud-based crypto and expiry for that token.

mweksler: +1 to making it easy to encrypt basic card data

Any updates?

Manash: We'd like to create an end-to-end experience leveraging some token specs we have
... I am also looking at how 3DS 2.0 functions
... in this ecosystem 3DS is mandatory in some markets
... 3DS 2.0 may include some caching for better user experience
... probably in the next month we will have a high-level flow we can share with the group

IJ: I would like to invite our FIDO colleagues to chat about FIDO + payment request + 3DS 2.0

<mweksler> +1

<scribe> ACTION: ian to reach out to FIDO colleagues to set up a call [recorded in http://www.w3.org/2017/08/08-wpwg-minutes.html#action01]

<trackbot> 'ian' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., IFSF-EFT-WG-Lead, ijacobs, ijmad).

Next steps

IJ: Reframe gateway? Reframe mission statement?

oyiptong: I will take a look; reframing makes sense

<scribe> ACTION: Ian to update the mission statement with the above narrative [recorded in http://www.w3.org/2017/08/08-wpwg-minutes.html#action02]

<trackbot> 'Ian' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., IFSF-EFT-WG-Lead, ijacobs, ijmad).

<scribe> ACTION: oyiptong to review the gateway params spec and reframe it [recorded in http://www.w3.org/2017/08/08-wpwg-minutes.html#action03]

<trackbot> Created ACTION-64 - Review the gateway params spec and reframe it [on Olivier Yiptong - due 2017-08-15].

Next meeting

22 August