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

Hi Laura, thanks for your input.

In the TPAC meetings we talked about defining tokenization in such a way
that it could enable a wider range of payment methods, e.g., ACH pull
payments could result in generation of a token. This could provide a
path to the kind of choice and competition MAG wishes to see.

Peter

On 11/7/18 4:56 PM, Laura Townsend wrote:
> 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.
>

Received on Thursday, 8 November 2018 00:16:47 UTC