W3C home > Mailing lists > Public > public-payments-wg@w3.org > November 2018

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

From: Grossar, Jonathan <Jonathan.Grossar@mastercard.com>
Date: Mon, 5 Nov 2018 17:09:14 +0000
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>
Message-ID: <e5b0482dbcea411f9078e70e265921dd@KSC3MSX03.corp.mastercard.org>
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.
Received on Monday, 5 November 2018 17:10:45 UTC

This archive was generated by hypermail 2.3.1 : Monday, 5 November 2018 17:10:46 UTC