W3C home > Mailing lists > Public > public-payments-wg@w3.org > February 2017

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

From: Ian Jacobs <ij@w3.org>
Date: Mon, 6 Feb 2017 16:08:27 -0600
Cc: Payments WG <public-payments-wg@w3.org>
Message-Id: <D6CF25CB-DFE9-4D78-B067-A32DBC46032D@w3.org>
To: marcos@marcosc.com
Hi Marcos,

Notes inline.

> On Feb 6, 2017, at 2:53 PM, marcos@marcosc.com wrote:
> On 7 Feb 2017, at 5:43 am, Ian Jacobs <ij@w3.org> wrote:
>> Participants in the payments app task force,
>> We meet 7 January at 10am ET. 
>> Previous meeting 31 January:
>>  https://www.w3.org/2017/01/31-apps-minutes
>> WebEx: 
>> http://www.w3.org/2017/01/paymentapps-2017.ics
>> Ian
>> ========
>> Review the Proposal, which identifies points of consensus and open issues. 
>> I updated the proposal based on recent discussions including last week's meeting: 
>> https://github.com/w3c/webpayments-payment-apps-api/wiki/Proposal-20170130
>> I would like to discuss in particular some proposals that would help us move forward:
>> 1) FILTERING. See proposals from Adam [1] and Rouslan [2]. These
>>    proposals move away from filtering-in-the-payment-app back to
>>    filtering-in-the-browser. We will need to hear from browser
>>    developers 
> 👋 hi - I'm part of Mozilla's implementation team, and main point of contact between that team and the standardization effort. 
>> whether they would commit to a simple matching
>>    language, and whether that commitment would enable other
>>    payment methods to make use of it.
> My counter proposal is also on the table and matches what Apple does (allowing for network requests to verify merchants, for instance- in the spirit if canMakeActivePayment()). I'd don't see how the two proposed alternatives allow for the creation of something like ApplePay? 
> 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. Merchant validation was not deemed critical to all payment methods, and therefore
    is not built into PR API V1. It was also not deemed critical path for V1 of basic card. But it is possible to define a payment method 
    that involves merchant validation.

  - 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. 

  - 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 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.

  - 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. 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.)

>>    [1] https://github.com/w3c/webpayments-payment-apps-api/issues/96#issuecomment-276416457
>>    [2] https://github.com/w3c/webpayments-payment-apps-api/issues/96#issuecomment-276423629
>>    Action 20170131: Andre to write up use cases for additional
>>                     organizational capabilities for payment apps.
>>    Do we need additional container capabilities?
>>    Is it required that user agents display option information (or just
>>    a way for user agents to improve the user experience)? See issue 90.
> I think it's critical to gather real world examples. I would like to see something that looks a lot like this document (i.e., a lot of screen shot of real world products):
> https://www.w3.org/TR/netinfo-usecases/
> It doesn't need to be as formal - but should not be based on fictional user stories or anything like that. We have a lot of great companies in this WG who already provide amazing checkout experiences - we should look to those. 

(I hope Andre sees the request! :)

>>    As we have moved in the direction of "payment apps are web apps
>>    that implement additional permissions" we have moved in the
>>    direction of dependency on other parts of the Web platform.
>>    Web App Manifest is one such component, which provides app-level
>>    information about labels and icons. However, it is not yet
>>    widely supported in browsers and also would not (as is) provide
>>    information about options-level labels and icons.
> 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).

>> 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?

> As editor of the Web Manifest spec, I'm happy to work with this group to add clarifications or new members to the spec should the use cases not be met. To date, all use cases have been met AFAIK. 

I think that’s part of the “do we need options?” discussion.

>>    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.

>> My personal preference is to
>>    enable merchants to provide a list of payment app identifiers
>>    (including just origins for web-based payment apps) as input to PR
>>    API and let the user agent try to make good use of the information
>>    such as highlighting registered payment apps recommended by the
>>    merchant.
> I'm not in favour of this feature. We should sort out how payment apps will work first - this should be incubated using plain old HTML, CSS, and JS over the next few years while we roll out Payment Request to see what patterns emerge. It's way too early to even be considering standardization of this. 

I don’t agree that it’s premature to include merchant preferences in V1. However, I can live with not including them in V1 if there is little support and strong opposition. I am hearing your strong opposition - no need to repeat it. ;)

>>     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
>> https://github.com/w3c/webpayments-payment-apps-api/pull/101
>> Do people support the fix to the example?
> Yes. That needs to be removed immediately: Blink is dropping support for navigation of data: URLs on top level windows and Edge/IE has never allowed those. It's also why I raised the issue in the first place. 
> We should have a POST example - but one that used service workers properly. I'm happy to write that - please assign it to me. 

How about you and Tommy work together on this?

Thanks, Marcos!


Ian Jacobs <ij@w3.org>
Tel: +1 718 260 9447
Received on Monday, 6 February 2017 22:08:35 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:43:24 UTC