<scribe> Scribe: Ian
Kristina: Thanks Ian for email on this; I am working with people internally to get answers
IJ: What about Amex?
Rick: I have some quesitons
... when we issue a token, we talk about the scope of the
token...and we've talked about properties in the past
... in theory the merchant will store that token somewhere
(e.g., for a refund)
... that piece of information we might need from the merchant
on what they plan to do with the merchant.
... It would be nice to have the additional data
IJ: Please capture in written summary what you need (e.g., input string or even better, enum)
Rick: Another question -how can
the merchant store a token reference in addition to a
token.
... so that's a potential new response field item "token
reference" that would be used for storage
... this would be a security token that represents the payment
token
IJ: What about Mastercard?
Keyur: Some fields are optional (e.g., info about the browser)...
IJ: Payment handler can get data
(e.g., via javascript)
... Anything missing from the protocol?
Keyur: Right now I don't think
there's anything additional required for tokenization if the
payment handler can get this type of data.
... Regarding token reference
... there are two use cases (1) enrollment (2)
transaction
... in these cases the merchant doesn't manage any unique
references
rick: When the token is given,
there might be a refund, or it might be stored for future
purposes
... we don't want them to store the FPAN; we want them to store
a reference and not the payment token
Keyur: Today merchant's don't
store references
... they use the token 16-digit number and keep it with them
for chargebacks, recurring payments, partial shipments
... MC does not share any unique reference aside from the
token
rick: It may not be the case
today but it may be the case tomorrow
... they may want the reference in the future to request
something of the schemes
Keyur: I think that's a
card-on-file scenario
... every token has some dynamic cryptogram...if the merchant
wants to do a separate transaction on the same token, they need
to go back to the handler to get the dynamic data...the
merchant still needs ot present the 16-digit number. The token
number is unique. Need ot present the token number and expiry
to get the dynamic data.
Rick: Will a merchant be able to initiate a transaction with the W3C API?
Keyur: The consumer is always
involved in the first authorization..
... for a recurring payment, how do we display the terms and
conditions to the user about recurring payments?
... once PH shares payload, the merchant can initiate those
payments
Rick: Would the merchant use same cryptogram or come back for a new one and if so how?
Keyur: For partial and recurring,
merchant doesn't need a cryptograme.
... the first payment that the merchant processes is with a
cryptogram...for subsequent payments no cryptogram is
needed
Rick: Ok, if that's the case,
it's out of scope how the merchant gets dynamic data.
... ok, that's fine.
Keyur: A third type - card on
file...when the merchant is doing a NEW transaction, the
merchant does need to get a cryptogram. For that case, the
merchant either needs to talk to the processor or the
user.
... suppose you buy something on iTunes, the card is saved
within iTunes but they cannot make a second payment until they
get cryptogram.
rick: We need to flesh this
out
... if the merchant needs to get the cardholder to do something
we need to figure that out
Keyur: I think we did not imagine card-on-file use cases for this task force
Ken: PAR?
Rick: Not what I was thinking but that is an additional consideraiton
IJ: Would PAR be extra field?
Rick: Yes
... it's not live yet in terms of solution.
... might be needed in the future
IJ: Would a version number (on the payment method identifier) be appropriate?
Ken: If we anticipate that PAR will be released in the near future, then I'd support adding it in one of the use cases
<scribe> ACTION: Ian to raise an issue about adding PAR as response data field for tokenization spec
<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: AHB will run both breakout
and recap
... I am mostly planning to facilitate
Topics to include: encryption, data model, potential convergence of *Pay, discussion of browser support, discussion of data adequacy with respect to TSP APIs.
IJ: Any update on encryption?
Ken: No luck on my end
IJ: What about Mastercard?
https://github.com/w3c/webpayments-crypto/issues
Keyur: I think we need asymmetric
keys
... the only encryption we need is to encrypt (part of) the
payload
... the structure of the message and the encryption scheme we
want to use depends on the encryption draft spec
https://github.com/w3c/webpayments-crypto/wiki/Encryption
Keyur: I think we need to have a minimal set of encryption methods
<scribe> ACTION: Keyur to propose some details around encryption
<trackbot> Created ACTION-89 - Propose some details around encryption [on Keyur Patel - due 2018-04-10].
AdrianHB: We want to be specific
about usage of JWE
... we want to create a limited profile of JWE (safe algos, key
types, etc.)
stpeter: +1.
... some issues we've heard about were about implementations
not the specs. We want to provide a strong baseline.
24 April