Web Payments WG

14 Nov 2019



Ian Jacobs (W3C), Chris Dee (Worldpay), Dean Ezra (Barclays), Matt Lockyer (Worldpay), Peter St Andre (Mozilla), Kacie Paine (MAG), Rob Martin (Capital One), Justin Toupin (Google), Danyao Wang (Google), Florent Lambert (Lyra), Alex Liu (Airbnb), Nick Telford-Reed, David Benoit (Reach), Adrian Hope-Bailie (Coil), Rouslan Solomakhin (Google)
Adrian Hope-Bailie



<scribe> scribe: Ian

Outcome of the Call for Consensus to advance the charter to the AC

AdrianHB: We sent out a call for consensus; got feedback on charter; we incorporated changes and there were no objections
... we recorded consensus to advance this to the AC

Note about AC review has started

<AdrianHB> Review started today

<AdrianHB> We may get feedback which we need to take into account

<AdrianHB> If you're not an AC rep please ask yours to respond

FTF meeting dates

AdrianHB: We are confirmed for 30-31 March in Dublin, hosted by Airbnb
... we are still looking at having 2 more days afterwards to do coding of user experiences
... and potentially a 1 April meeting of the WPSIG

IJ: Please pencil in for now

IJ: I suggest waiting a few days to finalize travel plans until we have confirmation of 1-2 April meeting

<scribe> ACTION: Ian to send a separate email to the list with confirmed face-to-face meeting dates.


AdrianHB: We had some early discussions about the idea to bring together developers and browser vendors to code for 2 days
... to build user experiences, understand challenges
... looking for merchants, payment service providers, browser vendors
...example: when we've talked about handling "card on file" use case of Airbnb...how could we handle that? Building a POC, for example, of a merchant payment handler, would be interesting
... we had thought about US Bay Area in January but that's not going to work out, so now we are looking at 1-2 April

IJ: Stay tuned for more on that as well

Two pull requests to review

Danyao: The first pull request is "Allow incremental request of billing and shipping address"


scribe: this is an improvement based on previous privacy feedback about oversharing address information
... some parties have indicated that they want less than full address ifnormation.
... this pull request amends the current PR API
... instead of passing a boolean, the merchant can pass in a list of fields and then the merchant gets back only those parts
... and merchants can incrementally request that information.
... many thanks to Marcos for helping in the design
... to help us understand as browser vendors how to prioritize this, we'd like to hear from merchants and others
... how important is this feature to you?
... please comment on the pull request on GitHub
... if we don't hear from you, we'll not prioritize it in the short term

The second pull request is "Add requestSecurityCode member to BasicCardRequest"


Danyao: This relates to Basic Card payment method. Today browser typically prompts the user for the CVV. This boolean instructs the browser NOT to collect the CVV (to reduce prompting the user)
... we want to hear from merchants how important this is.

IJ: Please provide feedback to us on GitHub in support of this proposal

<nicktr> no longer at Worldpay but think this is a valuable addition

<nicktr> so +1 from me

Modal Window discussion

<Chris_Dee> +1 from me too - the more control the better

AdrianHB: To summarize the modal window discussion

<nicktr> AdrianHB has written a great explainer here https://github.com/adrianhopebailie/modal-window/blob/master/explainer.md

AdrianHB: at TPAC we had some discussion about modal window idea -- generalize the modal window so that it's not limited to payment handlers
... we thought there would be more use cases for this UX such as single sign-on and cross-origin sign-on
... goal is to enable the browser to invoke a modal window that has a first party context that is not the same origin as the site the user is visiting (e.g., the merchant site)
... generally cross-origin interactions are locked down.
... typically redirects are used today to get the user to another origin
... that is not a great user experience. And often returning to the original origin breaks and so the UX is even worse.
... so the idea here is a new Web platform feature to enable the second origin to invoke a modal window.
... Rouslan has, in the explainer, given an example of a cross-origin password manager. This can be hacked via PH API, but we don't want that, hence the interest in generalizing.
... the big challenges here is how to do this in a privacy-protecting way
... e.g., whether it makes sense to show a first party context over another one, or whether it should be closer to iframes (which are third party contexts)
... and is there a risk of "training users" incorrectly around security.
... if we can make some progress on this, it would help us generally and also more specifically potentially increase support for payment handlers in browsers

<Zakim> danyao, you wanted to talk about modal window skunk works

<AdrianHB> +1 on test for non-payment use cases

Danyao: Chrome is interested in partnering with someone to prototype this to solve a use case. We have a hypothesis that this could be useful for several use cases, but we need some additional confirmation from developers that this could be a reasonable solution.
... we could prototype flows using PH API (just for prototyping!)
... I'd like to see some experimentation
... I think the TAG is looking for concrete use cases; having skunkworks prototype would help move this work forward.
... e.g., Stripe demo in their 3DS flow

<nicktr> ian: payment handler API is at one end of the spectrum of chattiness, whereas the explainer is at the other (very chatty) side of the spectrum.

<nicktr> ...this allows the browser to do less

<nicktr> ...and allows more use cases

<danyao> The same privacy issue is being discussed here in the context of PaymentRequestEvent.openWindow() as well: https://github.com/w3c/payment-handler/issues/351

<danyao> +1 to staying closer to known use cases initially

<nicktr> ian: but it opens the door for lots of cross-origin communication which might mean security concerns

<nicktr> ...is it possible that there's a middle ground?

<nicktr> ian: please take this into account when reviewing

<nicktr> ...and please give us your use cases

Request to add troy to list of approved card network identifiers

list of network identifiers


<nicktr> notes that we already support some local schemes like cartebancaire and mir

<AdrianHB> +1 stpeter (or deprecate basic-card :P)

<nicktr> +1000 to deprecating basic-card

PROPOSAL: Add "troy" to the approved list of card network identifiers

[Cartes Bancaire gave a +1]

Chris_Dee: It may not be as simple as we think.

[IJ reviews the history of card types]


IJ: For historical context: we discussed this previously and chose to keep things simple. We also considered then dropped the card type

<Zakim> nicktr, you wanted to ask browser vendors about their position

NickTR: Quick question regarding the addition of this identifier....what is the implication for browser vendors?
... usually there is a small coding effort
... is Google cool with adding a new network identifier?

Justin: There are two angles: (1) conceptual angle (2) Practical angle about implementation
... for the second one I want to call out a couple of things:

a) Chrome is focused on making web based third party payment handlers a great experience

b) Autofill would have to support this network

scribe: so this might not be a high priority

"Appearance in this list is not a guarantee that a particular browser or other user agent recognizes the identifier as a supportedNetwork. "

stpeter: +1 to what Justin said: Basic Card is not a high priority, but I see no harm to adding troy to the list.


IJ: We might use the list for SRC

stpeter: No objections

PROPOSED: To add "troy" to the list of approved card network identifiers

<AdrianHB> +1

<rouslan> +0

<Chris_Dee> +0

<Matt> +0

<nicktr> +0

<danyao> +0

<stpeter> +1

RESOLUTION: To add troy to the list.

<scribe> ACTION: Ian to update the list of card identifiers and refine the process description

Upcoming meeting schedule

Next call: 12 December

No calls on 28 Nov, 26 Dec

<nicktr> +1 to seeing updated demos

Summary of Action Items

[NEW] ACTION: Ian to send a separate email to the list with confirmed face-to-face meeting dates.
[NEW] ACTION: Ian to update the list of card identifiers and refine the process description

Summary of Resolutions

  1. To add troy to the list.
[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2019/11/14 15:56:39 $