See also: IRC log
https://github.com/w3c/webpayments-methods-tokenization/wiki
https://github.com/w3c/webpayments-methods-tokenization/wiki
IJ: How does this sound to people?
Manash: Thanks for sharing the
draft.
... I think overall this looks pretty good
... we might come back to you with recommendations on edits
based on things like "issuer tokens"
... what should we say about issuer tokens?
... we have mentioned merchant-specific and PSP tokens
... one target audience would be bank-based payment apps.
... so want to mention issuer tokens explicit
... An action item from our end would be to come back to you
before next week with some specific text edits
... but I think we are moving in a good direction.
Keyur: I sent some feedback.
<oyiptong> +1 on mission statement
IJ: Thanks! I have
incorporated.
... Stripe folks?
cweiss: Not yet.
Stan: I have a question about the
benefits of this effort. Saying that it will make it easier for
PSPs to interact with more merchants
... it hints at the fact that we would allow to merchants to
interact with PSPs they don't have a relationship with.
IJ: I would distinguish business relationships v. technology friction. Let's make that clearer.
Stan: +1 to scoping this to providing standardized APIs for collecting tokens from PSPs. that makes sense
mweksler: I agree with Ian (about
the standard pipe, not the token shape). A business
relationship is still necessary; we may or may not need to say
that in the mission statement.
... but I agree that a business relationship is still
necessary
shift4sms: Yes,agree. I think the
goal in this document should be to give vendors on what data
they need to accommodate for, now how to do it.
... give merchants a heads-up on data requirements.
IJ: I think we need to figure out whether we can come up with common data set.
<Manash_MC> +1
Ken: Please call out relationship to EMVCo
IJ: +1
Ken: What does this solve for
that EMVCo spec does not?
... whatever the answer, let's include that.
... Meanwhile, I like the initiative and in principle am
supportive of it.
Manash: We can take a stab at a FAQ entry
IJ: At the bottom of this https://github.com/w3c/webpayments-methods-tokenization/wiki
mweksler: how are we editing?
IJ: for now I'm cool with people editing directly in the wiki
<mweksler> +1
https://github.com/w3c/webpayments/wiki/How-the-Working-Group-works
IJ: Let's use issues list for
discussion and perhaps important or controversial text
proposals
... welcome other people's contributions to the wiki
Keyur: We could mention in the mission statement that our mission is to leverage existing token schemes supported by issuers, PSPs, and networks, and make it easier for merchants and PSPs to process payments with these existing schemes.
<scribe> ACTION: Manash to work on a FAQ entry about relationship of this work to EMVCo specs [recorded in http://www.w3.org/2017/05/16-wpwg-minutes.html#action01]
<trackbot> Created ACTION-57 - Work on a faq entry about relationship of this work to emvco specs [on Manash Bhattacharjee - due 2017-05-23].
Keyur: Summary of discussion was that there are device tokens that can be given to merchant...so we don't need an intermediate PSP token in those cases
scribe: we need to update the
diagram
... we want to enable merchant to say what kind of tokens the
merchant's PSP(s) support
https://github.com/w3c/webpayments-methods-tokenization/blob/gh-pages/diagrams/w3cpayment.pu
IJ: How do we get this easy communications among parties?
Keyur: Payment method can talk
about merchant-supported token types
... the list could be defined in the payment method.
... "psp", "network", and maybe "issuer"
Manash: Some issuers can issue
virtual card numbers
... Should we look at dynamic CVV, dynamic expiry?
... we should be sure to cover those as well
Keyur: Internally, MC and Visa
support dynamic expiry and dynamic cvv
... the wallet can generate dynamic value that is a random
number and that's what's given to the merchant in addition to
the card number
... the merchant processes payment with pseudo PAN, CVV,
Expiry
... the network translates
... as I think of this, it seems closest to basic
card...merchant doesn't need to know that it's a token
Manash: Agree mostly. If a merchant is willing to accept dynamic CVV, they have to specify that they ask for CVV
alyver: (Catching up)....I think
that dynamic cvv and expiry fits best with basic card
... would the merchant have to specify their PSPS and whether
they support network or gateway tokens, there are a lot of
merchants who have no idea.
<shift4sms> +1 on merchants not knowing token type to ask for
alyver: they might know they
support *PAY due to integration of code
... or similar for Masterpass or Visa Checkout
mweksler: I want to add some
color to the conversation and highlight some of the potential
needs.
... to begin, I think that the fact that the network tokens can
at times fit into basic card is great...for those cases, we
would not need another spec.
(IJ THINKS WE SHOULD CALL THIS OUT IN THE WIKI)
<alyver> correction: I was suggesting that dynamic expiry and cvv fit into basic card. token are different.
mweksler: Many merchants,
however, have integrations that don't look like basic card.
AirBNB doesn't see PANs. All that info is shipped to a PSP.
They provide AirBNB with a token
... that pattern of integration is the one that we are
discussing here and doesn't fit with basic card. It does
require a different integration on the front end and the back
end.
... on the front end, the mechanism for capturing info needs to
be able to ship info to a PSP and return a token to the
merchant
... and on the backend, the merchant needs to have a
relationship with the PSP who can process the token
shift4sms: Regarding format
preserving tokenization, this is not a format my company
supports in particular. PCI has a clause in their scoping
document about tokenization. If you have format preserving
tokens, you need to be able to distinguish them from regular
card numbers...that's why I lean towards non format-preserving
tokens
... so we should call out pros and cons
... the other problem with format-preserving tokens is
collisions with real data...
... there's a higher chance of collision when your data needs
to fit within the confines of a data number
alyver: Thanks for the
clarification. I was referring mostly to dynamic cvv/expiry
fitting with basic.
... if we are talking about stripe or braintree types, etc. if
that's the problem we are trying to solve, that's fine.
... I think in the case of gateway tokens, there is an
assumption of backend integration for merchants to work with
PSPs.
... if you look at android pay for mobile spec, they have bits
on support for gateway tokens....that's a good example
(IJ: plans to add a bit on basic card and dynamic data to the wiki)
oyiptong: Why are we talking
about format-preserving tokens v. non format preserving?
... I don't think we are constraining tokens.
<alyver> re: Google's support for gateway and network tokens https://developers.google.com/web/fundamentals/discovery-and-monetization/payment-request/android-pay
oyiptong: I think we should try
to write a spec to be token-type agnostic
... merchant will specify supported tokenization schemes
... does it matter what format the token is in?
stan: I want to touch base on the
basic card spec.
... I think the motivation here was to enable network-level
tokens and issuer tokens to circulate
... maybe there's a world in which we manage to handle network
tokens in basic card spec
... and that we we don't try to solve network and PSP tokens at
the same time
... these things operate at very different levels
... feels like we may wish to tackle these separately
shift4sms: I've heard a few
comments about merchant specifying token type
... to me, it seems that "network" and "issuer" token are the
same....are they different in practice?
... if you say "I cannot support a network/issuer token" do you
really have a choice at that point?
Keyur: Regarding issuer/network
token...in the draft tokenization spec, there is a distinction
between issuer and network token
... I hear from Manash that issuer tokens are more like virtual
cards
... virtual cards don't address our PCI/compliance issue
... someone should dig into this question of whether issuer and
network tokens are materially different
... if it's a virtual card, it should be done via basic
card
<Zakim> Ian, you wanted to speak about why it could be useful to allow for more
<oyiptong> thanks, Ian
IJ: I think that it is interesting to try to see if we can handle lots of use cases where tokens of all types come from the user side, and it's easy for merchants to get tokens without knowing their exact format. Hard question for me is whether we can abstract across request data.
Ken: I think network/issuer
distinction is about who runs the vault.
... I want to make sure we are not replicating existing
tokenization specs.
stan: I want to add some
perspective. If the effort is to provide a simple solution for
merchants to get PSP tokens, then we need a bigger spec since
these tokens can represent lots of other payment methods
... I think that it may make sense to think of "EMVCO" (which
might fall into basic or not)...and then handle PSP
differently
... merchants might not be happy to have one spec for "cards"
and have to do other things for other payment types
https://github.com/w3c/webpayments-methods-tokenization/wiki
The focus of this Task Force is tokenized card payments.
"
IJ: Great question - whether we tackle smaller problem first and learn, etc.
Stan: Maybe we can live with crossing abstraction boundaries, but I want to be explicit
mweksler: +1 to crawling before
we walk. If we start focusing on something that is well-scoped,
I think we might achieve something that will work.
... but stan makes a good point
<oyiptong> +1 on mweksler's comment
IJ: Anybody want to look at data requirements in preparation for next week's call?
Stan: I can take an action item to write down input data from different providers.
\o/
<scribe> ACTION: Stan to look at input data requirements across a few token providers [recorded in http://www.w3.org/2017/05/16-wpwg-minutes.html#action02]
<trackbot> Error finding 'Stan'. You can review and register nicknames at <http://www.w3.org/Payments/WG/track/users>.
23 May