See also: IRC log
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
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
IJ: Shane has done reviews
... awaiting reviews from zach + Max
Plan:
* 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
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
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)
12 October