Tokenization Task Force

TPAC agenda planning and Tokenized Card

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.

Encrypted Card

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

Dynamic Basic Card

... also interested in relationship to dynamic CVV etc.
... what if the browser calls a server that provides a dynamic CVV
... then the browser doesn't have to ask the user to enter a CVV code

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

Next Meeting

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