See also: IRC log
https://github.com/w3c/webpayments/wiki/FTF-Nov2017
Demo (Manash/Sachin) and report on experience with network tokenization spec.
3DS 2.0, UX, Regulatory overview, Benefits to W3C members
How can 3DS 2.0 scale through PR API
Manash: EMVCo is coming out with 3DS 2.0
...it's a vast improvement...several reasons it's important:
- regulatory
....in some markets 2-factor auth is required
...but the user experience can be klunky
...but potentially 95% of the time step up will not be required (to strong auth)
- 3DS 2.0 does improve the approval rates (for CNP)
in the US 1 in 6 transactions is declined. 3DS 2.0 is supposed to increase acceptance rates
- Liability shift may also be possible in some jurisdictions
...but 3DS 2.0 has costs - scalability, ....
...what we want to focus on TPAC is:
[10:43] <Ian> 1) benefit of 3DS 2.0..and can we create a scalable model on top of PR API that allows merchants to accept 3DS 2.0 without setting up a 3DS 2.0 server
[10:44] <Ian> ...there is a potential scalable solution to make it less burdensome on the merchant
[10:45] <Ian> IJ: what might we get to see about network tokenization payment method?
Manash: At TPAC what we are
hoping to show how you create a scalable format using network
tokens
... we want to move away from Basic Card and from custom
payment methods
... we want merchants to be able to say "I accept network
tokens" and allow any payment app to return a token
... we will have a design and roadmap at TPAC
Ken: +1 to Manash's agenda
https://w3c.github.io/webpayments-methods-tokenization/index.html
https://github.com/w3c/webpayments-methods-tokenization/wiki/Network-Tokens
Manash: The wiki reflects our
more recent understanding.
... Note that 3DS 2.0 is independent of tokenization (can be
used with basic card)
IJ: to ensure this work is understood:
a) What are the delviearbles?
2) Make sure our rechartering includes that in scope
Last edited in august => https://github.com/w3c/webpayments-methods-tokenization/wiki/Network-Tokens
<scribe> ACTION: Ian to update the network token payment method to include the data model in the wiki [recorded in http://www.w3.org/2017/10/03-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: What title should we give that spec? Keep it as "Tokenized Card Payment"?
Manash: Network / Issuer Tokenized Card Payment?
IJ: Let's keep short title and move details to abstract
Manash: In a couple of weeks we
will have more clarity on when we will have a demo with
worldpay
... I would also like to understand how other players in the
ecosystem are planning to work with a tokenization
standard.
IJ: Any news or updates?
Olivier: No updates. I still plan to build a prototype for TPAC
Value proposition for encrypted:
* World where user does not yet have payment app that does tokenization
* World of PCI exposure even when third party using iframe
* Where merchant wants to control routing and therefore ok to get data itself; just wants that data to be opaque
IJ: We should be able to articulate the value proposition and who the interested parties are.
Manash: Where is the card being encrypted?
Olivier: In the user agent (or other payment app)
<oyiptong> https://github.com/w3c/webpayments-methods-tokenization/wiki/encrypted_card
We characterize this as "transitional" payment method prior to broad adoption of network tokens
Manash: interesting!
IJ: Should we turn encrypted card
into a payment method spec?
... let's keep as wiki (dropping part II) and if WG supports
adopting it, give it a new repo
olivier: Background transactions also interesting...how does dynamic cvv work in subscription world?
Manash: You have card data on
file but don't store the CVV...
... there's a call to the server when payment (subscription
transaction) required, so get a dynamic cvv at the transaction
time
Oyiptong: The added security is the ability to deny the transaction before it's made?
Manash: Rather, the data is
dynamic (so more secure)...whether cvv or expiry date
... one question is "who can generate that data?" it's either
banks or networks
IJ: Is this still Basic Card though from the merchant perspectiv?
Manash: Yes
IJ: Do we need a different payment method identifier for social reasons? (e.g., so merchants can say "I did not get basic card back")
Manash: Or maybe there is a user
experience change (e.g., no input for CVV; call a server
instead)
... merchant cannot store the data it receives
... so probably need to signal to back end that some data
cannot be stored
oyiptong: I want to talk to Andre about encrypted card
Things we can do at a call before TPAC:
* Review draft presentations
* Review updated payment method specs
NEXT MEETING: 17 October
<scribe> agenda:
* Check on Olivier outline
* Check on Ian's network tokenization spec edits