A New Protocol’s Uncertain Promise

Can the new version of 3D Secure fix the faults of the old one and stem the steady rise of e-commerce fraud? The answer is a big maybe—and here’s why.

It has been nearly two decades since the card-network brands introduced 3-Domain Secure 1.0 in an attempt to offer a security enhancement for the booming e-commerce market. Seventeen years later, fewer than 10% of bank card transactions use it.

Making the rounds (for industry input) now is EMVCo’s specification for 3DS version 2.0. This new version addresses a bigger problem with fraud by accommodating a broader set of authentication tools.

But EMVCo’s infrastructure approach—channeling the new security-?data flows through the big card brands and issuers—could be making the same mistake the initial version did. What the prospects for 3DS 2.0 turn out to be could be decisive for the nation’s escalating struggles with financial security.

Online fraud—like e-commerce itself—continues to grow rapidly. Some apologists suggest that the increase is simply driven by market growth. They claim the country’s conversion to EMV chip cards at the physical point of sale might not be driving fraud over to the card-not-present channel as much as many feared. But most observers remain gravely worried about the security of Internet transacting.

In that light, this new version of 3DS illuminates the debate about whether the card brands’ effort is the nation’s best shot at this problem, versus rival efforts aimed at a more open solution.

Limited Second-Guessing

In a nutshell, the 3DS 2.0.1 March 2017 specification (Version 2.0 was first released last October) establishes a new set of rails for data flows prior to an authorization request being made by an online merchant for a purchase. It supports browser-based and mobile app-based transactions, including mobile and digital-wallet payments.

The data involve the account holder’s identifying characteristics (such as a mobile device ID or number), session data (including IP addresses), and other information that gets sent to issuers for their assessment of the suitability of the authentication.

For some portions of these transactions, issuers that opt in for this service can reject the transaction, and in some configurations indicate to the merchant a pending decline for a secondary authentication, or accommodate a merchant’s request for step-up authentication for transactions that appear risky.

Merchants can still direct authorization requests in the wild through the networks, but issuers can make their own decisions on what portions of those to approve or decline. And issuers absorb some amount of the risk and merchants get some basis-point discounts.

What’s transparently appealing about the 3DS 2.0 approach is that it offers a broader approach to authentication processes and tools than simply an often embedded second log-in as exists today with 3DS version 1.0. Such processes include the potential for active issuer involvement in the authentication, and replace static passwords with tokens, biometrics, and potentially other technologies to ensure account-holder verification.

The specification is flexible and adaptable, fosters global interoperability (EMVCo’s primary emphasis) and compliance with local regulations, and utilizes modern technology components to accomplish its functions.

For example, based on a Mastercard operations bulletin from a year ago (“Announcing Mastercard Identity Check Authentication Program,” March 31, 2016), a number of different authentication options can be accommodated as inputs to the 3DS 2.0 flows to support this decision-making.

And, acknowledging the reality that many issuers will have had no meaningful experience with online authentication, Mastercard proposed limiting second-guessing by issuers of Internet merchants to no more than 5% of the transaction streams in the early going. No doubt, some online, risk-adept issuers can help make e-commerce transacting safer over time. But most issuers don’t have the 15 to 20 years of experience online retailers have amassed.

Fee Fears

Critics of 3DS 2.0 are worried about two things: the competence of issuers in augmented authentication until they gain the necessary experience, and the potential that authorization decline rates in the wild could increase as issuers prefer the new rails.

But a bigger concern is the proposed infrastructure. It’s complex, it’s new, and it’s likely to cost users (merchants and third-party facilitators) more—even if it works.

The protocol design supports server operations for three domains (of course) and requires both merchants and issuers to update internal systems to support the protocol.

The specification contemplates the operation (in the acquirer domain) of a 3DS server communicating with a 3DS client on the cardholder device—as supported by the merchant checkout, and directed by licensed software providers known as merchant plug-ins (MPIs).

This acquirer configuration communicates in real-time with a directory server (the interoperability domain), which authenticates and validates the links and messages between the 3DS server and a third component—an access server (the issuer domain). The directory server also defines specific (network) “programme” rules, such as time-out values, and updates onboarding and maintenance configurations

The access server is controlled by the issuer, setting rules for which card numbers and consumer devices are eligible for 3DS authentication, authenticating the cardholder for specific transactions, and confirming account information for a 3DS requestor-initiated transaction.

The issuer response travels back to the merchant or other requestor. Or the issuer could mount a “challenge request/response” interaction with the 3DS client, including out-of-band authentication. For frictionless flow, this secondary authentication step is not required.

