RE: [Agenda] 27 November Card Payment Security Task Force

Hi Adrian,

Please check my attempt to clarify the matter. I’ve provided replies on some individual questions you’d raised.

Best Regards,
Tomasz

From: Adrian Hope-Bailie <adrian@coil.com>
Sent: 26 November 2019 21:18
To: Ian Jacobs <ij@w3.org>
Cc: Web Payments Working Group <public-payments-wg@w3.org>
Subject: Re: [Agenda] 27 November Card Payment Security Task Force


CAUTION: The message originated from an EXTERNAL SOURCE. Please use caution when opening attachments, clicking links or responding to this email.


Hi Ian, TF members,

Please can you clarify a few questions I have about the wiki:

https://github.com/w3c/src/wiki/UX-Assumptions-and-Requirements#cross-src-enrollment<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_w3c_src_wiki_UX-2DAssumptions-2Dand-2DRequirements-23cross-2Dsrc-2Denrollment&d=DwMFaQ&c=uc5ZRXl8dGLM1RMQwf7xTCjRqXF0jmCF6SP0bDlmMmY&r=gGO7JtsSyntBU-GDdHDB4l3lQwFRpuFyuge3kx2OlvY&m=uXMHsFKaa9MBngdY8bds9lTouudluUPw23YF4KTPgso&s=UchPzUmuQl7b-hfvuYgT5mapDtzEqwyDIMZo4Xgs_Y0&e=>
"Based on 13 November 2020 discussion, we should not assume that all SRC payment handlers will be able to enroll a card in all SRC systems."

What does it mean to "enroll a card in an SRC system"? I thought an example of an SRC System was the VISA network and therefore if my bank issues me a VISA card it is from the VISA SRC System.

TB: To Enroll the card into SRC System means that the card is digitised and eventually tokenised. From now on the surrogate identifier, SRC Digital Card ID ,is used during the checkout to identify the card. The Identifier relates to the token or PAN stored by the SRC System.

TB: As it happens today SRC Systems are maintained by the networks, such as EMVCo members. However, the fact the card is issued does not mean it’s “from the SRC System”. It can be enrolled / digitised into the SRC System. There is several enrolment scenarios, so the card can be enrolled by the consumer via SRCI/DCF or by the Issuer.

Can I "enroll" that card on other SRC systems?
If so, what does it mean to do this?

https://github.com/w3c/src/wiki/UX-Assumptions-and-Requirements#cross-src-display-and-selection<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_w3c_src_wiki_UX-2DAssumptions-2Dand-2DRequirements-23cross-2Dsrc-2Ddisplay-2Dand-2Dselection&d=DwMFaQ&c=uc5ZRXl8dGLM1RMQwf7xTCjRqXF0jmCF6SP0bDlmMmY&r=gGO7JtsSyntBU-GDdHDB4l3lQwFRpuFyuge3kx2OlvY&m=uXMHsFKaa9MBngdY8bds9lTouudluUPw23YF4KTPgso&s=vxAA0gSIuW9aGzBaLRnxQAkaXsvHoH0vK49dls6Mg04&e=>
"Based on 13 November 2020 discussion, we should not assume that all SRC payment handlers will be able to display a card from any SRC system for selection."

What is the limiting factor?

TB: I wouldn’t say it’s limiting factor. It’s the architectural nature of SRC. SRC Systems federate some consumer identity information to allows client, such as SRCI, to pull digital card form participating SRC Systems. Everything over and above is implementation decision and therefore we should not assume SRC PH must be integrated with each SRC System to pull the cards. It can be, but does not have to be.

Do SRC payment handlers need to be "certified" or have some form of relationship (technical/business) with all of the SRC systems they can display a card from?

TB: I’d say yes. However, it is implementation decision how to handle PH as a client of SRC System API.

Is this roughly the same as "supportedNetworks" in basic card?

