See also: IRC log
https://github.com/w3c/webpayments-methods-tokenization/wiki
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
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).
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].
22 August