<dezra> hi all
yes
[Andres Rapela, FRB]
[Dean Ezra, Barclays]
[Lawrence Cheng, Barclays]
[Raushan Singh, Barclays]
[Peter St Andre, Mozilla]
[Rouslan Solomakhin, Google]
[Jeff Williams, TCH]
https://w3c.github.io/webpayments-methods-tokenization/index.html
https://github.com/w3c/webpayments-methods-tokenization/pull/49
https://w3c.github.io/webpayments-methods-tokenization/index.html
IJ: Ok to drop supportedCryptogramTypes?
[No objections]
<scribe> ACTION: Ian to merge pull request 49
https://github.com/w3c/webpayments-methods-tokenization/issues/44
Propose to close 44 because addressed in the spec
stpeter: +1
<scribe> ACTION: Ian to close issue 44
stpeter: I started review
yesterday; would like to spend more quality time with it. My
main question is around who will implement this?
... if you come to this spec as a browser vendor, a lot would
be opaque.
... it's not self-contained as a spec.
... might be helpful to provide more of an overview of how this
fits into the payment ecosystem.
... both with regard to how this fits into payment systems, and
also terminology.
... so I think having more intro and terminology tutorial
around concepts would be helpful.
stpeter: More info will help bridge communities
Q. Flow diagrams?
<stpeter> I just created https://github.com/w3c/webpayments-methods-tokenization/issues/50 so we can track this issue.
stpeter: People have same software everywhere - mobile phone
<stpeter> It feels like an edge case to me. (It = using two different computers to handle transactions with the same merchant.)
<scribe> ACTION: Ian to add issue to clarify story of "any payment handler" v "same payment handler" for subsequent cryptograms
IJ: Jeff, do you issue EMV-compliant tokens?
Jeff: yes.
IJ: Are there other prevalent tokenization models we should be aligning with?
- tokenization, 3ds, auth
25 September