Tokenization Task Force

<scribe> Scribe: Ian

Agenda

Spec updates

https://w3c.github.io/webpayments-methods-tokenization/

https://w3c.github.io/webpayments-methods-tokenization/

===

- Merchant requests a cryptogram through backend integration (no browser involved)

https://bit.ly/2LPqTY6

- Merchant requests a cryptogram through same payment handler that requested original token:

https://bit.ly/2M3RqR6

- Merchant requests a cryptogram through any payment handler able to reach the TSP; in this

scenario the token requestor might be the merchant:

https://bit.ly/2n6xQ8F

[IJ walks through the flow diagrams]

IJ: What do people think about the direction of the tokenization spec?

stpeter: Not clear on the third flow.

IJ: Filtering

mweksler1: Regarding flow 2...it seems to be very optimized to be able to operate in a headless fashion
... the only UI referred to was the user pushes a button to use a card
... would it be possible in your thinking to skip that one, too?
... e.g., I have knowledge the user wants to use the card...don't bother the user.
... suppose it can be done in a compliant fashion.

https://w3c.github.io/payment-request/#user-protections-with-show-method

To help ensure that users do not inadvertently share sensitive credentials with an origin, this API requires that PaymentRequest's show() method be triggered by user activation (e.g., via a click or press).

stpeter: We also have a min display time in Firefox to ensure user sees sheet.
... I think we need to think through the security and trust model we have

mweksler1: What is the min time shown?

stpeter: right now it's 5 seconds.

<stpeter> mweksler1: see https://wiki.mozilla.org/Firefox/Features/Web_Payments/Privacy_%26_Security_Considerations#Information_Leakage

<scribe> ACTION: stpeter to review the tokenization spec

<trackbot> Created ACTION-102 - Review the tokenization spec [on Peter Saint-Andre - due 2018-08-21].

IJ: Scenario that drove flow three was "I don't have the same payment handler here."
... but flexibility may not be the right response. It might be "get the same payment handler"

mweksler1: Another option might be (e.g., for Airbnb) the merchant has the token obtained via Stripe...and suppose Stripe is down that day and we would want to go through Braintree. That is another use case behind flow 3.
... I think perhaps we should start with the simple use case here.

stpeter: Think I support mweksler1 that we might push 3 down the road

<Zakim> Ian, you wanted to mention PH API as part of the discussion

IJ: PH API is also not uniformly distributed

Issue 47

https://github.com/w3c/webpayments-methods-tokenization/issues/47

Q: What is the set of possible cryptogramTypes?

Rick: There is one really in the sense of being a true cryptogram
... that is put in a certain field and usually for 3ds
... different networks have different names for it but there is an EMVCO name

Dave: No observations right now re: cryptogram types

Issue 48

https://github.com/w3c/webpayments-methods-tokenization/issues/48

Q: How are empty supported* fields to be interpreted?

roy: These fields are optional, so what do you do when field is provided by empty?
... does it mean "support everything"?

https://w3c.github.io/payment-method-basic-card/

If types is empty and networks is empty, return true.

In tokenization:

8.2 Steps to check if an instrument is supported

If types is empty and networks is empty, return true.

Ian: I need to speak to cryptograms

<scribe> ACTION: Ian to follow up on issue 48 with pointing to algorithms and possibly fixing algos

<trackbot> 'Ian' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., IFSF-EFT-WG-Lead, ijacobs).

[roy leaves]

TPAC

https://github.com/w3c/webpayments/wiki/FTF-Oct2018

for tokenization (30 minutes)

"Tokenization. Spec updates. Facebook demo (Roy)"

scribe: also thinking breakout session for deeper dive.
... what would people like to get out of the TPAC meeting?

stpeter: It would be helpful before then for enough people with greater expertise on the network side of things to have reviewed the work done in the spec

IJ: Would be helpful to prepare any questions specific to browser vendors for TPAC.
... Who is going to implement this payment method?
... the browser vendors will listen more if we can answer the question

Rick: In the case of dynamic transactions, what benefits would there be to being a payment handler.
... there are some benefits to branding visibility (e.g., *Pay)
... we need to emphasize benefits for the payment handler/browser role (flows 2 and 3 of card on file use case)

IJ: Anybody want to lead the deep dive conversation?

Rick: If I can go, I would love to.

Next meeting

28 August