This setup is similar to what the brands imposed early on in 3DS 1.0, under the assumption that most or all authorization requests would be preceded by a secondary log-in. To facilitate that process, the brands did pre-registration of tens of millions of cards. But when consumers saw a window pop up without warning when they tried to use their cards for a purchase, the transaction abandonment rate soared, and many merchants unhooked from the protocol.

Over the years, the brands turned over the access and directory functions of 3DS 1.0 to companies like CardinalCommerce and Arcot, and abandoned any idea of charging fees or disrupting the process. Instead, Cardinal (now owned by Visa) deployed embellishments such as giving either the issuer or the merchant the option whether to check for the 3DS log-in—many of which were stored for easy and transparent identification via prior setup with embedded smart cookies.

Even with several basis points of reduced interchange for using 3DS 1.0, though, adoption remains minimal.

Now, with version 2.0, merchants and payment facilitators are worried that the brands will be expecting to charge incremental fees for operating or managing the three servers—assuming they do not allow work-arounds and actually prove up to the task of managing these operations as volume scales.

Real Security

For Visa’s part, while it appeared, when the 3DS 2.0 effort was announced in late 2014, that it would not pursue 3DS—especially biometrics—as aggressively as Mastercard (which had built a supporting platform ready to launch in early 2015), apparently it has come around to embrace a broader approach to online authentication. In an announcement in late May, Visa laid out its own upgrade to Verified by Visa, its brand name for 3DS.

On top of that, at this spring’s Secure Technology Alliance (formerly Smart Card Alliance) meeting, Visa’s Ben Dominguez acknowledged that the new 3DS would accommodate and complement independent front-end authentication mechanisms such as FIDO (Fast IDentity Online), an open-industry protocol for e-commerce that embraces a combination of public key infrastructure and a choice of other identifiers/verifiers.

On the one hand, such an accommodation augurs well for security collaboration, something rare in the industry to date. On the other, if you use FIDO, isn’t that sufficient? Why would users need to ride another section of the rail, so to speak, just to ensure the networks and issuers control the transaction flows—unless there is a financial incentive to do so?

Even more intriguing is the overture to FIDO, which comprises more than 250 significant supporting organizations, by EMVCo—with the stated objective of figuring out how FIDO’s PKI-based security combinations might augment EMV at the POS.

As we know, EMV does not encrypt (or protect) card credentials (other than the card-verification value), except to prevent replays of intercepted transactions. As a result, whatever levels of counterfeit fraud the protocol avoids are offset by the exposure of credentials for abuse online and in other fraud-aggrandizing venues. What if real security were available offline?

A Useful Step?

In that context, the EMVCo networks might be tipping their hand. Also circulating in the industry for comment are the latest EMVCo specifications on tokenization. This token specification calls out 3DS 2.0 as an exemplar application in multiple instances: e.g., “Token Assurance,” “Interactive Cardholder Authentication-2 Factor,” “Risk Oriented Non-Interactive Cardholder Authentication.” So it’s reasonable to expect the networks to begin selling everything EMVCo is working on as a package of solutions, ostensibly to buttress adoption of each protocol.

That might not be a bad idea—if the approach actually works. The United Kingdom aggressively implemented chip-and-PIN (in 2004) and 3DS 1.0 (in 2008), and while counterfeit fraud at the physical point of sale came down, all forms of fraud have been growing since 2011. So it’s hard to see how card-network programs are doing anything permanently to reduce fraud as long as they keep real account credentials moving around the system in the clear. (Tokenization is promising in the interim, but it depends mightily on security in the cloud being strong enough).

If 3DS proves to be another business and/or technology stumble for the networks, or can’t productively coexist with alternative ways to secure e-commerce, or can’t scale to the escalating challenges of online fraud, then adopting it would simply amount to throwing more good money after bad.

On the other hand, if the proper incentives for adoption can be provided to justify the added costs and likely new fees, and EMVCo embraces the strong feedback the industry is providing to accommodate more holistic approaches independent of network, 3DS 2.0 might prove to be a useful step in addressing the U.S. crisis in payment risks and fraud.

How 3-D Secure 2.0 Works

3-D Secure 2.0 offers additional fraud protection by analyzing the merchant’s contextual data and then prompting consumers to verify their identity only on high-risk transactions.

1. Cardholder enters his or her Visa account details

2. The merchant’s 3-D Secure service provider packages the message with transaction data and delivers it to the issuer via authentication request

3. The issuer’s 3-D Secure service provider determines the transaction risk and may prompt the cardholder to verify his or her identity with, i.e., a one-time password

Risk Assesment:

HIGH RISK

Requires additional customer verification

Typically less than 5% of transactions

LOW RISK

Requires no additional customer verification

Typically more than 95% of transactions

4. Issuer sends the authentication result to the merchant

5. Merchant submits transaction for authorization with a flag indicating the authentication result