Secure Remote Commerce and the WPWG – some initial thoughts

Introduction

This is my view of the current Secure Remote Commerce (SRC) specification (v0.9) which EMVco have published into the public domain for wide review and comment. I’ll try to explain what SRC is, how it might work, and what it means for the work of the Web Payments Working Group (WPWG) at the World Wide Web Consortium (W3C).
Happily, my main conclusion is that I think the two ecosystems (SRC and Payment Request) play nicely with each other. I think that the open architecture of Payment Request and Payment Handler lend themselves well to supporting one or more SRC payment methods below.

What is Secure Remote Commerce?

At its heart, SRC is an attempt to combine authentication of payer and payee with a desire to have privileged, persistent payment data move only between a cardholder and their issuer. In particular, it attempts to move the traditional card number (Personal Account Number or PAN) away from the merchant.. It can therefore be seen as an evolution of two other EMVco specifications – network tokenisation and 3D secure for authentication.
Figure 1 – SRC takes away card numbers and replaces them with an SRC payload
It should be stated from the outset that as the spec currently stands, it works only with CARD payments – specifically those with a long 16-19 digit Personal Account Number (PAN) which conforms to ISO 7812. It is not currently set up to work for non-card payments which are prevalent in many payments markets.
Although I’ll spend the rest of this blog talking about transaction processing, it’s worth noting that that SRC describes a whole ecosystem including how to register the various participants with the SRC systems, how to enrol cards and cardholders and how to bind identities and credentials together. This makes the specification very big and a little daunting to read.

Roles

Like many specifications, SRC begins by defining a new set of roles and actors. The main new ones we need to talk about are the SRC Initiator (SRCI) and the Digital Card Facilitator (DCF), but to be honest it’s easiest to start by talking about the transaction flow to illustrate what these different roles are doing.

To begin at the beginning

Caveat: I’m assuming everyone is already registered/enrolled in the flow that follows, and this is consumer initiated. The spec says it can support merchant initiated transactions, but then says it doesn’t say how in this version.
Everything starts with the SRC trigger, which the spec says can be a button, a gesture, a voice command, or a funky dance move[1]. Whatever it might be, the trigger can be found in what the specification calls a Digital Shopping Application (DSA), but which you and I would probably call a website or an app, and to keep things simple, I’m going to say here that the shopper pushed a button.
Figure 2 -  Orchestrating the SRC dance



Once an SRC transaction has started, the specification assumes that a bunch of assurance and validation takes place of the cardholder and the cardholder’s device (which might be a phone, a PC, a smart TV, or a car. Maybe’s it’s their fridge.) How this happens isn’t tightly specified, but it seems that it’s the responsibility of the SRC Initiator to make sure that information is collected that allows a Customer Profile Request to be sent to EACH[2] SRC system. Let’s assume for now that the assurance works smoothly (perhaps via Web Authentication API) and that the SRC Initiator is now content that it’s dealing with the real consumer. The Customer Profile Request (step 1 above) is then sent to each SRC system in turn, and those SRC systems each return a Customer Profile Response, which includes all the stuff you need to build a list of digital cards that can be used in this payment, including card art and masked PAN. The various SRC systems go off and do this via the Digital Card Facilitators (step 1a), who are providing the digital representations of the underlying cards. I don’t think that the cardholder has to have any interaction with the DCF – in other words, the SRC Initiator can handle all the user interactions – but the spec also provides for a DCF handover method, so there’s probably another flavour of this flow in which the user jumps into a UX from the DCF later in the flow.
The SRC Initiator then has to present all of these cards in a SRC Candidate List, which enumerates all the SRC enrolled cards associated with the cardholder.[3]
Figure 3 – The SRC candidate list shows the cardholder all their possible SRC payment choices
The cardholder chooses from the list and that then allows the SRC Initiator to send a Checkout Request (step 2) which can provide more information about the specific card that’s been chosen, like associated delivery addresses, billing addresses and lots of risk data. My reading of the SRC spec is that this step might be optional.
It's probably worth highlighting that the order in which different cards will be arranged on the candidate list is based on the most recently used cards, according to the SRC specification, whereas the payment handler API takes the approach that the user can control the ordering. 
Once the consumer is completely ready to buy with a selected card, the SRC Initiator sends a Payload Request (step 3), which the SRC system replies to with a Payload Response (step 3a), which contains dynamic data. It’s this Payload Response that allows the SRC Initiator (and so finally the merchant) to create a traditional authorisation request – how to get from Payload Response to auth request is beyond the scope of the specification so will presumably depend on the implementations of each of the SRC systems in question.
Once the authorisation request has gone off (via the merchant’s gateway/PSP/acquirer) and there has been an authorisation response (like “authorised” or “declined”), the SRC Initiator is supposed to send a Confirmation Request (step 4) to the SRC system to signal the end of the payment transaction, and received a Confirmation Response in return.

