The Identifier should not be the Authenticator

I was asked to look into the value of the EMV Secure Remote Commerce Specifications.  In the first section they wrote:

“1.1 Background … While security of payments in the physical terminal environment have improved with the introduction of EMV specifications, there have been no such specifications for the remote commerce environment. …”

This statement caused a bit of angst.  It caused me to think of the work to create SET and Visa’s efforts to promote the original version of 3D-Secure.  I was further reminded of how difficult it has been to find the balance between convenience and fraud and how merchants are more worried about abandonment than they are about the cost of fraud. Ultimately, it caused me to wonder about the goal of the EMV 3-D Secure specification.

“To reflect current and future market requirements, the payments industry recognised the need to create a new 3-D Secure specification that would support app-based authentication and integration with digital wallets, as well as traditional browser-based e-commerce transactions. This led to the development and publication of the EMV® 3-D Secure – Protocol and Core Functions Specification. The specification takes into account these new payment channels and supports the delivery of industry leading security, performance and user experience.”

The keywords found in the last sentence “the delivery of industry leading security, performance and user experience” suggest these two specifications are searching to solve the same problem.

According to the Oxford dictionary

Security is

    • “The state of being free from danger or threat.”
    • “Procedures followed or measures taken to ensure the security of a state or organization.”

Authentication is

    • “The process or action of proving or showing something to be true, genuine, or valid.”
    • Computing The process or action of verifying the identity of a user or process.

On this same page, the authors go on to make the following statement

“… there is no common specification to address the functional interactions and transmission of data between the participants.”

This then causes me to wonder about the original ISO 8583 specification, the current ISO 20022 specification, and the subsequent concept of the three-domain model within the 3D-Secure specification.  All three of these specifications define the interaction between the participants while not restricting the method of transmitting the data.  It seems the authors of the SRC specifications have forgotten history.  Or, are they trying to rewrite history.

At this stage, Authentication seems to the most important part of what EMV is attempting to address.  But,  the focus seems to be more about rewriting history that solving the fundamental problem.  We seem to have this desire to take public identifiers and convert them into secrets.

“An industry transition from a dependency on Consumer entry of PAN data can be accomplished by providing an SRC specification that meets the needs of all stakeholders involved.”

These intriguing contradictions beg the question.  Why did the authors of the Secure Remote Commerce specification not reference the good work of those that created the 3D-Secure specification and propose an approach unlike EMV?  They all are part of the same organization!

Is the goal not to address authentication and Security of the payment transactions, be they instore or on the Internet.  I would argue

We allowed the PAN, the payment card identifier, to become a means of authentication

This use of the PAN as both an identifier and an authenticator; reminds me of a hearing of the United States House Committee on Ways and Means May 17th, 2018 hearing on “Securing Americans’ Identities: The Future of the Social Security Number”.

“House Ways and Means Social Security Subcommittee Chairman Sam Johnson (R-TX) announced today that the Subcommittee will hold a hearing entitled “Securing Americans’ Identities: The Future of the Social Security Number.” The hearing will focus on the dangers of the use of the Social Security number (SSN) as both an identifier and authenticator, and examine policy considerations and possible solutions to mitigate the consequences of SSN loss or theft.”

All the witnesses and most of our members of congress accepted and understood the problem.  We allowed a simple government-issued identifier to become a means of authentication, in other words, an authenticator.  Like allowing the social security number and now also the PAN to become part of how we authentic someone’s identity.  We caused these publically available identifiers to become valuable and sensitive PII data.

Cardholder Authentication and Consumer Device Identification

What is clear, as one continues reading the SRC specifications, is the goal is to reduce the frequency of presenting payment credentials on merchant websites.

“Minimising the number of times Consumers enter their Payment Data by enabling consistent identification of the Consumer and/or the Consumer Device”

A very different approach to what the payment schemes do with the EMV based payment process.  The authors of EMV saw the PAN as public data, they architected something designed to assure the uniqueness of the card and the ability to positively verify cardholder.  Card Authentication and Cardholder Verification.

Why not simply think and focus on the same architecture?  Simply change the word “card” to “device” and focus on Device Authentication and Cardholder Verification or as everyone is promoting Multi-Factor Authentication.  We simply need to make sure the thing is genuine and the right individual is using the thing.  The thing is what the cardholder has – The “what you have” factor.  Add a pin/password or better still a biometric to be the second factor the “what you know” or “what you are” factor.

EMV 3D-Secure creates the ability to exploit the “what you have” factor by offering Device fingerprint data to the issuer’s authentication process.

 

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.