Tokenization Task Force

15 May 2018



stpeter, Ian, Giulio, Simon, RichardWaller, Kristina, Ryan, MattD, Roy, Keyur, Ken


<scribe> Scribe: Ian


Token use types



==> https://lists.w3.org/Archives/Public/public-payments-wg/2018May/0023.html

IJ: How do those use cases fit into our token story?

Keyur: I think that a principle that we wanted to go back to is whether we want the token shared across companies.
... when expedia wants to book a car, should that just be processed by expedia for that rental agency?
... do we want to spec that out so that tokens can be shared with other merchants?
... or do re-auths?

IJ: Is there existing practice with tokens?

Giulio: I described how it happens today with raw card info

Giulio: in moving to token, multiple charges especially from different merchants becomes problematic
... I think it will be hard to push tokenization if business models have to change.

Rick: I don't think we can debate the industry practices here; it happens today whether right or wrong
... we should discuss here whether this is a use case we want to support.
... I think we should look at as many use cases as we can and see whether we can fit them into one of these three buckets.

Giulio: For the question is whether the API should allow for N > 1 tokens; should we pass the merchant id?

IJ: merchant id already in the API

Simon: The details of the transaction matter (e.g., Expedia pays the hotel and there's a separate transaction)
... the concept of sharing a token would be problematic from a domain restriction control perspective
... a token user may be sharing a user, but there is some uniqueness (e.g., unique cryptogram)
... so you can uniquely identify who has it, who is using it, and whether they should be
... the idea of sharing a network token around is probably not going to work.

Keyur: I want to echo Simon's point...it may lead to fraudulent transactions even if the token is limited to one-time use.
... I also believe that once a payment credential is generated it should be processed by one single entity
... at least for a MC token you can process multiple transactions on a single token
... e.g., recurring authorizations that come from the same acquirer/processor

rick: On this particular use case - there is some debate whether it will exist after PSD2.
... that use case may be soon obsoleted.

IJ: How does Apple Pay do this? Is it limited?

Giulio: If you go to a site that uses Apple Pay, you can, say, buy a flight but not book a hotel room.
... that's the experience today.

IJ: Domain controls sound like "same origin" controls on the backend.

Giulio: Single use domain control is a cryptogram; can be used with any merchant
... the card -on-file token may be restricted to one merchant.

IJ: I am hearing from Giulio that "one time token" might be usable (since not constrained to the merchant)

Keyur: Would the payment handler know which merchant will use the additional cryptogram?
... technically it's possible to generate 1 token and 2 cryptograms

IJ: That seems to create risks re: same origin

Keyur: Right, this use case is a window to fraud. I would exclude it from the use case for now.
... until we have a better sense of how important the use case is...note also that EU moving away from this use case. And you are indirectly violating the GDPR rules (no control over entities with whom you are sharing data about a user)

<keyur_> +present

Rick: With regards the use of the token itself, nothing stops the person using the token to bill on behalf of the third party agent
... the moving of the PAN from entity to another confuses the domain controls and may lead to a decline.
... I would second Keyur's proposal and come back to it if demand or scale become an issue

IJ: Should I add it as an issue?

<scribe> ACTION: Ian to add this topic to the tokenization repo issues list and point to the minutes

<trackbot> 'Ian' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., IFSF-EFT-WG-Lead, ijacobs).



IJ: Who has looked this over (besides me)?


Keyur: I also reviewed some of the issues associated with this topic.
... the goal here is to secure the data between the payment handler and the payment requestor (e.g., gateway)
... this is based on the JWT standard
... it uses 2 keys:

a) Data receiver

b) Data provider

scribe: A256GCM guarantees against MITM attacks
... data receiver generates a key pair; I picked RSA but happy to include ECC as well
... we should discuss whether we want to support a single one or multiple algos
... the CEK is encrypted with the receiver's public key
... I've put in an example and links to resources

IJ: how is order of claims set normalized?

Keyur: JSON serialization order
... You have header, encrypted text, and message auth code
... the auth code is compared to the header and encrypted text.

IJ: I'm trying to figure out how brittle this is.

Keyur: Order doesn't matter.
... adrianHB alluded to signatures. I didn't use them here
... signatures require maintenance of another pair of keys
... I don't think that was required here

=> https://github.com/w3c/webpayments-crypto/wiki/Signatures

Keyur: message auth code helps avoid tampering; not a signature but a hash of the data. You can validate data has not been modified in transit.

IJ: Proposed

- more readers

- add algorithmic text

- share with security IG

<stpeter> +1 - I can review

<scribe> ACTION: Keyur to work on abstraction for what a payment handler author would need to do to use encryption, and what a payment method spec would say; reach out to Ian as needed

<trackbot> Created ACTION-95 - Work on abstraction for what a payment handler author would need to do to use encryption, and what a payment method spec would say; reach out to ian as needed [on Keyur Patel - due 2018-05-22].



IJ: Which scope seems interesting?

stpeter: I think scope 2 is problematic since we are skipping enrollment phase
... e.g., enrollment of a card in Apple Pay may not be the path we have in mind here.

Ian: Which is?

stpeter: I think the path would resemble various *Pay but is more generic. Any payment handler could do things; you still need to register the payment handler with Chrome.

[Discussion of optics]

Roy: I think that some of the *Pay are not eligible for what we are prototyping since they involve merchant onboarding.
... for an open tokenization spec, you may or may not need onboarding

IJ: So should we talk about bootstrapping flow?

stpeter: Not sure we should due to business relationships

IJ: I propose reflection for 2 weeks then we come back

Next meeting

29 May

Summary of Action Items

[NEW] ACTION: Ian to add this topic to the tokenization repo issues list and point to the minutes
[NEW] ACTION: Keyur to work on abstraction for what a payment handler author would need to do to use encryption, and what a payment method spec would say; reach out to Ian as needed

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2018/05/15 16:43:31 $