NEW FRONTIERS IN SECURE COMMERCE...NEW FRONTIERS IN SECURE COMMERCE EMV® 3-D SECURE EMV® is a registered trademark in the U.S. and other countries and an unregistered trademark elsewhere

NEW FRONTIERS IN

SECURE COMMERCE

EMV® 3-D SECUREEMV® is a registered trademark in the U.S. and other countries and an unregistered trademark elsewhere. The EMV trademark is owned by EMVCo, LLC.

SAM PFANSTIEL, MODERATOR

CONTROLSCAN

KEVIN CROCKETT

CARDINALCOMMERCE

STEVE KLEBE

GOOGLE

TABITHA ODOM

EMVCo


CONTROLSCAN

KEVIN CROCKETT

CARDINALCOMMERCE

STEVE KLEBE

GOOGLE

TABITHA ODOM

EMVCo

EMV® 3-D Secure

Tabitha Odom – Chair of the 3DS Working Group, EMVCo

17 July 2019

Copyright ©2017 EMVCo 55Copyright ©2019 EMVCo – Unauthorised reproduction is prohibited

Role of EMVCo in EMV® 3-D Secure

What EMVCo Does What EMVCo Does NOT Do

• Develop specifications that support secure e-commerce transactions in a globally interoperable manner.

• Enhance specifications based on industry feedback.

• Maintain vendor / service provider relationships.

• Collaborate with other industry bodies.

• Implement and manage a testing and approval programme.

• Deliver royalty-free specification ‘tool box’ to be adapted by global, regional and domestic payment systems to meet regional market variations.

• Develop EMV 3-D Secure solutions / products.

• Implement EMV 3-D Secure solutions or services.

• Maintain ecosystem implementation and governance requirements.

• Mandate, incentivise or shape policies for EMV 3-D Secure solutions.

• Manage 3DS version 1.0 – Visa will maintain sole ownership and management of this version.

EMV® is a registered trademark in the U.S. and other countries and an unregistered trademark elsewhere. The EMV trademark is owned by EMVCo, LLC.


EMV® 3DS Technology

• Supports app-based purchases on mobile and other consumer devices.

• Enables merchants to integrate authentication into their checkout process for both app and browser-based implementations.

• Specifies the use of multiple options for step-up authentication.

• Adds a non-payment message category.

• Enables merchant-initiated account verification.

• Flexible to accommodate global and local needs.

• Available royalty-free from the EMVCo website.

Specification FeaturesEMVCo maintains the EMV 3DS

Specifications, administers testing

and provides an approval process to support e-commerce

transactions in a globally

interoperable manner.


Key Benefits

Merchants Consumers Issuers

• Supports a consistent approach for cardholder authentication or account verification.

• Applies to multiple platforms and digital channels.

• Minimises checkout abandonment.• Protects merchants from exposure

to fraud-related chargebacks.

• Reduces risk of fraud.• Richer data exchange enables

frictionless authentications.• Supports new devices and

channels.• Encourages cardholders to

make purchases using their preferred medium.

• Enhances online security.• Increases convenience.• Maintains existing consumer

experience.

The exchange of 3DS data between the merchant and a card issuer can increase authorisationapproval rates and reduce the risk of fraud, while optimising the cardholder’s experience.


EMV® 3-D SECURE TRANSACTION FLOWS


ACS

The Access Control Server (ACS) – responsible for authentication of the cardholder

DSDirectory Server (DS) – operated by each participating Payment System

3DS Server

3DS Server – communicates with the merchant environment and the Directory Server (DS) to send and receive authentication messages

SDK3DS SDK running on the consumer device communicates with the 3DS Requestor Environment and the Access Control Server (ACS)

EMV® 3-D Secure Components


The consumer adds the item to their shopping

cart, completes the standard purchase

information and confirms the purchase

The purchase information along with device data and other details are submitted

to the ACS to determine cardholder

authentication

The ACS was able to authenticate the

cardholder via ‘risk-based authentication’ and the cardholder is

authenticated passively

Application Based Example – Frictionless Flow


Acquirer BIN