https://github.com/w3c/src/wiki/UX-Assumptions-and-Requirements#add-card-based-on-pan-entry<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_w3c_src_wiki_UX-2DAssumptions-2Dand-2DRequirements-23add-2Dcard-2Dbased-2Don-2Dpan-2Dentry&d=DwMFaQ&c=uc5ZRXl8dGLM1RMQwf7xTCjRqXF0jmCF6SP0bDlmMmY&r=gGO7JtsSyntBU-GDdHDB4l3lQwFRpuFyuge3kx2OlvY&m=uXMHsFKaa9MBngdY8bds9lTouudluUPw23YF4KTPgso&s=87xgf_-Y1gYM8aDlJyxR9RpBQBAjJwYZhWIplbSQRZ8&e=>
"The user would enter a PAN, leading ultimately to installation of a relevant payment handler capable of enrolling that PAN"

This implies that knowing the SRC system for a card is enough to select an appropriate SRC payment handler that could enroll the card.
This further implies that payment handlers will be published by the SRC systems. (i.e. There will be an SRC payment handler from VISA, from MasterCard etc)
Is this correct?

"[pre-installed] payment handlers can support "add card: functionality."

This contradicts the earlier statement that not all payment handlers can enroll cards from all SRC systems.

TB: PH is simply a client integrated with one or more  SRC Systems. I can assume that given PH can enrol cards into each SRC System it is integrated with. I can see two UX flows/scenarios:

  1.  Consumer enters card credentials into the browser native interface and then the browser delegates enrolment of the provided credentials to capable PH. That may involve some UI specific to PH to finalise the enrolment, e.g. DCF UI.
  2.  Alternatively, consumer must first select PH to enter card credentials in PHs UI. Then PH takes it further.
In my opinion, option 1 allows consistent and uniformed ‘card add’ functionality. From my perspective it’s desired approach.

Some clarifying questions which remain unanswered:
1. Would SRC-System-Published Payment Handlers live alongside DCF-published payment handlers?
2. If so, what flow would lead a user to installing a DFC-published handler?

https://github.com/w3c/src/wiki/UX-Assumptions-and-Requirements#no-payment-handler--wallet-selector<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_w3c_src_wiki_UX-2DAssumptions-2Dand-2DRequirements-23no-2Dpayment-2Dhandler-2D-2Dwallet-2Dselector&d=DwMFaQ&c=uc5ZRXl8dGLM1RMQwf7xTCjRqXF0jmCF6SP0bDlmMmY&r=gGO7JtsSyntBU-GDdHDB4l3lQwFRpuFyuge3kx2OlvY&m=uXMHsFKaa9MBngdY8bds9lTouudluUPw23YF4KTPgso&s=qNaMXBb-dRPUEWoPEdc2zcSMMPghL-KgZ85drjXqLxE&e=>
"Users must be able to select an instrument for payment without an intermediate step of selecting from a set of available payment handlers (wallets)."

It is impossible to provide this experience and provide users with choice.
If a merchant supports multiple payment methods (including SRC) and some of these are specific to a wallet (e.g. PayPal, Google Pay, Apple Pay) then the user MUST be prompted to select a wallet.

TB: I believe the wallet PH should be able to “install” the Payment Instruments in the context of the payment sheet, so the consumer can select the individual PI right form the list without selection of the wallet. When the PI is selected the associated wallet/PH would pick up the event and handle the payment flow. Two additional comments:

  1.  That works only if the wallet/PH can recognise device and/or consumer.
  2.  I don’t see this as required behaviour, but rather available option. I understand some of the wallets may prefer to use it and some may prefer to be selected first.

If the requirement is restated as "without an intermediate step of selecting from a set of available SRC payment handlers" then the answer is for SRC cards to be installed as individual payment handlers and appear in the selection list, branded by SRC system alongside non-SRC wallets.

The question remains, as I have already asked in another thread, what happens in this case but where the user has no SRC payment handler installed?
The user is prompted to choose between "Bob Pay, Other Pay and ???????"
What is the desired user experience here?

TB: In a nutshell EMVCo SRC is a standard that aims to replace inherently insecure PAN-based payments in e-commerce. As the Basic Card is a standard build-in way to pay, at least in Chrome, I’m thinking SRC should replace it and become standard card-based payment instrument for Web Payments. That solves, so called “distribution problem”.

