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

> 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

Received on Wednesday, 31 October 2018 13:01:12 UTC