Implications for Payment Request and Payment Handler

As I said in the introduction, I think that SRC can work very well with the WPWG’s payment request/payment handler specifications.
Figure 4 – fitting SRC and Payment Request together


The role of SRC Initiator can be played by a payment handler. It could be the handler that some browsers have chosen to implement inside/alongside the browser. It could be a handler implemented as a standalone native handler, or it could be implemented as a web application and supported through the payment handler specification. However, the requirement to complete verification/assurance activities before presenting the candidate list needs some careful thought – being logged into a browser might not be enough to allow the candidate list to be provided, and so instead a third party payment handler capable of supporting SRC and its assurance methods might be required.
The URL-based payment method identifier mechanism would allow each SRC system to declare a payment method, and have a manifest which declared which handlers/Initiators were supported.
The requirement to send a confirmation request from the Initiator to the SRC system looks like it might be difficult against the existing payment request API. The current Payment Request specification allows for a “complete” method to be called, but its result can (at the moment) only be a “success”, “fail” or “unknown”. An extension might be needed to carry the additional information required by the confirmation messages, but the good news is that in version 0.9 of the SRC specification, these confirmation messages are optional, not compulsory.
Beyond the technical aspects of the SRC specification, it is important to note that each SRC Initiator has to be registered with the SRC systems, and that each SRC Initiator has to enrol each Digital Shopping Application that it supports. In practice, in the WPWG world, this probably means that each payment handler will have to have a registration scheme to register each website that it supports. Some handler-like implementations like ApplePay and Pay with Google already require website registration – other handlers wishing to support SRC would have to implement similar.

Other observations

There are a number of inconsistencies in the v0.9 which I expect will be ironed out as the specification matures. But it would be fair to say that accessibility (in the sense of ensuring that there are no barriers that prevent interactions with the SRC flows by people with disabilities) is something that I think needs further work – especially an over-reliance in the specification language on things like buttons and “visual versions” of things like card art.
The EMVco specification is a starting point for implementations from each of its members (Union Pay, JCB, Visa, Mastercard, Diners/Discover and American Express). Until these implementations are available for experimentation, it’s difficult to know for sure how easy the integration of payment request and payment handler into this ecosystem will be. There may also be implementations of SRC systems from organisations other than EMVco members – just as there have been of other EMVco specifications, notably including Tokenisation. However, the profusion of SRC systems will require careful management, and the specification is currently silent on how an SRC Initiator might try to identify all possible participants. I imagine some kind of directory will be required eventually.
The SRC specification describes an entire ecosystem including registration, enrolment, configuration management, identity binding and orchestration, alongside payment acceptance, so there are big chunks of it that aren’t directly relevant to the work of WPWG but which may well be interesting to WPWG members, especially if they might plan to implement their own payment handler.

Conclusions

It’s still very early in the lifecycle of this specification, and EMVco are to be applauded in making it available for review before it reaches v1.0. I’ve necessarily only looked at a handful of possible implementations and have not covered in this blog big chunks of the ecosystem, but my initial analysis is that the worlds of SRC and web payments (payment request and payment handler) can work well together.
Payment Request has been designed from the outset to be agnostic of the underlying payment method and the extensibility that comes from URL-based payment method identifiers and payment handlers lends itself well to adapting to SRC. More than that, I think SRC can exist alongside existing card payments (like Basic Card) and non-card payments (like credit transfer) which means consumers should be able to make choices about what payment methods they use but still have a consistent experience.
The public consultation on SRC v0.9 is open until Monday 3rd December and I’d urge anyone interested to respond if they can. Equally, if anyone has feedback on my initial analysis, or has thoughts about implementations, the WPWG would love to hear from you.

**UPDATE 1** 
Fixed spelling and capitalisation errors, and added a comment about the ordering of payment instruments in the candidate list


