Re: Expectation to merge tokenization and 3DS task forces; upcoming schedule

Hey all, now that the conversation is blending SRC with 3DS and tokenization, I feel compelled to share our POV.  Representing the Merchant Advisory Group and 140 plus of our merchant members, we support W3C review of the SRC DRAFT spec to 1/understand how the 2 standards can co-exist for cards and 2/offer comments for potential incorporation into the SRC FINAL spec.  As I understood our Web Payments Working Group call last week, SRC specific discussions will take place in the Web Payments Working Group vs. the Tokenization/3DS Task Forces unless we feel there is pertinent info to bring forward to the task force as a result of the review.  Ian, please correct me.

As I understand it, tokenization is optional within SRC as designed in the draft spec although the card payment networks have made it clear both tokenization and 3DS will be integral to their individual implementations of SRC.  Despite the latter, the optionality still should keep the SRC conversation someone separate and distinct from the tokenization conversations within W3C.  In fact, a webinar I just saw this week continues to confirm that tokenization and 3DS are part of the payment environment which is not in scope of SRC but can be enabled through SRC participants.  I agree tokenization and 3DS are tools that support card payments today and the task forces have been pursuing efforts already to evaluate how the PR API can support both of these EMVCo specifications.  (Ian, again correct me if that is not accurate).  These are all separate and distinct payment technologies that should be able to standalone as well as work together depending on the participating stakeholder preferences.

All that being said, MAG does not  support concentration of efforts on EMVCo SRC interoperability in isolation or priority at the expense of other alternatives that offer choice and competition. If there are other prevalent in-market or not yet commercialized alternatives that support ACH, direct debit, or otherwise, W3C should engage in parallel with the same level of commitment.  I agree the demand for clarity regarding SRC is true but the broad market demand for SRC is TBD.  The challenge with a parallel path is to ensure there are no conflicts in direction.

I think we are saying similar things but felt it important to voice our perspective.

Laura

From: "Grossar, Jonathan" <Jonathan.Grossar@mastercard.com>
Date: Monday, November 5, 2018 at 11:11 AM
To: Adrian Hope-Bailie <adrian@coil.com>, Ian Jacobs <ij@w3.org>
Cc: David Benoit <benoit@withreach.com>, Payments WG <public-payments-wg@w3.org>
Subject: RE: Expectation to merge tokenization and 3DS task forces; upcoming schedule
Resent-From: <public-payments-wg@w3.org>
Resent-Date: Monday, November 5, 2018 at 11:10 AM

As pointed out below, the release of SRC specs (and the public review period) is a great opportunity for the group to understand the areas of interoperability between W3C and SRC standards, to understand how W3C could leverage SRC and 3DS specs to secure cards payments processed through Payment Request API, and to provide EMVco with feedback (to possible update their specs).

I agree with Ian that there is a clear demand from the ecosystem to understand how the 2 standards can co-exist and therefore, the proposal was made at the plenary to concentrate efforts and (limited) resources on this analysis within the tokenization taskforce, in order to produce a tangible outcome.
It does not exclude obviously any other work, which can be done in parallel of this analysis.

From: Adrian Hope-Bailie [mailto:adrian@coil.com]
Sent: Sunday, November 4, 2018 4:28 PM
To: Ian Jacobs <ij@w3.org>
Cc: David Benoit <benoit@withreach.com>; Payments WG <public-payments-wg@w3.org>
Subject: Re: Expectation to merge tokenization and 3DS task forces; upcoming schedule


CAUTION: External email. Please do not click on links/attachments unless you recognize the sender.


Having begun to understand SRC better I'm not sure I agree there is "concrete demand" for a card specific tokenisation spec and if there is, it is misplaced or coming from the wrong stakeholders.

I think there is a great deal of work for us to still do to fully understand how SRC integrates with our APIs as it is an all-encompassing system that optionally includes tokenisation and 3DS. i.e. Tokenisation is a tool (and it's a tool that can be used for a variety of payment methods and instrument types, e.g including IoT devices)

I think the ideal approach now is to review the SRC flows along with the flows for other payment methods that also have strong demand (such as those being used in the SEPA region) and try to define a tokenisation payment method standard that accommodates them all, by treating tokenisation as a tool, not a type of payment instrument.

Further, having looked at the current card tokenisation spec it's pretty clear that there is nothing in there that "won't work" if it is made more generic so I'm not clear what we gain by explicitly excluding all other payment instrument types and creating the impression that the WG's "tokenization" work is only going to accommodate tokenised cards.


On Wed, 31 Oct 2018 at 15:01, Ian Jacobs <ij@w3.org<mailto:ij@w3.org>> wrote:


> On Oct 30, 2018, at 10:50 PM, David Benoit <benoit@withreach.com<mailto:benoit@withreach.com>> wrote:
>
> Good evening.
>
> I know I am new to this group, and don't have all of the history of these working groups at hand for context, but I'll throw in my opinion for what its worth.
>
> I think approaching a topic such as this and focusing only on cards is a lost opportunity.
>
> In my mind, reaching out to some external party to verify a cardholder (3DS/SRC/etc) is no different from reaching out to something like PayPal/etc. that doesn't have a card.  In both cases, you are asking some entity for permission to authorize payment related to some transaction/invoice/etc., and the result of that is some  "token" that can be passed back to whomever is requesting authorization, then through to whatever is responsible for dealing with that "token".   In the case of PayPal, that is some token that you get back from them that is only meaningful to PayPal.  In the case of a card, it could be some encrypted payload that contains all of the information necessary, similar to what ApplePay produces, or some opaque identifier that references card information that would already be saved with the ultimate recipient of the token.
>
> The interaction - from the point of view of an API consumer - shouldn't need to be different just because it is a card.  I was very happy to hear Adrian's pitch to unify this effort, and would very much prefer that the specification head in that direction.

Hi David,

Thanks for sharing your view; we welcome that!

Regarding whether to address a specific set of use cases or take a more generic approach, I think the biggest driver is that there is concrete demand (right now) for the former and  theoretical interest in the latter. We are always looking for implementers so we can write specs for them.

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=2ArBK_5KTqxFNOUiQ58NeBc3GqpPK5LJjjjO6kqwKhg&m=D6r7EXzKO3E9DbjLBH5qafJ3CsPjl3tGx0hfFJgNXz0&s=EMV3o2TgWa-1ZRrykxBDNy2PIC7_fFL84R1hSPq_Cyg&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.