https://w3c.github.io/webpayments-methods-tokenization/index.html
https://github.com/w3c/webpayments-methods-tokenization/issues/47
https://github.com/w3c/webpayments-methods-tokenization/issues/47#issuecomment-413128253
Jeff: UCAF, Visa model, DTV
(dynamic CVV2)
... those are 3 digit code options
CAVV (is that Visa)?
Ian: Is it a scenario where someone accepts UACF and not the visa one?
Jeff: I think it's more likely
they will choose "established" v. "dynamic cvv"
... I think supporting full cryptogram (UCAF, CAVV) would add
friction but would be more secure
Manoj: +1 to targeting full cryptogram
Jonathan: Dynamic approach is a temporary solution
Jeff: If we are going out to get merchant POV, that's a good question to put on the list.
IJ: I am hearing then "full cryptogram". Does saying "I support one or both" align with what people would want to do in the ecosystem
<scribe> ACTION: Ian to solicit some merchant input on cryptogram types
<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: Are formats different between
MC and Visa versions? Or do they both conform to EMVCo?
... do people need to filter if there are only 2 values?
Jeff: If you accept tokenized visa, you need to support CAVV. If you support MC tokens, you need to support UCAF
Jonathan: Likely aligns with network
IJ: Do we need versioning?
Manoj: I don't think so
IJ: I am hearing
- Preference for full cryptogram
- Full cryptogram follows network
- We can drop supportedCryptogramTypes
- Add to "Assumptions" statement about preference for "Token Cryptogram" rather than dynamic data.
Manoj: I suggest leaving it as "Cryptogram"
<scribe> ACTION: Ian to summarize this discussion in issue 47 with proposal to delete supportedCryptogramTypes
<trackbot> 'Ian' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., IFSF-EFT-WG-Lead, ijacobs).
11 September