See also: IRC log
Sachin: Chatted with MichelW.
Have a draft diagram
... need seems to be leaning toward a tokenization
... solution enabling non-pci compliant merchants to
... participate in this system reusing their existing PSPs
<oyiptong> +1
Roy: Makes sense :)
<mweksler> +1
[No opposition to that position]
Sachin: Within masterpass we have
a construct of converting creds into an opaque identifier that
we pass back to the merchant along with some identifying
information about the payment method (e.g., last4 and brand
ID)
... the idea is that not only MC but other PSPs that provide
hosted page functionality provide similar services
... the idea was "let's try to see whether we can come up on
the format"
... would not impact merchants, but those participating from a
wallet/PSP perspective would need to follow this
... this is fundamentally not about network tokenization; that
would happen behind the scene between PSPs and networks
[We review a flow diagram]
Keyur: User registers a payment
method (via payment app)
... note that wallet provider or PSP can provide payment
apps
... payment app stores credentials
... merchant PSP does processing
... mediator (browser or other) is user-controlled
... there's also an acquirer
[User interaction phase]
scribe: merchant does
canmakePayment..if ok then calls PR API
... identifies a tokenization payment method
... the data includes PSP identifier (which PSP the merchant
supports)
IJ: Can that be a list of PSPs?
Keyur: Yes
Manash: So far the discussion has focused on gateway tokens and network tokens....are there other tokenization processes we should be considering?
Sachin: Good point. We've not delved into it. But one idea is that network token is "under the hood"
Manash: Another point is "what
happens when tokenization is not supported"
... eg., dynamic expiry and dynamic CVV
... so we should be taking into account the available security
mechanisms.
... I think we should taken into account all these mechanisms
that the merchant might accept
Sophie: I'm familiar with various token types. I am struggling to understand what "gateway token" means.
mweksler: That's more familiar to
merchants who do "vaulting" whereby the merchant integrates
with the PSP and lets the PSP collect card data from the
user
... the PSP then shares an opaque id with the merchant
Manash: Network token here refers to EMVCo token
Keyur: In the flow, when the
merchant sends a payment request, the merchant does not know
whether the PSP supports network tokens
... so the merchant refers to the PSP(s)
... so matching by mediator would include determination that
"app supports communication with the PSP"
... then the user chooses a payment app
... there could be an option where some payment apps have
multiple cards
... user performs card selection
... once app has been selected, payment request data + card
identifier sent to payment app
... payment app returns an opaque token identifying this
translation, also card brand, last fours and setupURL
s/token identifying this transaction/token for the card/
scribe: then payment response
goes to merchant/PSP with token, etc.
... when the token is generated by the payment app, it would
look up the PSP .... then response indicates which PSP was
used.
... the returned token goes to that PSP
Keyur: PSP can act like a payment
app (@@Ian missed it@@). But when PSP does not act like a
payment app,
... the PSP would get a URL, fetch the @@, sign it...
... and this would let wallet verify identity of PSP
... in the PSP supports a network token format, then the PSP
would tell that to the payment app provider
... so the PSP indicates support for network token (or
not).
... if so, then the response (step 20) would be a network
token
... if not, then the response would be FPAN
... the reason we are asking the PSP to give us the details
(whether EMV supported or not)
... because the PSP is the only entity integrated into the
acquirer
Mweksler: AirBNB does use a PSP
oyiptong: We use PSPs, there's even a desire to use multiple PSPs
Manash: Depending on what token
is being served, it changes the payload
... e.g., EMV-based tokens would have different fields passed
on to the PSP
Keyur: Yes, the payload would be different but the response format would support both result types
<Zakim> Ian, you wanted to mention matching algo and to ask more about PSP identifier
IJ: How does Payment App talk to PSP? What is the identifier about? a URL?
oyiptong: Thanks for this
diagram, I think it represents most of what we want to surface
to merchants
... being PCI/DSS compliant is a requirement on the backend and
keeping the system separate is a valuable tool...I think this
will interest other merchants
... so as an area of focus, I like that we are talking about
gateway tokens....
... is there any move towards "defining" the choices of
PSPs
mweksler: I would really like to
continue going through the diagram in more detail; lots of new
concepts that probably make sense
... I would like to have a better understanding of the Happy
Path
... but also of the StepUp path
Steve: Nobody has mentioned
issuer today...has that been dropped off...how is that handled
differently?
... are there more use case examples for this?
... I'm a gateway provider...I'm having a hard time knowing why
I need to know the difference between token types
Sachin: I think that we are focusing here on creating an opaque identifier that behaves more like a gateway token than anything else, but provides
support for network tokens
scribe: it will be the responsibility of payment app provider and PSP to exchange appropriate information.
IJ: I'd like some high-level prose and can help
<oyiptong> +1
Mweksler: +1
<mweksler> +1 on hour long
<Sachin_Ahuja> +1
<shift4sms> +1
PROPOSED: 1 hour long call starting next week
SO RESOLVED
<scribe> ACTION: Ian to extend the call to one hour [recorded in http://www.w3.org/2017/05/09-wpwg-minutes.html#action01]
<Zakim> Ken, you wanted to requests that Ian reprint the link/URL for the diagram, please..
IJ: Let's put diagram in repo
16 May, for 1 hour