Acquirer Merchant ID

Cardholder Account Number

DS URL

Message, Extension, Version

Acquirer BIN

Acquirer Merchant ID

Card Expiry Date

Cardholder Account Number

DS URL

Merchant Country Code

Message Category, Extension, Type, Version

Purchase Amount, Currency, Date & Time

Recurring Expiry, Frequency

More than 10 X Data

Browser User-Agent

Browser User-Agent

IP address

Browser Time ZoneJavaScript Enabled

Cardholder Email Address, Home Phone Number, Mobile Phone Number, Work Phone Number

Cardholder Name

SDK App ID, SDK Encrypted Data, Ephemeral Public Key

SDK Reference Number, SDK Transaction ID

3DS Requestor URL, App URL

Browser Accept Headers

Cardholder Account

Information (Account

Age, Change, Password Change, Number of Transactions per Day /

Year, Shipping Name Indicator, Suspicious Activity, Payment

Account Age etc.)

Cardholder Account Identifier, Billing Address

Cardholder Shipping Address

Transaction Type

Account Type

Browser Time Zone

DS Reference Number, Transaction ID

EMV Payment Token Indicator, Payment Token Source

Purchase Date & Time

Recurring Expiry, Frequency

3DS Server Reference Number, Operator ID, Transaction ID, URL

Address Match Indicator

Device Channel, Device Information, Rendering Options

Supported

Message Category, Type

Merchant Name

Merchant Country Code

Merchant Category Code

Merchant Risk Indicator (Delivery Timeframe, Re-order, Pre-order, Gift Card)

3DS Requestor Authentication Information (Method), Challenge Indicator, ID, Initiated Indicator

3DS Requestor Name, Non-payment Indicator, Prior Transaction Authentication information

Instalment Payment Data

Browser Java Enabled, Language, Screen Color Depth, Height, Width

3DS 1.0 Data (Initial Message – VEReq) EMV® 3-D Secure Data (Initial Message – AReq)

Application Based Use Case Example – Challenge/Response Flow

Whitelisting Status, Status Source

ACS Decoupled Confirmation Indicator

3DS Requestor Decoupled Max Time, Decoupled Request Indicator

3DS Requestor Authentication Method Verification Indicator


The consumer adds the item to their shopping

cart, completes the standard purchase

information and confirms the purchase

The purchase information along with device data and other

details are submitted to the ACS to determine

cardholder authentication

The ACS was not able to authenticate the

cardholder via ‘risk-based authentication’. The

cardholder is requested to enter an OTP to

authenticate themselves

Application Based Use Case Example – One Time Passcode (OTP) Flow


The OTP information is sent to the ACS for verification

The ACS was able to verify the cardholder via the OTP

and the cardholder is authenticated

Application Based Use Case Example – OTP Flow: Success


EMV® 3DS V2.2.0


EMV® 3DS 2.2.0 Builds upon the Key Benefits

EMV 3DS

Promotion of Frictionless

Authentication

New Authentication

Channels

Better communication

across all Domains

Better User Experience (UX)

Identification and Verification

(ID&V)

Increase Approval Rates

Reduce Fraud


EMV® 3DS 2.2.0 Additional Features

Promotion of Frictionless

Authentication

Further promotion of frictionless authenticationEnhancements offer options for fewer step-up authentications, while still complying with regulations, such as PSD2 in Europe:• Indication if acquirer Strong Consumer Authentication (SCA) or Transactional Risk

Analysis (TRA) was already performed prior to the authentication message being sent.

• Ability to send data as Information Only to the ACS / Issuer.• Indicators communicating if the cardholder has already “whitelisted” themselves

to a merchant prior to the transaction or wish to whitelist themselves to the merchant during the transaction.

FIDO Authentication, Token, and Secure Remote Commerce (SRC) Data:• Additional information as to how the cardholder logged in to their 3DS Requestor

Account.• Specification has been updated to carry additional FIDO, Token and SRC data

from the merchant to the issuer.


EMV® 3DS v2.2.0 Key Features

User Experience with Whitelisting Checkout (SCA)

