See also: IRC log
<michel_cc> presnet+ Michel (CC)
<michel_cc> not yet
<michel_cc> (password missing)
<oyiptong> https://github.com/w3c/webpayments-methods-tokenization/wiki/gateway_params
<scribe> scribe: Ian
oyiptong: Michel and I met last
week to talk about gateway params, we need to talk about
server-side interactions
... We introduce the "gateway" into the network
relationships
(We look at diagram)
https://cloud.githubusercontent.com/assets/9365/26812915/8dcef2bc-4a2f-11e7-98c3-eea00ea5b178.png
scribe: 1. user requests a page
from the merchant
... 2. merchant responds with a page with PR API that specifies
gateway params
... we need a merchantId, a public key to encrypt data, a
gateway URL that the browser will invoke to send payload, and
finally an optional param "environment" for testing
... if user chooses a payment app that supports the gateway
payment method, the browser makes a request to the
gateway
... the request has a few params (merchantId, card data
(encrypted), environment)
... we don't want data sent in the clear
... the gateway then responds with a one-time use nonce
... subsequently, the browser generates an id that it stores
locally for subsequent uses
... the browser then sends data back to the merchant
... when the browser stores the ID it stores per
merchant-origin, per gateway, and per instrument
... the id is sent back to the merchant in the payment
response
... we also want a bank identification number so that merchants
can do routing
... the gateway nonce, the gateway URL (identifying the
gateway) and contact information for the user
... for sequent card uses, we can skip the gateway
communication.
... the payment request goes by without the nonce.
... if there are any errors, it should appear as though the PR
API has failed and the user should try again
IJ: Why is the browser doing things instead of the payment app (e.g., call out to the gateway and storage)?
oyiptong: We want this built into the browser. The payment method implementation would do this in a standardized way
ClintonA: In subsequent requests, merchant makes a request to the browser, browser sends an ID back...how does the merchant know which gateway the token is associated with (initially or subsequently)?
oyiptong: The payment response
includes a gateway identifier
... it's returned by the browser for subsequent uses as
well
ClintonA: If the relationship for
uniqueness is gateway/merchant/product, there's a scenario
which is that a cardholder for a particular merchant may be
able to select a card for the merchant. But there may be three
different gateways. The user simply selects the card..and the
merchant says "I want a token for this gateway"
... how does merchant say "I want token from his gateway"
oyiptong: Not part of this
proposal but we could do so.
... this proposal just shows one gateway Url but could be
expanded for multiple
... but ClintonA makes a good observation
... the spec could take an array
alyver: I'm still digesting this...I wanted to understand the gateway merchant identifier..it's the browser responsibility to store this?
oyiptong: Yes
alyver: I expect there to be
pushback on this.
... the list might be large...not sure if they want to store
data
... the nonces are typically single use and typically couldn't
be reused
oyiptong: Agreed nonce is for one-time use. The browser only needs to store the uniqueness key (merchant origin + card info + gateway id) + gateway URL to send back
alyver: Where is the tokenized card ID coming from?
oyiptong: Generated by the browser for subsequent use
<mweksler1> Browser == payment app
oyiptong: the merchant keeps
track of the ID, and when calling PR API subsequently, the
browser has it.
... When the user selects the payment method, the gateway
generates the token but does not send it to the client. When
the merchant gets the nonce, it uses the nonce to get the
token. The merchant and gateway communicate out of band for the
actual token
MANASH_MC: oyiptong, michel,
thanks a lot.
... a couple of things around encryption - who is responsible
for managing the encryption keys?
... just the browser?
<shift4sms> Payment app was mentioned. In my mind the browser and the payment app are one and the same - would this be correct?
oyiptong: We are using public
keys. It's a good point that I need to mention in the document
that the merchant/gateway have an understanding (and have
generated a key pair)
... the public key is used to encrypt the payload but the
gateway has the private key
MANASH_MC: Different scenarios -
card data stored in browser, in native wallet, or web-based
wallet
... native wallets will typically store tokens in hardware or
cloud
... web based wallets may store tokens..how will that
happen?
... e.g., can a gateway create a web-based wallet?
<shift4sms> Also, some discussion on a token to merchant back-channel of some sort - is this solution requiring a multi-use token or does this back-channel allow for single-use tokens?
MANASH_MC: How does this work
with existing custom payment methods?
... main point is to understand (1) who is responsible for
encryption and (2) how do gateway tokens work if gateway
distributes wallet?
ClintonA: When I look at the
subsequent request v. the initial request, I see that 11 and 12
for initial request is the request for the actual token. Is the
result of 12 a token or the actual PAN?
... if step 11 and 12 are beyond the scope of this payment
method
... why is it defined in the payment response
... I'm trying to figure out what exactly goes in 11 and 12 and
why is that not included in the subsequent requests?
oyiptong: 11 and 12 are indeed
server-to-server communication. It could also be a transaction
where the merchant could be charging the card at this
point.
... the response will be a token to be used subsequently
... as far as 13, the response, is concerned...the reason it is
after communication between merchant/gateway is that there
might be errors
... the user can try again in error cases
... in the diagram about subsequent use, there could be more
arrows to show communication between merchant and gateway
<ClintonA> ian your line is breaking up
ack oyiptong: I wanted to mention ... Michel mentioned that we could also make the payment app handle the tokenization
scribe: we could create a handler so that the handler is responsible for generating and storing the id
Ian: I think we should write the spec to make clear what happens...and then it doesn't matter whether it's the browser or some other payment app that's implementing
oyiptong: Ok
"...the browser will contact the gateway "
say instead: ....the payment contacts the gateway
scribe: and the payment app could be a browser
oyiptong: Ok
<alyver> +1 I think taking the approach of having Payment Apps being responsible for tokenization might be a good approach.
Shift4sms: Is this solution requiring a multi-use token or does this back-channel allow for single-use tokens?
steve: in our solution, single use is preferred
IJ: Am I understanding that at times gateways will say "don't store this for subsequent use". IS that a thing?
<shift4sms> Mostly correct. We certify based on single use or multi use and if both are certified, then the payment app can request which.
oyiptong: Yes. It could be the gateway OR the merchant
IJ: What does the spec say about that?
<Zakim> oyiptong, you wanted to comment on payment app handling
<shift4sms> yes
ClintonA: Perhaps "gateway" is
not the right word for "token provider"
... there are other types ... don't have a better term.
IJ: Token provider?
<oyiptong> +1
<MANASH_MC> +1
<shift4sms> +1
<alyver> +1
alyver: Circling back to payment
apps that tokenize....to play the devil's advocate...
... suppose we only have third party payment apps to implement
tokenization
IJ: I assume I would choose one from among all matching payment apps
ClintonA: What we are seeing with
these questions is that the merchant has to be able to indicate
how they expect to authorize the result of the payment
rqeust
... the parameter defines which gateway and whether they are
are using network tokens
IJ: Next steps...take a second pass?
oyiptong: We'll take feedback
(payment app v. browser, token provider, some steps
mentioned)
... and support for N gateways
... clarity around one-time use tokens
IJ: When can you update the wiki, Manash, with next draft of mission statement?
MANASH_MC: I want to do a tiny bit of research of 3DS as well and will have the wiki updated by next week.
IJ: Next steps?
roy: I was out for more than as
week. Am now back!
... we are planning to meet on Thursday after the main WPWG
call.
... I am available 8 June
(Regrets from IJ)
<MANASH_MC> +1 on 8th or 15th
Roy: 11am-noon ET Thursdays to start...will adjust as needed
PROPOSAL: 8 June, 11-noon ET
<oyiptong> +1
<Ken_> +1
<scribe> ACTION: Ian to send around a meeting announcement for a Thursday network tokenization call [recorded in http://www.w3.org/2017/06/06-wpwg-minutes.html#action01]
<trackbot> 'Ian' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., IFSF-EFT-WG-Lead, ijacobs, ijmad).
<mweksler1> 1
<mweksler1> +1
<Ken_> +1 Want to attend, but can't this week...to clarify
ClintonA: I will bring my comment to the network tokenization call
MANASH_MC: In the gateway session
last week, one pain point identified last week...gateway tokens
are basically not inteorperable
... Airbnb highlighted this.
oyiptong: the gateway proposal
has a standard way to get info from any token provider
... it becomes easier to handle
... the gateway to merchant backend communication is another
interop issue
Manash: Network tokens should be
reusable across gateways
... let's identify the user stories in the gateway section of
the mission page
Proposed: 20 June
<oyiptong> +1
<alyver> +1
