See also: IRC log
<scribe> Scribe: Ian
Roy: What do we need to do to get the spec to a place where it is supported?
oyiptong: We did get some
feedback in Chicago
... next steps included the possibility of multiple payment
method specs
https://www.w3.org/2017/03/24-wpwg-minutes#item03
IJ: what problems do we want to solve?
Roy: My rendition of "what
problem we want to solve": basic card is a bootstrapping
mechanism. Where we want to go as an industry is toward
tokenization
... so the purpose of the spec is to make it easier to do
tokenized (card) payments
oyiptong: If I may, I know you just mentioned that gateway tokens might be too proprietary ... I would like for us to consider also creating a gateway token spec
roy: It's not that we don't think it's valuable, but we think that the inputs/outputs are so different, we weren't sure how to produce a payment method spec
manash: MC joined W3C the week
before last. Sachin and I will be representing MC in the task
force and we're happy to be here.
... MC (as well as Visa, Amex) have been promoting tokenization
in the market for some time. EMVCo's standard has been adopted
by issuer banks, acquirers, merchants, and gateways
... there are different types of tokenization...there is card
on file but also card on file on the merchant side
... you can generate cryptograms through cloud-based
methods
... there are tokens on secure elements
... there are tokens in the cloud
... we should look at existing standards in the market
... we think that tokens are more secure (than PAN)
... and also liability shift is an important
consideration
... we should also understand what should motivate merchants
when they adopt tokenization
sachin: I need some clarity on the drivers on this
Roy: Spec had been focused on issuer/network tokens
Sachin: the conversation is
around acceptance...
... suppose stripe starts accepting network/issuer
token...doesn't that solve e.g., the Airbnb use case and
liability issue is covered?
oyiptong: Yes
Michel: I think issuer tokens
would work, they would require a different integration than the
one we have today, which is not a small undertaking.
... where olivier was going earlier was to try to create a
standard that would more closely describe what many merchants
have today
... where they have someone like braintree or stripe they
integrate with .
... and those are gateway tokens
... I think that there are many merchants that have
integrations like that....they get a token that they use
... I take roy's point that there's a lot of proprietary
information, but I think that there's room to create a standard
to make integration earier
Sachin: There is merit in that
conversation. The construct is similar
... there is definitely room for standardization. ...but
... the merchant might need to recode their backened to the new
standard
... or there's a data arbitrage that does the conversion
oyiptong: Where is tokenization
done? At issuer level or gateway level?
... I think it doesn't matter as long as there is one
standard
... but I think we need to account for a transition
period
... there will still be knowledge needed to generate the
tokens
... we could align ourselves with something that exists
Sachin: We are calling both these
things "tokens"...but they are fundamentally different
... PSP token is an identifier of data kept in the PSP's data
store
... the issuer token is a cryptogram that is associated with a
single-use transaction that can also provide a liability
shift
mweksler: Yes, they are different
as described, but in their pattern of use they are not so
different
... e.g., the user provides a PAN and the merchant gets a
token
... they do have different characteristics
... but the distinction for user or merchant is less
clear
... the way that the data is transmitted to the acquirer is
very different
1) PSP token - the regular PAN is eventually transmitted
2) Gateway - Cryptogram is transmitted and PAN never leaves the vault.
Manash: there is also additional
data that is communicated
... the nature of tokens is different.
mweksler: What are the differences?
Sachin: It might help for us to
have an overview session regarding network tokenization ... but
before we do that:
... in the case of a network token is what we are generating is
a cryptogram that goes in a specific field in the message sent
to the acquirer.
... the funding PAN is never transmitted
... so there are big differences in what data is
transmitted.
Stan: I will take the voice of
our users...I think of merchants and users speaking in terms of
gateway tokens
... if they are happy users of their gateways, they don't want
to switch
... at the end of the day, users/merchants really do want
gateway tokens
... if we only come up with a standard that excludes gateway
tokens, we will end up with client-side javascript
libraries
<oyiptong> +1
Stan: even if the w3c standard is
used under the hood, stripe, braintree, etc. would have to use
their own APIs
... in client-side libraries
... that's one argument for including gateway tokens
sachin: I hear that ... want to
understand a bit more
... suppose you have a merchant who is not PCI compliant..they
will continue to use gateway tokens...and any issuer
tokenization needs to be handled, it will be handled by the
gateway (e.g., behind the scenes)
mweksler: I think what's
important to think about is from the user/merchant
perspective..t.he fact that we are doing gateway or network
does not look that different
... the merchant "does not care"
... of course the tokens are used differently and have
different security properties
... but if you look at what the user and merchant see using the
standard, is that they have a similar experience
... the user provides a PAN and out comes a token
... If the differences are big we might end up with 2
standards....
Sachin: I think the diffs are
fundamentally large
... we can write down both types, or sequence diagrams to
help
oyiptong: I want to add to michel
/ stan...i think there are current business needs met with
gateway tokens
... vaults are important for recurring payments
Sachin: Agreed. These are
fundamentally different constructs
... I think the w3c need my be more toward gateway tokens
... and behind the scene activity may be different
Stan: I think the right spec should be a layering of network tokens and on top of that gateway tokens
Sachin: I will take 2 actions
1) Present network token spec as an example
2) Sequence diagrams for both network and gateway
oyiptong: It seems like the network and gateway tokens are orthogonal and we could come up with an abstraction
IJ: Maybe we start thinking about things as layers
9 May