<scribe> Scribe: Ian
https://lists.w3.org/Archives/Public/public-payments-wg/2018May/0025.html
https://w3c.github.io/webpayments-methods-tokenization/index.html#tokenusagetype-enum
https://lists.w3.org/Archives/Public/public-payments-wg/2018May/0023.html
==> 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).
https://github.com/w3c/webpayments-crypto/blob/master/payment-encryption.md
IJ: Who has looked this over (besides me)?
[Silence]
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].
https://www.w3.org/2018/Talks/ij_tokenization_20180515/token.pdf
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
29 May