Re: [Agenda] 7 Feb 2017 Payment Apps task force call

On February 7, 2017 at 9:08:30 AM, Ian Jacobs ( wrote:
> > As an implementer, I want developers to have the same capabilities as a native payment
> handler has.
> >
> > As an implementer, I want to end up with the same internal and external facing API for
> implementing payment apps (security and privacy allowing). See Fetch API as an excellent
> example: we use the same API both internally in Gecko and expose it to web developers.
> We should aim for something like that.
> There are a number of pieces here and I’m not sure I’ll do all of them justice:
> - Regarding whether we can circulate the same information related to canMakePayment()
> compared to Apple Pay (and similar) maybe, except that we don’t have consensus to do so.

Consensus on merchant validation or any data validation is somewhat
irrelevant. And here is why: The question that we need consensus on
here is, can the equivalent of calling `request.canMakePayment()` in a
native payment handler (Android Pay, Apple Pay, Microsoft Wallet,
Whatever Pay):

 * perform a network request?
 * check access to a device (e.g., NFC, BlueTooth)?
 * check details in a database (e.g., IDB).

If the answer to *all* of the above is "no". Then my argument is null and void.

However, Apple's canMakePaymentsWithActiveCard() method [1], on which
our `canMakePayment()` was modeled:

"This method asynchronously contacts the Apple Pay servers as part of
the verification process. It can only be used to check Apple Pay’s
availability before defaulting to Apple Pay during your checkout flow,
or before adding an Apple Pay button to your product detail page. In
all other situations, use canMakePayments instead."

The details of what Apple does with canMakePaymentsWithActiveCard() to
perform the network request are irrelevant for the sake of the
argument - though they are bolstered by the fact that these are fetch
requests over HTTPS. The only thing that matters is that "This method
asynchronously contacts ... servers."

It doesn't take much imagination to come up with a case where one
would need to check for the availability and presence of certain
hardware to perform a payment - independently of the actual payment
method (i.e., "is the NFC-SuperPay-Thingy near by?" and *not* "Is the
NFC-SuperPay-Thingy nearby attached AND can the user pay with Amex?").


> - canMakePayment() is designed to to return true if there is support for at least one merchant-accepted
> payment method. Its functionality is intentionally
> limited for privacy reasons.

What is being proposed doesn't make things less private?

> - That is still different from the payment method matching that happens in section 3.2
> show(). I believe that is where the Payment Apps Task force
> has been focused: when the user agent is determining which apps to show, it would first
> compute the intersection of merchant-accepted and
> payment app-supported payment methods. For each payment method in the intersection,
> we then need to figure out whether the merchant
> supplied conditions (aka filter) match the payment app supplied conditions. Until
> recently, we expected the payment app to do that
> computation. However, now we have momentum in the other direction, or the user agent
> to do simple string set matching.

It's worthwhile exploring this, but I worry that it will be
insufficient. Nonetheless, I'm willing to throw support behind
Rouslan's proposal [0] if it can be integrated in a backwards
compatible way with .show().


> - It seems important that canMakePayment() and the algorithm in 3.2 should *both* take
> into account the payment-method specific
> filters provided by the payment app. However, right now PR API does not require third
> party payment apps and so there is no explicit
> mention of third-party payment app filters.

It appears that it would be a non-breaking change to add [0] to the PR API.

> - AdamR has pointed out that providing information to payment apps about a transaction
> before the user has selected the payment app
> has raised privacy issues.

I don't think I ever proposed doing any such thing, but whatever. My
goal is only to allow payment-request handlers to handle calls to
.canMakePayment() in a privacy-maintaining way - but also in a way
that doesn't disadvantage the Web.

> Having the browser do matching based on strings provided
> by the payment app removes that concern.
> (I cannot recall which message of yours speaks to that concern in your proposal.)

I'm pretty sure I addressed those in my proposal. Irrespective, none
of the proposals are set in stone and it's not as if things can't be
fixed if demonstrated to be wrong.

> > This statement is false. It's implemented in Gecko for over 2 years (becoming available
> in Fennec soon), underpins PWAs in Chrome and Opera (it's been shipping in stable for
> well over a year in both), and has had significant backing and participation from Microsoft.
> Thank you for that status update.
> I was basing my comment in part on Caniuse information (which may need an update, therefore).

As was I.


No, the information there is accurate - but you need to read it more
carefully: It clearly states that it's supported in Chrome and Opera,
and then underneath, in the Notes, is states that it is in development
in both Firefox and Edge with appropriate links.

Please always check the fine print ;-)

> >> How should
> >> we write the spec to balance these considerations?
> >
> > Considering the support it already has, perhaps by not doing anything? Let us kindly
> please stop reinventing the wheel.
> I don’t think anybody wants to reinvent the wheel for the heck of it. I think the steps we’ve
> been going through (with your help) are:
> * What wheels do we need?
> * What wheels are out there we can reuse?
> * How interoperable are those wheels?

I do think we've made good progress on some things - like
understanding these as web apps, better integration with the web's
permission model, allowing for better management of payment methods,
etc. But I still think we should be making more use of the primitives
we've defined in the PR API (PaymentRequest and PaymentResponse).

I'm also uncertain if developers can fully support all the events and
bi-directional communication the PR APIs requires via this API (It's
obviously on me to prove that it cannot).

> >>
> >> What should we aim for in FPWD?
> >
> > We should consider not doing this. This is more wheel-recreation. Just allow merchants
> to use HTML/CSs/JS for this.
> I don’t agree that this is wheel-recreation.
> One view was that by having recommendations in browser chrome that had never existed
> before --selection of payment apps—
> that this would be interesting as a new app distribution channel. Several people in the
> task force have indicated that they have
> heard a lot of interest in this.
> The primary countervailing argument has been around security in the presentation of
> untrusted apps. I believe that argument
> has caused a number of people to accept that the status quo could be sufficient.


> >>
> >> There seems to be consensus on "a new openClientWindow method
> >> on the event”. Would someone like to volunteer to write up the proposal?
> >
> > The proposal is in the bug and my counter proposal. Could you let me know what further
> details we need? I'm happy to write it up.
> We discuss clients.OpenWindow() in what is currently section 10.4 Payment App Display
> in the task force spec:
> It seems that we need:
> * To define the openClientWindow() method (somewhere; maybe in 10.4)
> * To review the text in section 10.4. Some of the cautionary statements there could be
> deleted if we have
> a method that is known to do the right thing on a variety of devices.
> * Review example 3 which mentions clients.OpenWindow (but see below regarding Example
> 3)
> Does that sound right as a starting point?


> >> =======
> >> Tommy's pull request regarding Example 3
> How about you and Tommy work together on this?

Will do.

Received on Tuesday, 7 February 2017 05:48:48 UTC