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

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> wrote:

>
>
> > On Oct 30, 2018, at 10:50 PM, David Benoit <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>
> https://www.w3.org/People/Jacobs/
> Tel: +1 718 260 9447
>
>
>
>
>