W3C

Web Payments Working Group Teleconference

09 Feb 2017

Agenda

See also: IRC log

Attendees

Present
oyiptong, Ian, adamR, adrianhb, nicktr, zkoch, dezell, Molly, Ken, max, alyver
Regrets
Rouslan
Chair
AdrianHB
Scribe
Ian

Contents

  1. PMIs
  2. Payment Method Manifest Specification
  3. Test suite check in
  4. Meetings
  5. PAG update
  6. next meeting

PMIs

https://github.com/w3c/webpayments-method-identifiers/pull/21/

AdrianHB: Have some draft text. But Ian and I were not in agreement on one point and want to ask the group

Question: When a PMI URL is malformed (i.e., has a query string or fragment id), should the user agent throw it out and not match at all, or simply throw out the query string and fragment id but consider the URL for matching?

(The pull request basically says "Keep the URL but throw out the offending parts")

(Ian had thought we had decided "Throw out the URL")

zkoch: Unrealistic to expect implementations to strip out bits. Prefer "throw out the URL"

AdrianHB: That is what Rouslan said at the last call

<zkoch> Note: Rouslan sends regrets, is caught in snowstorm

<oyiptong> in favor of zkoch's suggestion

<dezell> +1

PROPOSED: Throw out malformed URLs for matching

<adamR> Sounds okay to me.

so RESOLVED

<nicktr> makes sense to me +1

AdrianHB: I will update the PR

Payment Method Manifest Specification

zkoch: Max and I met last week. Max is working on defining the link header parts.
... I am working on the structure of the manifest file
... we've decided we're going to use the current web app manifest spec for inspiration
... I also reached out to Marcos re: reuse of web app manifest
... and sent to Molly as well
... I have asked Marcos for feedback before end of week

adrianhb: I think that we may not be able to reuse web app manifest for some of the tasks we have in mind for a payment method manifest file
... I think it will be a simple file

zkoch: I tend to agree; but hope we get this resolved quickly

<AdrianHB> ian: the apss TF is having debates about the granularity of choices to present a user

a) One container and that's it

b) One container with different walls

c) N containers with N instruments

<zkoch> o.O

<AdrianHB> ian: we had envisioned that the user would see options with something they recognise (like the last 4 digits of their card) to save some clicks

<adamR> zkoch: Option c) looks like https://dl.dropboxusercontent.com/u/53717247/amex.png

<AdrianHB> ... what granularity is being provided in native?

zkoch: there are two questions (1) what is our objection and (2) what are we doing
... I suppose that if other implementers want to do this, I wouldn't oppose. But we think that there are sufficient problems with instrument-level information..it can be overwhelming to the user, you need to figure out how to identify strings in a consistent manner across apps, you have a deduplication problems (same card in multiple apps)
... and are unhappy in general with instrumental level UX

<AdrianHB> deduplication is a valid concern!

zkoch: there are a few other things as well...we found these to be hard challenges
... today you just see "Android Pay" as an option
... when you click you open Android Pay and choose an instrument, do authentication, etc.
... so we don't do any line-time support
... the same flow should work for 3rd party payment apps

<nicktr> adam?

adamR: I am sensitive to the point that Zach is talking about re; user experience.
... but I want to put forth the countervailing force - the amount of friction to go through a flow increases dramatically with each click the user must perform.
... the prospect that they are choosing an app and then an instrument in the app doesn't do the user or merchant any favors
... we had previously discussed registering these things and then leaving to the browser whether to render them to the user, or render the app-level
... so we wanted to enable a single click flow if user agent wants to

adrianHB: I heard zach not objecting to having the info available, and simply google choosing not to implement.

adamr: Note that the desktop experience may be different

IJ: The spec currently says "UA must render options"

<AdrianHB> ian: spec currently says UA must render options. I hear us saying this is not a normative req on UAs

<zkoch> +1 to no “must” language on this :)

<AdrianHB> ... any thoughts from other implementors?

Molly: I need to think about it

<Zakim> Ian, you wanted to ask MS and Opera and Mozilla

<Zakim> AdrianHB, you wanted to point out spec complexity that we could avoid by putting this off to a v2

<AdrianHB> https://dl.dropboxusercontent.com/u/53717247/amex.png

AdrianHB: There is still the question of "app container walls' (esp for 2 apps from same origin)
... Another thing I wanted to raise...there's a lot of complexity and debate in the apps task force about how to support this
... and how this set of data that needs to be loaded into the browser needs to be tied back to composable parts of a web app
... we have security and app boundaries to worry about

