See also: IRC log
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
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
<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
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]
IJ: We have a draft report
... expect the PAG to review the report, then take to the
Director
16 Feb