NOTE: UI Templates updated for both Native and Browser HTML


EMV® 3DS v2.2.0 Key Features

User Experience after Whitelisting (Frictionless)

Note: ACS still has the final decision as to whether SCA is required for the cardholder transaction


EMV® 3DS 2.2.0 Additional Features

New Authentication

Channels

Support of Mail Order / Telephone Order (MOTO) transactions

• MOTO transactions can now be identified within EMV 3DS 2.2.0• Specification has built in two key features to support MOTO

1. The addition of 3DS Requestor Initiated (3RI) Paymentso A channel that allows the merchant to initiate the authentication request

without the cardholder being in-session.o This channel only supported non-payment transactions within v2.1.0 for account

verification purposes only.o This channel has been expanded to support MOTO and recurring transactions

where authentication may be required but the cardholder is not in-session.2. The addition of a new authentication method: Decoupled Authentication

o A new authentication method which allows cardholder authentication to occur if the cardholder is offline.

o This authentication method can also be used if the cardholder is online via our Browser and App channels.


For more information www.emvco.com

Official specification & supporting material portal

FAQs general & technical

Seminar & meetings details

EMVCo approved products & accredited labs

White papers & best practice guides

or join us on LinkedIn.

Thank you!

http://www.emvco.com/


CONTROLSCAN

KEVIN CROCKETT

CARDINALCOMMERCE

STEVE KLEBE

GOOGLE

TABITHA ODOM

EMVCo

CardinalCommerce3-D Secure done right. Everybody wins.

KEVIN CROCKETT

SR. DIRECTOR, GLOBAL CUSTOMER SERVICES

[email protected]

EMV® 3-D Secure – how it has

changed/how it differs from 3DS 1.0

EMV® is a registered trademark in the U.S. and other countries and an unregistered trademark elsewhere. The EMV trademark is owned by EMVCo, LLC

How has 3-D Secure changed?

Improvements to 3-D Secure

• 3DS was introduced in the early 2000s … updated with the consumer

experience in mind

3DS 1.0

• Friction on every transaction

• Designed for browser-based

transactions

• Limited data used for authentication

EMV 3DS

• Better consumer experience - most

transactions can be authenticated without

consumer impact

• Device agnostic

• More data points available for

authentication for more confident issuer

risk decisions

Why authentication matters.

Cardholders who are declined usually take one of the two paths of least resistance –

both are a unwanted experience for everyone.

When false declines happen, everyone loses.

Select another card

in the wallet

Purchase

elsewhere

EMV 3-D Secure in the U.S. vs. Europe

How to get the most out of 3-D Secure

Authentication first can increase approvals – and sales.We have analyzed selected verticals to share KPIs and stats about the card-not-present

market, authorization and fraud rates, and the impact of authentication using Cardinal.

Industry Authorization

Lift1

Removed Fraud1

Luxury Goods 5% 30 bps

Clothing &

Footwear

4.5% 13 bps

Sporting Goods 4.5% 121 bps

Computer &

Software

7% 18 bps

Jewelry 2% 2 bps

1 Source: Cardinal and Visa global data. Statistics are drawn from the latest available data covering the period Oct 2017 to Sept 2018.

EMV® 3-D Secure helps improve the ecosystem as a whole.

• Merchants & issuers collaborate to deliver mutual benefits

• Rich data sets deliver better results: authorization lift + decreased

fraud

• Authentication first – improves authentication process as a whole

• A better shopper experience – fewer false declines with near-zero

friction

Everybody wins.

• Merchants sell

• Shoppers buy

• Issuers collect funds

• A happy shopping experience for all


CONTROLSCAN

KEVIN CROCKETT

CARDINALCOMMERCE

STEVE KLEBE

GOOGLE

TABITHA ODOM

EMVCo

GOOGLE PAY™ & EMV® 3DS 2.0/SCA

STEVE KLEBE, GOOGLE PAY™ BD

Proprietary + Confidential

The Google Pay™ API will help merchants meet SCA compliance on Android (app and web) with a seamless UX

Device-bound payment credentials*

