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

I like it.  Sorry we couldn't attend TPAC. Unfortunately we won't be able to join next year either due to timing as it conflicts directly with our MAG Annual conference involving 500 or so merchant and sponsor representatives.  Depending on activities, maybe we can find some alternative representation.

Since this thread started to insert SRC, I felt compelled to voice preference that this group approach all of these tools as just that...optional tools that can support multiple payment alternatives vs. an aggregate set of tools that are interdependent and can only support cards.  

I think W3C is all in for this approach which makes us pleased.

Thanks!

On 11/7/18, 6:16 PM, "Peter Saint-Andre" <stpeter@mozilla.com> wrote:

    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:27:08 UTC