Payment Apps Task Force

05 Oct 2016


See also: IRC log


Ian, Tommy, Pascal, adamR, jnormore, AdrianHB



IJ: What mechanisms do we need for trust in web-based payment apps?
... e.g., whitelists?

adamR: What are the attacks we are worried about? I think many of them are addressed by the web platform directly.
... I would not put more protections around them except where the platform does not already support them.

<jnormore> +1 not the browsers place

adamR: I don't think the browser should play a role in the ecosystem that involves whitelists
... the prospect of consistent white lists across browsers would be near impossible (hard already with certs) and that would make web-based payment apps DOA.
... and if we enable the merchant to do whitelists, then we've made payment method concept obsolete.
... so -1 to whitelisting by browser/merchant

jnormore: My biggest concern as a merchant representative is trust between payment service and merchant. Browser has no place determining what customer can use and what merchant can offer.
... but I do think that the merchant should be able to express which apps it prefers.
... I do know merchants who would go further and want to restrict apps that users can use

adamR: Can you speak more about trust concerns from payment requestors?

jnormore: I think the most important concern is "what the user experiences"

IJ: One point AHB made was that if browsers curate in some fashion, that users be able to override browser warnings (cf certificates)
... What lessons have been learned from plug-ins, for example, that we might anticipate here?

adamR: Plug-ins and add-ons...not sure we can learn a lot there. Add-ons largely had free run of the browser...the Web is moving away from both of those models.
... both Mozilla and google are deprecating npapi.
... we are moving in the direction of web extensions
... all of that said, what is being proposed for web based payment apps is taking this even further
... all you can do with a web application are things you can do on the web....
... they can only operate in the scope they are allowed to
... we are only adding two small things for payments: (1) being pulled up for a match and (2) thin amount of communication
... I don't think the latter changes the security properties.

IJ: Any other mechanisms necessary re: user experience?

adamR: I am sympathetic to that concern...but we should also not support a "best viewed with" perspective

jnormore: As long as the merchant has some ability to push recommendations to the customer, I think that addresses the problem

native app integration experience

See Rouslan document -. https://docs.google.com/document/d/1izV4uC-tiRJG3JLooqY3YRLU22tYOsLTNq0P_InPJeE/edit?usp=sharing


(Payment options)

Proposed: Version has app-level granularity in the mediator.

<jnormore> +1

<TommyT> +1

adamR: I think what we have in the payment app spec supports payment options...there's a mechanism to display that and give info of which was selected back to the payment app.
... I think this adds almost no complexity and allows significantly better user experience.

IJ: Please say more about why you support removal.

TommyT: I'm happy with keeping things simple in v1...if it turns out it's not a lot of complexity, I'm not against keeping it in.

jnormore: I also want to keep things simple. I think there is complexity about what is shared with whom.

IJ: Can we design in a way that browsers MAY use this.

adamR: The way I put the text together is there is an ID for each option. When the payment app gets control, it gets the ID of the selected option
... if you want the browser to be able to render options or just the app, then
... we make the ID nullable; if it shows up as null then the payment app would be required to figure out which option to user, probably by querying the user.
... the one last thing I want to say on this is that we (mozilla) have been speaking to payment providers and they seem awfully hung up on being able to represent some card art.
... this seems to be a high order priority for them
... so given that priority + low complexity I would be inclined to keep
... Having it be "optional" makes this more complex (for app providers)

AdrianHB: Right, app providers have to handle both cases (ID present or not)

jnormore: There's an implication here of registration (IDs for options)
... would this still work when there is not registration?

adamR: I don't yet understand how unregistered payment apps work (and how they communicate payment methods and payment options)...once we figure that out it should be straightforward to communicate option information
... what I envision we will probably have is an ephemeral registration - same information is communicated but that data is subsequently forgotten

IJ: +1 to ephemeral registration model

<jnormore> +1

IJ: I would like to add a note in the spec that unregistered apps would communicate in the same was (and same data) as registered payment apps; just the data is forgotten

<scribe> ACTION: jnormore to write up this point on ephemeral exchange of data for unregistered payment apps [recorded in http://www.w3.org/2016/10/05-apps-minutes.html#action01]

IJ: I am hearing more people prefer keeping payment options for now

<scribe> ACTION: Ian will restore payment options [recorded in http://www.w3.org/2016/10/05-apps-minutes.html#action02]

AdrianHB: We'll want to circle back with Rouslan

getting to FPWD

IJ: Shane has done reviews
... awaiting reviews from zach + Max


* Get reviews from zach, max

* Make edits and resolve other issues to the extent we can

* Either week to review + CFC / or / CFC directly here

<Zakim> AdrianHB, you wanted to ask about implementors

AdrianHB: I wanted to note a few conversations I've had in Lisbon and find out from Adam and Tommy what the plan is for implementation of the payment app spec.
... I think some folks thing of web based payment apps as a desktop phenomenon
... so for some vendors there may not be web-based payment apps in the near term.
... Mozilla / Opera / Samsung are best candidates for implementation right now

adamR: I am not in position to give a timeline right now...when we implement PR API my expectation is we will implement payment app API in parallel

TommyT: We are very interested in web based payment apps
... also native apps
... the only thing that has kept us from doing a proper integration is the state of the spec

(Hey!!!!! :( ;)

<AdrianHB> +1 - we also need interest from app publishers to publish web-based apps

IJ: I have been talking with some companies about web-based payment apps

jnormore: We are interested from the merchant perspective AND from the payment provider perspective in web-based payment apps
... regarding web-based payment apps and desktop, I disagree....I think it's EVEN MORE important on mobile
... that web-based payment apps be considered a mobile offering as well

<AdrianHB> Great!

IJ: I have also heard that having web-based on mobile will be useful (e.g., convenience stores + digital offers)
... My thought is that implementation experience will pick up (I hope) after FPWD

Detecting if payment app available

Mahesh proposal -> https://github.com/maheshkk/webpayments/wiki/Detecting-if-payment-app-is-available

<Zakim> AdrianHB, you wanted to discuss Mahesh's proposal

(We will leave it for tomorrow's conversation)

AdrianHB: I think that one CAN do what Mahesh wants through hacky methods and we can't prevent; so making it cleaner is appealing

Getting PR API to CR

AdrianHB: I think app implementation experience (both native and web) will give confidence in shape of PR API

adamR: I look forward to hearing back from Zach

AdrianHB: I think that integration of some push-based payment methods is valuable right now (re: shape of PR API)

Next meeting

12 October

Summary of Action Items

[NEW] ACTION: Ian will restore payment options [recorded in http://www.w3.org/2016/10/05-apps-minutes.html#action02]
[NEW] ACTION: jnormore to write up this point on ephemeral exchange of data for unregistered payment apps [recorded in http://www.w3.org/2016/10/05-apps-minutes.html#action01]

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.144 (CVS log)
$Date: 2016/10/05 14:00:59 $