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

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


> 
>    [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
> 
> 2) DISPLAY OF OPTIONS
> 
>    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. 

> 
> 3) DEPENDENCY ON WEB APP MANIFEST
> 
>    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. 

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

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. 

> 
> 4) RECOMMENDED PAYMENT APPS
> 
>    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. 

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

> 
> 5) OPENING WINDOWS.
> 
>     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. 

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

> 
> =======
> Conor's suggestion regarding recovery of a failed push payment
> https://github.com/w3c/webpayments-payment-apps-api/issues/102
> 
> Quoting:
> 
> "I suggest adding the "PaymentComplete" enum to the response that
> comes back to the mediator from the app, allowing for a clear mapping
> like the "details" object."
> 
> =======
> Next meeting
> 
> * 14 February
> 
> ========
> Other issues
> https://github.com/w3c/webpayments-payment-apps-api/issues
> 
> --
> Ian Jacobs <ij@w3.org>
> https://www.w3.org/People/Jacobs/
> Tel: +1 718 260 9447
> 
> 
> 
> 
>