Device biometrics

● One-time identification & verification flow to bind payment credentials to a device

● Google Pay™ returns an authenticated payload

● User performs 2-factor authentication with Google Pay (using biometric or device unlock) to complete a transaction with a device-bound payment credential

Android native app & mobile web Desktop (or when device binding unavailable)

Step up via PSP

● Merchants perform necessary step-ups via their own or their PSP’s SCA solution (3DS, etc)

● Applicable primarily to desktop web & non-Android mobile web

*All Google Pay credentials (device PAN or card) can be bound to a device; more details on further slides


Transaction with any device-bound

credential

Google Pay™ 2FA, no step-up

Streamlined checkout with Google Pay™ device authentication

* Credential binding in GPay app = DPAN device token | ** Credential binding in GPay online buyflow = Path 2 for cards (FPANs)

Natively handled in Google Pay™ buyflow


For non-device bound credentials, merchants will run EMV® 3DS 2.0 as they do with other cards

EMV ® 3DS 2.0 performed by the merchant using the Google Pay™ API

response in conjunction with their in-house or PSP-provided 3DS2 solution

**In the future, GPay will authenticate desktop transactions natively, using a secondary mobile device bound to a user’s Google Pay Account

*Illustrative UX


● The Google Pay™ API can enable merchants to be SCA compliant while providing a frictionless flow

○ Merchants and PSP’s can integrate today → SCA compliance features will automatically go into effect

○ Existing Google Pay™ merchants must make a minor update to their integration

○ Existing PSP partners do not need to update their integration

● For Device Bound credential every Google Pay™ transaction will go through 2FA using device authentication.

● In scenarios where a payment credential is not bound to an Android device (e.g., desktop transactions), merchants

should comply through their own in-house and/or their PSP’s SCA solution

Executive summary


CONTROLSCAN

KEVIN CROCKETT

CARDINALCOMMERCE

STEVE KLEBE

GOOGLE

TABITHA ODOM

EMVCo

PCI 3DS Core 1.0 and

PCI 3DS SDK 1.0

Security Standards

Relationship between EMVCo and PCI SSC

• EMVCo (owned equally by card brands) created, owns, and manages the 3-D Secure protocol and implementation specifications:

– EMV® 3-D Secure Protocol and Core Functions Specification 2.2.0

– EMV® 3-D Secure SDK Specification 2.2.0

• PCI SSC (founded and governed by the card brands) maintains the security standards, assessor program related to the security standard

– “PCI 3DS Security Requirements and Assessment Procedures forEMV® 3-D Secure Core Components: ACS, DS, and 3DS Server”(henceforth “PCI 3DS Core Security Standard”)

– “Security Requirements and Assessment Procedures forEMV® 3-D Secure SDK version 1.0”(henceforth “PCI 3DS SDK Security Standard”)

TerminologyTerm Definition / Usage (see PCI Glossary on the PCI SSC website for full definitions)

3DS Messages Messages conveyed between 3DS components (e.g., PReq, PRes, CReq, CRes)

3DS Data Specific data elements defined in 3-D Core Specification (generally any data transmitted in 3DS messages)

3DS Sensitive Data Specific data requiring additional protection (e.g., 3DS Authentication Data, Public Keys, Challenge Data)

3DS Keys Private Keys for ACS and DS key pairs, generated by HSM, protected by P2-6 key management processes

3DS Requestor Initiates authentication request, conduit for 3DS data to consumer. Typically an e-commerce web server.

3DSS 3DS Server – Server in Acquirer Domain collects data elements and validates 3DS Requestor

DS Directory Server – Server in Interoperability Domain that authenticates servers and routes messages

DS-CA Director Server Certificate Authority – Generates key pairs used by DS

ACS Access Control Server – Server in Issuing Domain that authenticates cardholder

3DE 3DS Data Environment – Secure area within which ACS, DS, 3DSS functions performed.

Note: May be equivalent to Cardholder Data Environment (CDE), in which case only Part 2 is completed.

CVM Cardholder Verification Method – E.g., Online PIN, Offline PIN, Challenge-response, Shared Secret, Static

