October 2017 EMVCo published version 1.o of their Secure Remote Commerce Technical Framework. Today I decided to read and appreciate what they are trying to accomplish and then consider how it ties into what I remember and think we need to do moving forward.
Clearly the challenge links back to the now infamous New Yorker Cartoon. 
We have not successfully established a means of assuring the identity of an individual when presenting payment credentials (the PAN, Expiry date, name, billing address and CVV. The first attempt, still not 100% implemented, was the introduction of CVV2, CVC2 or CID a 3 or 4 digit number printed on the back or the front of the payment card.
We then developed something called SET or Secure Electronic Transactions and unfortunately the payment networks were not willing to allow Bill Gates and Microsoft to earn 0.25% of every sale for every transaction secured by SET he proposed to build into Microsoft’s browser. Without easy integration into the consumer browser, the challenges of integrating SET into the merchant web pages and the Issuer authorization systems caused this effort to fail the death of some many other noble but complicated attempts to create a means of digital authentication.
Next came 3D-Secure, a patented solution Visa developed. It offered what was considered a reasonable solution to Cardholder authentication. Unfortunately, given the state of HTML and the voracious use of pop-ups, the incremental friction, led to abandon shopping carts and consumer confusion. Another aborted attempt at Internet fraud mitigation.
Yet 3D-Secure was not a total failure. Many tried to enhance it, exploit it and avail themselves of the shift of liability back to the Issuer. Encouraging consumer engagement and adoption was futile in some markets mandated and cumbersome in others.
Now let’s consider what EMVCo is attempting to do with their Secure Remote Commerce Technical Framework. As I started to read, I ran into this:
“As remote commerce becomes increasingly targeted and susceptible to compromise, it is important to establish common specifications that protect and serve Consumers and merchants.”
Clearly the authors do not have institutional memory and cannot remember the various attempts alumni of these same organizations spent time on and encouraged many to invest in their implementing. Clearly this lack of historic context will leave some pondering the purpose of this paper.
I then read this sentence and reflect back on a recent hearing on “Social Security Numbers Loss and Theft Prevention” in front of The House Ways and Means Subcommittee on Social Security
“Over time the Consumer has been trained to enter Payment Data and related checkout data anywhere, making it easy for bad actors to compromise data and then attempt fraud.”
Once again, I stand troubled by how the Payment Data clearly printed on the face of the card and especially the PAN, 11-19 digits, designed to simply be an identifier, was converted into an authenticator. Like the social security number, the drivers license number, the passport number and your library card number, the PAN and other “Payment Data” was never designed to be an authenticator. It was meant to be data a merchant could freely record.
The secure features of the card
now the EMV cryptographic techniques otherwise referred to as the Application Request Cryptogram “ARQC” 
were meant to offer the “What You Have” factor in a multi-factor authentication scheme.
As I began to appreciate the scope of this document, the term “Consumer Device” becomes critical. I began to wonder if a PC is a consumer device or if a consumer device is only something like a mobile phone, watch or other like appliance. Fortunately, later in the document, the definition clears up any confusion created by the earlier use of this term.. This said, I then wonder about the difference between what they define as Cardholder Authentication and Consumer Verification?
After reading through all the definitions, I ponder why the authors had to change terminology? Why could they not embrace known and recognized nomenclature. Do we need a new vocabulary?
I wondered:
If this is another attempt to create a revenue stream for the payment networks?
Or, is this the effort of a “closed standards” body to reduce the potential value of the W3C WebPayments activity?
In search of an answer to this last question, I found this discrete comment inside the SRC FAQ.
9. Are any other industry bodies working in this area?
EMV SRC is focused on providing consistency and security for card-based payments within remote payment environments.
EMVCo aims to work closely with industry participants such as W3C to capitalise on opportunities for alignment where appropriate.
Having read bits and pieces of this and the WebPayments efforts one does wonder what is EMVCo trying to do. We shall see?