"prompting the user to select one from among multiple wallet options is not an acceptable user experience to bootstrap the ecosystem."

This seems like a bootstrapping/distribution problem for SRC payment handlers not something that the W3C needs to solve.
Any other payment method that wants to bootstrap it's ecosystem will face the same challenges.
The primitives are there to use: URL based payment method identifiers, payment method manifests with default payment handlers that are JIT installed etc.


On Tue, 26 Nov 2019 at 20:58, Ian Jacobs <ij@w3.org<mailto:ij@w3.org>> wrote:
Dear Card Payment Security Task Force,

Agenda for 27 November:

 * I have summarized proposals that I have read to help address SRC UX requirements:
    https://github.com/w3c/src/wiki/UX-Assumptions-and-Requirements#design-ideas<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_w3c_src_wiki_UX-2DAssumptions-2Dand-2DRequirements-23design-2Dideas&d=DwMFaQ&c=uc5ZRXl8dGLM1RMQwf7xTCjRqXF0jmCF6SP0bDlmMmY&r=gGO7JtsSyntBU-GDdHDB4l3lQwFRpuFyuge3kx2OlvY&m=uXMHsFKaa9MBngdY8bds9lTouudluUPw23YF4KTPgso&s=lGR44kvhH3LzTX_QPoa236zSUUrnd__hJGvSC34Jzd4&e=>

I would like to review current ecosystem expectations around those topics, most notably whether
there will be one or more payment handlers capable of speaking with the various SRC systems,
or whether each SRC system will have its own payment handler. In the latter case, we seem to be
able to manage the user experience of displaying and selecting instruments in the sheet, but
solving for “add card” functionality is a challenge.

Also, I am still seeking volunteers to do SRC demos (of the current deployments) for the full WG
at their 12 December call.

Call info:

- Usual call time: 11am-noon ET (4-5pm UTC)
- WebEx: http://www.w3.org/2018/11/cps.ics<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.w3.org_2018_11_cps.ics&d=DwMFaQ&c=uc5ZRXl8dGLM1RMQwf7xTCjRqXF0jmCF6SP0bDlmMmY&r=gGO7JtsSyntBU-GDdHDB4l3lQwFRpuFyuge3kx2OlvY&m=uXMHsFKaa9MBngdY8bds9lTouudluUPw23YF4KTPgso&s=ukRuS97AoXwmRVEu12dfVQHoZEy1X2w_Q2BNZfOXuhU&e=>
- IRC: irc.w3.org<https://urldefense.proofpoint.com/v2/url?u=http-3A__irc.w3.org&d=DwMFaQ&c=uc5ZRXl8dGLM1RMQwf7xTCjRqXF0jmCF6SP0bDlmMmY&r=gGO7JtsSyntBU-GDdHDB4l3lQwFRpuFyuge3kx2OlvY&m=uXMHsFKaa9MBngdY8bds9lTouudluUPw23YF4KTPgso&s=uFjVu_iv19MvSDAkwZ2gjuYLfP-Sx45hfluVz7cfQfw&e=> in the channel #wpwg

Thank you,

Ian

--
Ian Jacobs <ij@w3.org<mailto:ij@w3.org>>
https://www.w3.org/People/Jacobs/<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.w3.org_People_Jacobs_&d=DwMFaQ&c=uc5ZRXl8dGLM1RMQwf7xTCjRqXF0jmCF6SP0bDlmMmY&r=gGO7JtsSyntBU-GDdHDB4l3lQwFRpuFyuge3kx2OlvY&m=uXMHsFKaa9MBngdY8bds9lTouudluUPw23YF4KTPgso&s=PJKFRABiflYrI02PcRRDx-d5tvBHJ3QTlYsHkolq6qw&e=>
Tel: +1 718 260 9447




CONFIDENTIALITY NOTICE This e-mail message and any attachments are only for the use of the intended recipient and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient, any disclosure, distribution or other use of this e-mail message or attachments is prohibited. If you have received this e-mail message in error, please delete and notify the sender immediately. Thank you.