See also: IRC log
https://github.com/w3c/webpayments-methods-tokenization/wiki/gateway_params
(Changed recently!)
oyiptong: mweksler and I worked
on the text a bit and we'd like to share it
... we took previous feedback into account
... updated the diagram
... e.g., moved from "browser" to "payment handler"
... at step 7 the response from the tokenization response
provider says its an instrument token
... the order of operations remained roughly unchanged
... now says clearly that comms between tokenization provider
and merchant is outside of the scope of the spec
... in the diagram, shown in a box
... also added a diagram for a use case where tokenization
provider is different from payment processor
... there's an example flow showing how spec would work in this
case
... I also added an "optional feature" -> oneTimeUse boolean
in the request
... Optionally, the merchant could provide a oneTimeUse
parameter, which signals to the payment app that this payment
method is not to be saved for subsequent use.
... in the response the server can override the
preferences
... how the client handles the onetimeuse request is to not
store the ID
Keyur: On subsequent card usage if a onetime use token, it will still ask the token provider to generate a new token?
oyipton: Yes
Use case: Nonce passing
scribe: tokenization provider
passes back a nonce
... the payment handler sends payload, including nonce, back to
the merchant
... the merchant will know how to handle it due to out-of-band
agreement with tokenizer and merchant
Use case:
Use case:
Direct Token Passing
scribe: in this case, actual token is sent
This behavior is entirely up to the merchant and the token provider. A token-provider-merchant-identifier is still generated and the token is never stored on disk by the Payment Handler.
This saves one roundtrip by the merchant to the token provider, at the cost of security, but gaining in convenience.
scribe: this satisfies a request on GitHub from Keyur
Keyur: Also ties into the EMVCo
tokenization..t.hat's what I was trying to go towards
... I am still looking at your request/response to accommodate
EMVCo tokenization
... which would mean there is only one gateway + EMV
tokenization spec
Use case: Token Providers and Payment Processors are two different entities
scribe: in short - this is possible but out of scope for the spec
Keyur: Are we saying that the tokenization provider URL is the identifier for the tokenization provider
IJ: tokenProviderURL is serving two purposes - matching and contacting?
oyiptong: Yes
IJ: Should direct and nonce use
cases be moved up?
... or a link to "more use cases" after first diagram
oyiptong: +1
IJ: Any pending edits from oyiptong / michel?
Keyur: How do we perform 3DS as a
step-up?
... are we saying that once we go back to merchant page where
merchant can do 3DS based on processor capability?
https://github.com/w3c/webpayments-methods-tokenization/wiki
scribe: in the case of network
tokens, it's already taken into account to pass auth data which
is passed to the network
... but for gateway tokens, ultimately what travels through
payment processor is FPAN...and there is no auth data.
... 3DS is the only way right not to perform additional
authentication....3DS 2.0 could be interesting
... allows in-app step-up auth
... this is a "v2" sort of thing by the way
... my first statement is that when I go back to the merchant
page after providing information (token or nonce)...in that
case the merchant can, today, do 3DS...but it's out of scope
for the W3C APIs
... so the merchant is free to perform step -up (but out of
scope for W3C0
oyiptong: We could also discuss
what the burden is on the merchant to display the information
properly
... what would it look like, e.g., for same card to be
presented multiple times.
https://github.com/w3c/webpayments-methods-tokenization/issues
IJ: Any updates from recent conversation?
keyur: Work in progress...we are
likely to add some params to gateway spec for network
tokens
... so hopefully by this weekend.
IJ: Where will edits happen?
Keyur: I would create a separate page to noodle on network tokens, then merge later in single tokenization spec.
https://github.com/w3c/webpayments-methods-tokenization/wiki/network_params
For questions while I am unavailable, contacting Mike Smith <mike@w3.org>
or Philippe Le Hegaret <plh@w3.org>
<oyiptong> filed an issue: Payment Method declaration may show duplicate card descriptions https://github.com/w3c/webpayments-methods-tokenization/issues/9
thanks!
oyiptong: Can we close with gateway params update?
Keyur: yes
RESOLUTION: Close issue 8
Clinton: Can use IIN and BIN
<alyver> Less formal, but BIN is more common
IIN is managed by ANSI, BIN is less formal
oyiptong: Are you saying, Keyur, token provider should route?
<clintona> I said ANSI.. ment ISO
Keyur: Let's keep it out until we have a use case where merchant needs BIN
<scribe> ACTION: oyiptong will raise an issue about whether BIN is required (or something similar) in response. [recorded in http://www.w3.org/2017/06/20-wpwg-minutes.html#action01]
<trackbot> Created ACTION-61 - Will raise an issue about whether bin is required (or something similar) in response. [on Olivier Yiptong - due 2017-06-27].
https://github.com/w3c/webpayments-methods-tokenization/issues/5
<oyiptong> issue for ACTION-61 https://github.com/w3c/webpayments-methods-tokenization/issues/10
IJ: Please look at issue 5, Keyur
Proposed 11 July
<oyiptong> +1
SO RESOLVED