<adamR> To be clear, this is showing a single origin, and therefore a single “web app” the way that term is used.

<adamR> Not two apps

<adamR> AdrianHB: ^^^

zkoch: Two quick thoughts - as I look at the image...I think there are two points of subtlety
... there are three total instruments
... there is a difference between instrument selection and "Giving users more insight as to what they will find in the app"
... so seeing not the same as clicking
... perhaps that would improve experience without complexity.
... +1 to going with "payment app level" for now and then revisiting if deemed insufficient

<AdrianHB> ian: helpful feedback

<AdrianHB> ... TF should put proposal to WG

<AdrianHB> ... but if there is enough info now then a strawpoll may be useful to give the Tf input

<zkoch> No :)

IJ: Do you expose instruments in native?

<AdrianHB> ... useful input from zkoch

zkoch: No

<nicktr> thinks that the schemes would probably have a strong view particularly given the link up between Masterpass and Visa Checkout

<Zakim> Ian, you wanted to make a point of order

<zkoch> nicktr: can you expound?

adamR: Important to think about mobile v desktop. I think that on mobile, app-level presentation makes a lot of sense.
... I would be concerned to be glossing over the other experiences

<zkoch> We also have a desktop implementation designed in almost implemented, so I think our thoughts come from that experience as well. But I agree there’s a risk of oversimplification

<nicktr> @zach - Mastercard and Visa have agree that they can put each other's tokens in each other's wallets

<nicktr> http://uk.businessinsider.com/unpacking-visa-and-mastercards-tokenization-deal-2016-12?r=US&IR=T

<adamR> Or to re-use a commonly employed IETF phrase: “Let’s make it as simple as possible, but no simpler.”

AdrianHB: I am hearing a feeling a concept the the specs should support options but not require impelmentation of them

AdamR: I think the spec should support this but agree it should not be required to be implemented by UAs (notably for mobile)

<nicktr> +1 to adamR's position - allow/support but don't mandate the display

Test suite check in

<AdrianHB> ian: meeting this week

http://www.w3.org/2017/02/09-wpwg-minutes.html

<AdrianHB> ... stan and roy joined and have stepped up and volunteered to help

<adamR> To be clear, I think the best way to think about this is as a “graceful degradation” scenario. Put another way: let’s say v1 didn’t support this functionatliy, but v2 did. We would still have to support v1 apps that didn’t register this, and they would have to deal with v1 browsers that didn’t display sub-options. If that’s a tenable state of affiars, I’d like to just go ahead and jump to that state right out of the gate.

<AdrianHB> ... resource constraints have held us back to daye

<AdrianHB> ... roy investigating if Facebook impl could be used for testing

<AdrianHB> ... and also if Fb has tests that it can contribute

<AdrianHB> ... currently tests are only run against Chrome on Android

Questions:

1) Anyone have PR API implementations available for testing?

2) Anyone have tests for those implementations

3) Anyone else want to participate in the testing effort?

<AdrianHB> ian: important to have tests at the end of CR

<AdrianHB> ... WG said in Lisbon that we wanted a good test suite pre CR

<AdrianHB> roy: we have an impl and were able to run the test suite against it

<AdrianHB> ... how do we "provide the impl back"

<AdrianHB> ...?

<AdrianHB> ian: part of that q is "how do we run tests". Normally we just point a browser at some code (tests) and see what happens.

<AdrianHB> ... some can be automated but some require manual intervention

<AdrianHB> roy: do we need to have a publicly accessible release or can we run tests internally and share results

<AdrianHB> ian: for the purposes of building out the suite there doesn't need to be a publicly available impl

<AdrianHB> ... historically the director has evaluated private impl as part of the process

<AdrianHB> ... there is also precedent of test suite results only being shown to W3C staff

IJ: I think you can get the test suite, run tests, check back new tests to the repo

<AdrianHB> ... so there is a process req and but that doesn't impact what we do to build the suite

Ian: Let me know if you have tests or want to help!

adrianhb: end-to-end integration testing could be complex, so help welcome

Meetings

next FTF meeting

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

(Currently about 30 people)

<nicktr> I would like to give an update on the EMVco work if I can a) get that update and b) get permission to communicate it. I am working on getting both

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

<nicktr> I would love to see demos

AdrianHB: People ok looking at demos?

[No objections]

PAG update

IJ: We have a draft report
... expect the PAG to review the report, then take to the Director

next meeting

16 Feb


Minutes formatted by David Booth's scribe.perl version 1.148 (CVS log)
$Date: 2017/02/20 17:16:53 $