<scribe> Meeting: Tokenization Task Force
<scribe> Chair: Ian
https://w3c.github.io/webpayments-methods-tokenization/index.html
https://github.com/w3c/webpayments-methods-tokenization/issues/44#issuecomment-405567047
IJ: Any reactions?
Jonathan: Do we want an option with just a token ref id where the merchant can get payload?
IJ: should that be an option or the only way it's done?
Chris: From a customer
perspective you want card art and other information for the
user experience.
... How does handler get updated info when card is updated?
Jonathan: One standard flow is for the merchant to connect to the TSP either through gateway or by itself and get data using token reference id.
4 quadrants:
* No relationship first transacation
* No relationship, n+1 transaction
* Relationship, first
*Relationship, N+1 transaction
Anyone want to review the proposal?
[No hands]
Chris: So long as their is a way
for merchant or their gateway to get access to updated
information, that addresses my question
... update services are behind the scene; users unaware of
them
... highlights the importance of something like last4 so that
user realizes card on file is same as what customer has.
... the promise to merchants is that tokens will be
evergreen
... that puts the onus on issuers to execute the remapping of
tokens when a card is reissued.
... if any part of that process breaks down, becomes harder for
issuers to execute on the lifecycle management
... last4 turns out to be an important UX component.
Rick: for use case where
relationships exist, you will know the TSP.
... trid will help you identify yourself
... ken and I will continue to look at the data model
Manoj: where there is an existing relationship and tokenrefid is used, how in this model do we ensure that the proper auth is given to the merchant to access these details?
IJ: Today we are not encrypting
it. We could.
... and I'm assuming payeeID is paired with token for future
validation
Manoj: I'd like to think through
it.
... I think there is a pairing of payeeId and tokenreferenceid;
I want to think about whether that's good enough.
Rick: I think the important thing
is to combine trid+tokenreferenceid .. the important thing is
to get it right in the first place.
... for the initial token
https://github.com/w3c/webpayments-crypto/wiki/Signatures
Proposed: 31 July
<Ken> +q
<scribe> ACTION: Ian to work with Ken and Rick on question of relationshiop/no-relationshiop flows (2 payment methods)
<trackbot> 'Ian' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., IFSF-EFT-WG-Lead, ijacobs).
Ken: Would be great to get TSP perspective
<scribe> ACTION: Chris to review the tokenization spec
<trackbot> Created ACTION-101 - Review the tokenization spec [on Chris Marconi - due 2018-07-24].
https://w3c.github.io/webpayments-methods-tokenization/index.html
https://github.com/w3c/webpayments-methods-tokenization/issues/44
https://github.com/w3c/webpayments-methods-tokenization/issues/44#issuecomment-405567047
Question:
- is the data model correct?
- how are we handling card-on-file? Do we need two payment methods?
Ken: Input from Airbnb would be great
(Ian: I cc'd Airbnb in my most recent message on GitHub)
Ken: Good to get merchant, PSP, browser perspective, too