Re: [w3c/3ds] Value proposition (#4)

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](https://github.com/w3c/3ds/files/1867054/2016.04.12.Verizon.2016.Data.Security.Report.Summary.docx)
[2017 02 PCI Multi-Factor-Authentication-Guidance-v1.pdf](https://github.com/w3c/3ds/files/1867055/2017.02.PCI.Multi-Factor-Authentication-Guidance-v1.pdf)
[2017 06 NIST.SP.800-63-3.pdf](https://github.com/w3c/3ds/files/1867056/2017.06.NIST.SP.800-63-3.pdf)
[2017 Verizon Data Security Rpt.pdf](https://github.com/w3c/3ds/files/1867059/2017.Verizon.Data.Security.Rpt.pdf)
[2017 StrongAuthenticationinCyberspace_8KeyPrinciplesforPolicymakers ChertoffGroup.pdf](https://github.com/w3c/3ds/files/1867060/2017.StrongAuthenticationinCyberspace_8KeyPrinciplesforPolicymakers.ChertoffGroup.pdf)



-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/3ds/issues/4#issuecomment-377848835