[1] The spec is actually silent on the subject of interpretative dance. But imagine how cool it would be if you could make a payment simply by busting out a moonwalk.
[2] Yes, you did read this correctly. It looks like it’s the responsibility of each SRC Initiator to contact every possible SRC system each time a shopping transaction happens.
[3] Where this gets exciting is when a cardholder enrols with multiple SRC Initiators and with multiple DCFs, but let’s assume it all just works for now

Comments

  1. Comments are open for corrections, brickbats and argument

    ReplyDelete
    Replies
    1. Hello everyone on this site seeing this post, I'm here to talk about how I got my loan without too much stress. I got a loan of $50,000 from Global Loan Access at the rate of 2%, if you have been seeking to get a loan and you finding it difficult Global Loan Access is your solution. Contact them today to get your loan at (globalloanaccess@gmail.com)

      Delete
  2. Can you draw another picture to show how SRC relates to W3C because I want to steal it and include it in a blog post please.

    ReplyDelete
  3. Hello everyone on this site seeing this post, I'm here to talk about how I got my loan without too much stress. I got a loan of $50,000 from Global Loan Access at the rate of 2%, if you have been seeking to get a loan and you finding it difficult Global Loan Access is your solution. Contact them today to get your loan at (globalloanaccess@gmail.com)

    ReplyDelete
  4. loan offer in 48 hours.
    Hi Do you have financial problems? And those who have trouble getting capital loans from local banks and other financial institutions. Please refer to this E-mail address: maurogiovanni00@gmail.com

    whatsapp: +55 11 97 6315 893

    ReplyDelete
  5. loan offer in 48 hours.
    Hi Do you have financial problems? And those who have trouble getting capital loans from local banks and other financial institutions. Please refer to this E-mail address: maurogiovanni00@gmail.com

    whatsapp: +55 11 97 6315 893

    ReplyDelete
  6. Are you in financial crisis, looking for money to start your own business or to pay your bills?
    I got mine from Mike Fisher. My blank ATM card can withdraw $2,000 daily. I got it from Her last week and now I have $14,000 for free. The blank ATM withdraws money from any ATM machines and there is no name on it, it is not traceable and now i have money for business and enough money for me and my family to live on .

    GET YOUR BLANK ATM CREDIT CARD AT AFFORDABLE PRICE
    *They sell this cards to all customers and interested buyers worldwide,the card has a daily withdrawal limit of $2000 to $5000 and up to $50,000 spending limit in stores and unlimited on POS.*

    *email: blankatm002@gmail.com
    *you can also call or whatsapp us Contact us today for more enlightenment
    +1(301) 329-5298

    ReplyDelete

  7. This is such an informative blog, your opinion, observations and ideas are amazing and to the point. I would love to read more content like this, and I want to give one advice to you are looking for a builders in bhopal then Sagar Green Hills is the ideal township for you.

    ReplyDelete
  8. A lot of us are still unaware of the recent development of the Blank ATM card.. An ATM card that can change your financial status within few days. With this Blank ATM card, you can withdraw between $1000-$10,000 daily from any ATM machine in the world. There is no risk of getting caught by any form of security if you followed the instructions properly. The Blank ATM card is also sophisticated due to the fact that the card has its own security making your transaction very safe and untraceable. For more info contact us with the below email address.
       
     E-mail: unitedblankatmhackcard@gmail.com

    ReplyDelete
  9. Thank you for the nice article here. Really nice and keep update to explore more health and safety tips and ideas. Nebosh Courses In Chennai Nebosh IGC Course in Chennai International Safety Courses


    ReplyDelete
  10. BEST WAY TO HAVE GOOD AMOUNT TO START A GOOD BUSINESS OR TO START LIVING A GOOD LIFE.....

    Hack and take money directly from any ATM Machine Vault with the use of ATM Programmed Card which runs in automatic mode. email  (  shublankatm@yahoo.com ) or call   +886981036185   for how to get it and its cost .

    .......... EXPLANATION OF HOW THESE CARD WORKS..........

    You just slot in these card into any ATM Machine and it will automatically bring up a MENU of 1st VAULT $1,000, 2nd VAULT $5,000, RE-PROGRAMMED, EXIT, CANCEL. Just click on either of the VAULTS, and it will take you to another SUB-MENU of ALL, OTHERS, EXIT, CANCEL. Just click on others and type in the amount you wish to withdraw from the ATM and you have it cashed instantly... Done.

    ***NOTE: DON'T EVER MAKE THE MISTAKE OF CLICKING THE "ALL" OPTION. BECAUSE IT WILL TAKE OUT ALL THE AMOUNT OF THE SELECTED VAULT. To get the card call OR Whats-app +886981036185 or email (  shublankatm@yahoo.com   )

    ReplyDelete
  11. >>Hello EveryOne This The British hacker You Know and As you Know
    I Was Blocked on my Old Account and decided To Apply for a new one so Kindly hit Me Up For a Long Term business
    As I Got valid Card and Also Does transfer of payPal Sauce,Wu,moneyGram ,This time Around with leGit CusTomers Only and If You Got BTC Ready
    Hit me Up for a long term Business....This Are My LeGit and Valid Cards With prices..
    >>>>
    >>>>I SELL CC $15 WITH GOOD AND HIGH BALANCE OF 5000$
    >>>>
    >>>>
    >>>>Usa CC With Bin 10$
    >>>>
    >>>>Usa CC Without Bin 8$
    >>>>
    >>>>Usa CC Full Info 20$
    >>>>
    >>>>
    >>>>Uk CC With Bin 10$
    >>>>
    >>>>Uk CC Without Bin 8$
    >>>>
    >>>>Uk CC Full Info 20$
    >>>>
    >>>>
    >>>>Canada CC With Bin 10$
    >>>>
    >>>>Canada CC Without 8$
    >>>>
    >>>>Canada CC Full Info 20$
    >>>>
    >>>>
    >>>>Usa Cvv With Bin 20$
    >>>>
    >>>>Usa Cvv Without Bin 15$
    >>>>
    >>>>Usa Cvv Full Info 35$
    >>>>
    >>>>
    >>>>Uk Cvv With Bin 25$
    >>>>
    >>>>Uk Cvv Without Bin 20$
    >>>>
    >>>>Uk Cvv Full Info 40$
    >>>>
    >>>>
    >>>>Canada Cvv With Bin 18$
    >>>>
    >>>>Canada Cvv Without 15$
    >>>>
    >>>>Canada Cvv Full Info 30$
    >>>>
    >>>>
    >>>>I Do Good Transfer To All Countries ( Western Union Transfer)
    >>>>
    >>>>25$ Btc For 250$
    >>>>
    >>>>30$ Btc For 300$
    >>>>
    >>>>35$ Btc For 350$
    >>>>
    >>>>40$ Btc For 400$
    >>>>
    >>>>45$ Btc For 450$
    >>>>
    >>>>50$ Btc For 500$
    >>>>
    >>>>
    >>>>I Do Good Transfer To All Countries ( PayPal Transfer)
    >>>>
    >>>>
    >>>>20$ Btc For 200$
    >>>>
    >>>>25$ Btc For 250$
    >>>>
    >>>>30$ Btc For 300$
    >>>>
    >>>>35$ Btc For 350$
    >>>>
    >>>>40$ Btc For 400$
    >>>>
    >>>>45$ Btc For 450$
    >>>>
    >>>>50$ Btc For 500$
    >>>>
    >>>>
    >>>>
    >>>>I Do Good Transfer To All Countries ( Cash App Transfer )
    >>>>
    >>>>
    >>>>
    >>>>
    >>>>20$ Btc For 200$
    >>>>
    >>>>25$ Btc For 250$
    >>>>
    >>>>30$ Btc For 300$
    >>>>
    >>>>35$ Btc For 350$
    >>>>
    >>>>40$ Btc For 400$
    >>>>
    >>>>45$ Btc For 450$
    >>>>
    >>>>50$ Btc For 500$
    >>>>
    >>>>
    >>>>
    >>>>Contact Me

    xploitt.com@gmail.com

    Safe And Good Transfer And Good Cvv Fullz Track1&2 Bank Login Profiles And Many More...

    ReplyDelete
  12. I want to testify about United blank atm cards which can withdraw money from any atm machines around the world. I was very poor before and have no job. I saw so many testimony about how United hackers send them the atm blank card and use it to collect money in any atm machine and become rich. I email them also and they sent me the blank atm card. I have use it to get 90,000 dollars. withdraw the maximum of 5,000 USD daily. United hackers  is giving out the card just to help the poor. Hack and take money directly from any atm machine vault with the use of atm programmed card which runs in automatic mode.

    Email: unitedblankatmhackcard@gmail.com  

    ReplyDelete

Post a Comment