https://w3c.github.io/webpayments-methods-tokenization/index.html
- Manash to analyze response data models from ApplePay, GooglePay, SamsungPay to compare with tokenization response data model
- I believe Keyur is working on request data to characterize tokens (to improve canMakePayment results).
Manash: It seems that the
response data elements are consistent across wallets that
provide token responses
... multiple wallets call a mastercard (or visa) service to
generate a payload
... as such our internal team is confident that the payload is
consistent across *Pay
... what we need to do in the main call on 8 March is to ask
the chrome and safari and samsung teams to share their payload
sample with their teams to find out if consistent with what
they are doing.
... also want to have their teams review the encryption
proposal
===
This example shows some fictitious Mastercard-specific response data.
{
displayLast4: "***6789",
displayExpiryMonth: "02",
displayExpiryYear: "22",
displayNetwork: "mastercard",
encryptedTokenizedCard: "QWxobHZ4bU4yWkt1QUFFU05GWjRHb0FCRkE9PQ==",
}
When decrypted, the encryptedTokenizedCard data would be:
{
cardNumber: "5413339000001513",
expiryMonth: "12",
expiryYear: "20",
cryptogram: "AlhlvxmN2ZKuAAESNFZ4GoABFA==",
typeOfCryptogram: "UCAF", // "Universal Card Authentication Field"
eci: "242", // Authorization and final transaction request with UCAF data
trid: "59812345678",
}
===
<scribe> ACTION: Ian to reach out to Samsung, Apple, Google to see if that model matches what they are returning and see if they can report by 8 March
<trackbot> 'Ian' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., IFSF-EFT-WG-Lead, ijacobs, ijmad).
manash: The cryptogram is
generated differently (e.g., Apple SE v. Google HCE)
... the data payload is consistent even if source differs
... the ECI (the authentication code) would be different for
different networks
... it's not different from what parties are already
generating
<Rick> Token Requestor ID
IJ: What is trid
<scribe> ACTION: Ian to fix the definition in the spec and reference
<trackbot> Error finding 'Fix'. You can review and register nicknames at <http://www.w3.org/Payments/WG/track/users>.
clinton: Looks good. The type of
cryptogram is needed, and the request message including trid as
well
... do we perceive the need for other types of
cryptograms
... do we think typeOfCryptogram needs more flexibility?
Richard: Merchant will only be able to process a certain type of cryptogram
Clinton: What about shared tokens?
Manash: Android cryptos are
generated in HCE...that's one reference point
... the other references points...both MC and Visa already
support (and Amex experimenting with) different cryptograms
that are generated by other parties
... format may vary so makes sense to keep it flexible
IJ: Any progress on token characteristics for request data?
Clinton's msg => https://github.com/w3c/webpayments-methods-tokenization/issues/25#issuecomment-363506135
Manash; First priority use case is 1-time token. Second priority is recurring. Then other use cases could follow (e.g., split shipment)
scribe: I will ask Keyur to do a
bit more analysis
... I think the current format could support recurring
payments, but we need to validate that
Clinton: Is trid sufficient to describe the token type?
Richard: I think we will need
more than trid to describe the properties of the returned
tokens
... the cryptogram might play a role in identifying the token
nature
IJ: To clarify, do we need response data?
Clinton: If token requestor is registered with TRID may not need more data, but if not registered may need more information to help identify the type of information needed for those merchants.
Manash: What do we need for a good discussion?
https://github.com/w3c/webpayments-methods-tokenization/issues
https://w3c.github.io/webpayments-methods-tokenization/index.html
Clinton: I think we have
variation in request message v. response
... mostly the request message data will depend on type of
token needed and who is making the request.
IJ: What's the narrative for the group on the 8th?
Manash: In order for PR API to be
adopted in markets with *Pay wallets, we want to create a
common standard across tokenizations
... to lower cost of merchant integration
... the tokenization spec aims to do that
... at this time need WG (and browsers in particular) to look
at the spec and see whether it solves some use cases for
them
Ken: Is it too early to call for volunteers to implement?
(IJ: Never too soon!)
Manash: For us the important next step is that browser vendors look at it and we get support for the short name to be able to do more experimentation
IJ: Do you mean support for the short string or more than that?
Manash: Implementation as a W3C-standardized spec like basic card
<Zakim> AdrianHB, you wanted to ask about how this interacts with 3DS
adrianhb: Bear in mind that if we
are looking for browsers to implement this in the standard,
they will want rigid data structures.
... they might want an enum instead of an open string, for
example
... How does this spec interact with 3DS?
... if I am doing a tokenized card payment, does 3DS come into
play? Can it come into play?
... we should be clear about this at 8 March
Manash: Agreed. To answer the question , the 3DS work is seen as a (cross-payment-method) add-on
https://github.com/w3c/3ds/wiki
adrianhb: Would be good to show example on 8 March
stpeter: back to implementation
question, I will look in more detail about the scope of work
that would be required for implementation (in the
browser)
... could be that the scope of work for the browser is
constrained and may not need to do a lot of
analysis
<scribe> ACTION: Peter to investigate cost of tokenization payment method implementation in a browser
<trackbot> 'Peter' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., OrtonP, stpeter).
1) Short string support
2) Some functionality related to the data (e.g., storage or analysis)
3) canMakePayment() matching
Manash: I want both PMI Support to be able to test multiple apps
Ken: We should see what implementation schedules might be as well
Rick: Regarding 3DS => it
validates the card holder. The card details just start the
payment process.
... validates card holder according to the issuer
... when you do 3DS you do get a separate cryptogram on top of
the token cryptogram
https://w3c.github.io/webpayments-methods-tokenization/index.html
Richard: In 3DS 2.0 there's an
authentication request. In the response the issuer can send
back and AV with a cryptogram (or require a step up)
... in theory the response is two bits of info (1) cryptogram
(2) transaction reference id
... that information is about the cardholder
IJ: Should that be part of the 3DS add-on?
Richard: It depends on who
requests the 3DS
... if the browser acts as a client and does the 3DS on behalf
of the merchant, that would be great for scale, but the browser
would need to return both cryptograms to the merchant as it has
done so on behalf of the merchant.
https://github.com/w3c/webpayments-methods-tokenization/issues
https://github.com/w3c/3ds/issues
<scribe> ACTION: Richard to send Ian (or add to GitHub) information about second cryptogram required (and when) from 3DS 2 response
<trackbot> Error finding 'Richard'. You can review and register nicknames at <http://www.w3.org/Payments/WG/track/users>.
AdrianHB: Regarding
implementation of tokenization payment spec in browser, PR API
supports the payment method NOT requiring validation by the
browser
... so It think that Ian's assessment is correct - it's
possible to not require conversion to IDL, just converted to a
JSON string.
https://github.com/w3c/webpayments-crypto/wiki/Encryption
IJ: No progress from me.
Peter: Me neither
... I will do some outreach
... I would like to write up a proposal this week and have some
results.
AdrianHB: I have been told that AES-GCM is the preferred method
AdrianHB: we've looked at this
around ILP
... and spoken to some people we believe to be
knowledgeable
... the AES-GCM seems to be the "best way to do symmetric key
based encryption" but doesn't help with asymmetric
... but it might be possible to wrap a symmetric key in
something else
... I think we can define a profile of JWE that we like, where
we limit the allowed keys/algos.
<scribe> ACTION: Ian to put together 8 March presentation for the full WG
<trackbot> 'Ian' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., IFSF-EFT-WG-Lead, ijacobs, ijmad).
Next meeting 6 March
scribe: after that no meeting 13 March