See also: IRC log
https://github.com/w3c/webpayments-methods-tokenization/wiki/encrypted_card
Olivier: I updated some
terminology
... from Vault Provider to Key Provider
... I added some descriptions to encryption mechanisms
<oyiptong> https://user-images.githubusercontent.com/9365/30331535-f15110d6-978c-11e7-8ed0-a5aaa28547d6.png
Olivier: the encryption exchange
is either done right after the browser hands control to the
payment handler, who contacts the key provider
... or there's an option (3) where the payment method data
includes the information necessary to generate the encrypted
card data
... that would be given via the parameters (shown in IDL)
Olivier: and this data would plug
into the Web Crypto API
... the idea is that the merchant provides the key and algo
information up front, but cannot decrypt the payload, and a key
provider is in the loop later
... so that merchant page is outside PCI-DSS scope
alyver: Question on the three
methods - from my experience #3 is the more common use
case
... when I think of Android pay, for example, #3 is how it's
done
oyiptong: I think #3 is the best way to do this; it's easy
IJ: So have you been socializing this? Is it interesting?
oyiptong: From what I've
understood, there is interest. E.g., option #3 is desirable for
small merchants. It's simple and low-cost to implement.
... we've also spoken with a payment processor who expressed
interest.
IJ: Oliiver, what feedback would you most like?
oyiptong: Viability (e.g., from
processor POV)
... also feedback from merchants on the PCI DSS scope
reduction
... also whether the payment method data declaration makes
sense
... and also from traditional payment gateways on whether
valuable.
<scribe> ACTION: Chris to review the proposal and send comments. [recorded in http://www.w3.org/2017/09/19-wpwg-minutes.html#action01]
<trackbot> Created ACTION-66 - Review the proposal and send comments. [on Chris Marconi - due 2017-09-26].
IJ: You can use the issues list
oyiptong: One thing I want to clarify - the tokenization extension use case is only an EXAMPLE of an extension.
IJ: Please clarify the two parts
oyiptong: First part is proposal
to encrypt card data (stops after "discussion" section).
... the next part is called "tokenization extension use case"
... which is there for discussion but should not be considered
part of the "encryption" part of the proposal (part 1).
IJ: How long for your review, Chris?
Chris: End of this week
IJ: Postponed until early October
https://lists.w3.org/Archives/Public/public-payments-wg/2017Sep/0032.html
IJ: Any initial thoughts on the idea of an indirection through the gateway to avoid exposing PAN?
====
1) The handler sends the card details of a secure connection to
the gateway (using a URL provided in the payment request) and
gets back a reference of some kind which it passes to the
merchant in the PaymentResponse.
2) The merchant then submits the payment to the gateway with the
reference instead of the card details and also all of the other
contextual data that the gateway requires. The gateway would then
use the reference to loo kup the card details it has in temporary
storage and process the payment.
This is subtly different in that the reference would be a single
use value for a set amount. The gateway may also provide the
merchant with a customer identifier that is consistent across
multiple uses of the same card to assist the merchant with
customer engagement.
====
oyiptong: Payment method request
data includes a URL, payment handler communicates with that
URL, passes a ref back to the merchant.
... sounds similar to the tokenization flow
... to the tokenization extension use case.
... minus the encryption part
https://w3c.github.io/webpayments-methods-tokenization/index.html
<oyiptong> https://user-images.githubusercontent.com/9365/28303430-031ea6c8-6b48-11e7-8d41-f7558ddd76db.png
oyiptong: In that diagram, after
the browser hands over control, the payment handler contacts a
service (here, a gateway)
... sends the PAN and gets back a reference. (Originally it was
a token; AHB's proposal suggests that it's a reference possibly
of another type)
alyver: This seems to be the same as the gateway tokenization flow we discussed before, as oyiptong pointed out.
IJ: There was not support for gateway proposal due to gateways not stepping up to do payment handlers. I'm not sure why this proposal is different.
alyver: There might be an opportunity to define a standard for what data is sent to the gateway
(IJ thinks Olivier had something like that in the gateway proposal)
scribe: I also think the browser could act as a payment handler here, and not integrate with N providers; just integrating with one API.
Keyur: We are having some
discussions, and trying to implement in a real-life
scenario
... merchant can get a token and process it (or their PSP
can)
... right now we are looking at whether to use test system or
production site for demo
... right now we are using a custom payment method spec; we
would break it back to the task force for discussion
https://github.com/w3c/webpayments/wiki/FTF-Nov2017
IJ: What should we present?
oyiptong: I would like to present
encrypted card ... Browser implementation would be very
interesting (autofill)
... it would be great to get supporting statements
IJ: what is strategy for securing supporting statements?
oyiptong: Identify
stakeholders
... we can also ask browsers what would convince them (then get
those statements)
IJ: What about code to show demo or ease of use by merchant?
oyiptong: I can implement a shim
<scribe> ACTION: Olivier to implement some example code to show how it works [recorded in http://www.w3.org/2017/09/19-wpwg-minutes.html#action02]
<trackbot> 'Olivier' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., omaas, oyiptong).
Tuesday, 3 October
<oyiptong> +1