Password, Biometric, One-time Passcode

CDI Consumer Device Information. – E.g., Smartphone, Laptop, Tablet

https://www.pcisecuritystandards.org/pci_security/glossary

EMV® 3-D Secure Process, Domains, and Entities

3DS Client

3DS Requestor

3DS Server

Directory Server

Access Control Server

Issuer

AcquiringIssuing

Interoperability

PCI 3DS Core Security Standards v1.0

• 3DS ROC & 3DS AOC

• Identification/Evaluation of

Evolving Risks

– Requires robust risk-

management practice

• Compensating Controls

– Legitimate technical or

business constraint

• 3DS Assessors

– 3+ years experience QSA or

QSA(P2PE)

– Quality Assurance

– Validation Methods may Vary

(with justification)

PCI 3DS Core to PCI DSS Comparison – Part 1

3DS Part 1 Requirement Other PCI Standards (May be used for Mapping)

P1-1 – Maintain Security Policies for All Personnel PCI DSS 12

P1-2 – Secure Network Connectivity PCI DSS 1, 10, 11

P1-3 – Develop and Maintain Secure Systems PCI DSS 2, 6

P1-4 – Vulnerability Management PCI DSS 5, 6, 11

P1-5 – Manage Access PCI DSS 7, 8

P1-6 – Physical Security PCI DSS 9

P1-7 – Incident Response Preparedness PCI DSS 10, 12

PCI 3DS Core to PCI DSS Comparison – Part 2

3DS Part 2 Requirement Other PCI Standards (for Comparison Only)

P2-1 – Validate Scope All Standards Require Proper Scoping

P2-2 – Security Governance PCI DSS 12

P2-3 – Protect 3DS Systems and Applications PCI DSS 6

P2-4 – Secure Logical Access to 3DS Systems PCI DSS 8

P2-5 – Protect 3DS Data PCI DSS 3, 4, 10

P2-6 – Cryptography and Key Management P2PE Domain 5, 6

P2-7 – Physically Secure 3DS Systems P2PE Domain 5

PCI 3DS SDK Security Standards v1.0

• SDK Security

– SDK Integrity Protection

– Sensitive Information

Protection

– Cryptography

• SDK Vendor Requirements

– Risk and Vulnerability

– Stakeholder Guidance

PCI 3DS SDK and Vendor Security Requirements

SDK Security Requirements Vendor Security Requirements

1 – Mechanisms to Prevent Unauthorized Modification 4 – Manage Risks and Vulnerabilities

2 – Protect Sensitive 3DS SDK Data Elements 5 – Provide Guidance to Stakeholders

3 – Use Cryptography Appropriately & Correctly

Third-Party Service Providers (TPSP)

• Common Examples– Application Hosting

– Networking or Security Managed Service Provider

– Physical Security

– Fraud Analysis / Scoring

• Requirements– Due diligence and written agreement

– Clear definition of responsibilities

– Ongoing verification that responsibilities have been met

• Compliance Assessment– May undergo 3DS assessment and provide 3DS AOC or redacted 3DS ROC

– Validate specific controls for each client entity’s assessment, or provide evidence package

Preparing for 3DS Assessments

• Implement according to PCI 3DS Security Standards (Core and SDK)

• Complete EMVCo functional testing and certification

• Define Scope of 3DE– Network Devices

– Servers, Computing Devices

– Applications

– Virtualization Technology

– Security Services

– Any Connected-To Components or Devices

• Provide Supporting Evidence to 3DS Assessor (3DSA)– ROC

– Scoping

– Network Segmentation

• Entity submits3DS Core ROC / AOC to brands

OR

• Assessor submits3DS SDK ROV / AOV to Brands

• Remediate (if necessary)

Q&A DISCUSSION

@ElecTranAssoc

[email protected]

electran.org

Documents

NEW FRONTIERS IN SECURE COMMERCE...NEW FRONTIERS IN SECURE COMMERCE EMV® 3-D SECURE EMV® is a registered trademark in the U.S. and other countries and an unregistered trademark elsewhere