Value proposition

[asolove-stripe]

[This is a super rough draft! Comments/revisions/rewrites very welcome.]

The goal of this task force is to create browser standards that allow the authentication of online credit card payments.

• Customers want a convenient way to complete online purchases that they know they can trust.
• Merchants want to comply with new Secure Customer Authentication standards (e.g. in India and the EU), but still want to minimize the friction and conversion rate impact of extra authentication in their checkout flows.
• PSPs want to make their existing products (like UIs to accept and tokenize card numbers) comply with SCA rules, while retaining enough control to still offer distinguishing features or UI innovations.
• Issuers want additional data about transactions to inform their risk models and offer value-added services to their cardholders. (They also wouldn't mind if their name/logo appeared prominently during the payment flow.)
• Browser authors want to offer better web payment options to help web commerce continue to grow. But they act on behalf of users and are therefore wary of sharing personal data or executing third-party code without explicit permission. Browser authors are generally not part of the payments world and are reluctant to take on responsibility for payments-specific data or policies that may change over time.

[glelouarn]

Many thanks Adam for that detailed analysis. Here are a few suggestions to go ahead on that proposal:

• Customers: could we add an indication about the fact a user can be reassured by authenticating during payment at the condition to minimize or eliminate friction (SMS, fingerprint, facial identification…).
• Merchants: when referring new, are you thinking about SCA required by PSD2 in Europe? Because they are asking to reduce friction, merging consent with authentication in a single and simple operation (bio-metrics for instance) is the best user experience merchants are looking for.
• Merchants: discussing with merchant according 3DS 2.0, they are also requesting to understand what are collected data, who they are transmitted to and how they can protect and control their data according local regulations (RGPD in EU).
• Networks: seems interesting for me to add that actor who is the global conductor of authentication and also request name/logo visibility.
• Browser authors: shares merchant problematic on data sharing. Interesting to illustrate the browser as to be considered as the bridge between merchant and user and as a consequence, have to address requirements of both.

[ianbjacobs]

Thank you, @asolove-stripe and @glelouarn.

@asolove-stripe, should the compliance point you make about merchants be moved to payment service providers? I don't know whether the compliance responsibility lies more heavily with the merchant or the PSP (or issuer).

@glelouarn makes an interesting point about GDPR. I have a similar question: is that most relevant to merchants or to PSPs (or both)?

I would support adding a Network entry where the goal is to reduce fraud and foster interoperability among different ecosystem participants.

I will keep thinking about this. Thanks!

[glelouarn]

Concerning GDPR, I think the merchant is the first concerned because he is proprietary of datas and by rebound, constraints go to PSP that is operator.
As a consequence, in my idea compliance concerns both even if merchant is exposed first in term of responsibility opposite to his customer.

[kmealey]

Adam;
Thanks for taking the first shot at this. As I read your draft, I thought it could be helpful to go back and rework the problem statement from the Wiki into the overall value proposition statement. So, let me know what you think?

Thanks again,
Ken

Problem Statement
The accelerated growth of e-commerce, especially through mobile devices, has offered consumers convenient services and payment methods that have led to a significant increase in the number of Card-Not-Present (CNP) transactions. A CNP transaction is a type of payment card transaction made where the card member (CM) does not or cannot physically present the card for a merchant's examination at the time that an order is given and payment effected. Since there is no longer a direct interaction between CM and merchant, the amount of fraudulent activity with CNP transactions has grown almost as fast as the market itself.

According to the Verizon 2016 Data Breach Investigations Report:

• Eighty-nine (89) percent of all attacks involve financial or espionage motivations.
• Sixty-three (63) percent of confirmed data breaches involve using weak, default or stolen passwords.

Why is Strong Authentication Important?
“As the table below demonstrates, it’s hard to find a major cyberattack over the last five years where inadequate authentication – generally a compromised password – was not the vector of attack”. Source: The Chertoff Group, Strong Authentication in Cyberspace, 8 Key Principles for Policymakers, February 2017

[Reference Chertoff Table 1, source: Secure Biometric Authentication: A Fundamental Building Block for Achieving Trusted 2 Cloud Services}

One current method of implementing Strong Authentication is Multi-Factor Authentication (MFA). MFA requires verification from two or more independent credentials such as a password, security token or biometric identification and is currently endorsed by NIST (National Institute of Standards and Technology) and the PCI Security Standards Council. (cite respective reports attached)

EMVCo’s 3-D Secure is a messaging protocol developed to enable users to strongly authenticate themselves with their card issuer when making card-not-present (CNP) e-commerce purchases. It is designed to prevent unauthorized CNP transactions and to protect the payment ecosystem (merchants, acquirers, browsers, card members,) from CNP-related fraud.
There are several reasons a merchant, acquirer or browser may wish to support 3DS 2.x, including (but not limited to):
• To reduce CNP-related fraud.
• To increase transaction approval rates.
• To comply with regional regulatory bodies or central bank mandates (e.g. PSD2 in Europe or by Monetary Authority evolving requirements such as in India, Australia, Korea, Hong Kong etc.).

[Reference Table of Impacted Markets from TPAC 3DS Breakout Session]

However, current ecosystem limitations raise obstacles to adoption:
• Merchants need to integrate custom code and specialized UX elements; this integration can be complex.
• Users may be required to authenticate multiple times, adding friction to checkout.

Thus, the goal of this task force is to create browser standards that allow the strong authentication of online credit card [CNP] payments. Some of the challenges to be balanced are:
• Customers want a convenient way to complete online purchases that they know they can trust.
• Merchants want to comply with new Secure Customer Authentication standards in India and the EU, but still want to minimize the friction and conversion rate impact of extra authentication in their checkout flows.
• PSPs want to make their existing products (like UIs to accept and tokenize card numbers) comply with SCA rules, while retaining enough control to still offer distinguishing features or UI innovations.
• Issuers want additional data about transactions to inform their risk models and offer value-added services to their cardholders. (They also wouldn't mind if their name/logo appeared prominently during the payment flow.)
• Browser authors want to offer better web payment options to help web commerce continue to grow. But they act on behalf of users and are therefore wary of sharing personal data or executing third-party code without explicit permission. Browser authors are generally not part of the payments world and are reluctant to take on responsibility for payments-specific data or policies that may change over time.

2016 04 12 Verizon 2016 Data Security Report Summary .docx
2017 02 PCI Multi-Factor-Authentication-Guidance-v1.pdf
2017 06 NIST.SP.800-63-3.pdf
2017 Verizon Data Security Rpt.pdf
2017 StrongAuthenticationinCyberspace_8KeyPrinciplesforPolicymakers ChertoffGroup.pdf

[ianbjacobs]

Hi all,

Thank you for the suggestions on this thread. I have taken a stab at consolidating the ideas and recent discussions into a description in a new wiki page:
https://github.com/w3c/3ds/wiki/value_prop

I very much welcome feedback,

Ian

[Jimbray4]

Hi Ken and Adam, one other application for authentication is ATM transactions. I am working on a solution that provides authentication for bank applications that provides a password-less authentication for mobile, online, ATM, CNP and person present applications. The solution does utilize a mobile device app to authenticate all of these transactions that would incorporate the bio-metric function. This approach eliminates the cost of hardware tokens. By adding real-time authentication to ATMs reduces the need to upgrade older ATM machines due to lack of EMV, Bluetooth and NFC capability. Big ROI for banks and credit unions.