<scribe> scribe: Ian
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
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
Danyao: The first pull request is "Allow incremental request of billing and shipping address"
https://github.com/w3c/payment-request/pull/873
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"
https://github.com/w3c/payment-method-basic-card/pull/78
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
<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
https://www.w3.org/2017/03/09-wpwg-minutes
<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]
https://www.w3.org/TR/payment-method-basic-card/
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.
https://github.com/w3c/src/wiki
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
Next call: 12 December
No calls on 28 Nov, 26 Dec
<nicktr> +1 to seeing updated demos