Payment Apps Task Force

<conorhwp> Hi. Joining the call now

Recent changes

* Integrated changes re: recommended apps, registration, display of windows

* Integrated PaymentAppResponse dictionary

Issue 79

AdamR: Let's wait; some things are in flux

Issue 92

https://github.com/w3c/webpayments-payment-apps-api/issues/92

IJ: Proposed no change to the spec, and maybe some good practice written down

<rouslan> +1

<adamR> +1

RESOLUTION: Close issue 92 with recommendation that the payment app not silently "not match" and instead inform the user of reasons for not accepting payment request

Issue 94 explicit permission

https://github.com/w3c/webpayments-payment-apps-api/issues/94

AdamR: Seems there is support at a high level for ensuring user permission
... but there's an architectural question

<pascal_bazin> I can

adamR: I would like to see the conversation in the other thread play out
... would be good to get an agreement in principle to have an explicit call to the user requesting permission to register a payment app

IJ: Is it different from the way we do it today?

adamR: Yes, there will be an explicit call to a function asking permission, INSTEAD of having the permission request be implicit in the actions that would require permission
... from the user experience perspective, it should be the same permission request

rouslan: I think the UX would have to change. The site has the freedom to request permission first and register the app 2 days later.

<adamR> +

rouslan: so the user experience needs to be "Would you allow this SIITE to register a payment app?"
... I think that it should be that each app requests permission, and users should not grant permission for future apps from the site

adamR: the way that users are usually prompted is yes/always/never
... so if a user is prompted to install and the user answers "always" then it won't be a surprise
... if the user answers "yes" then it would not happen 2 days later since that would be a separate session

rouslan: I am concerned about 4 buttons in a user experience

adamR: Typically what we do is we have yes/no + expansion buttons
... you can see this when a site asks for camera permission

rouslan: Do you see a use case for sites to continuously install payment apps?

adamR: Yes, versioned apps. or different branded apps depending on my account type

<adamR> Rouslan: https://www.dropbox.com/s/3smzrf6t64c15yp/Screenshot%202017-01-24%2009.22.36.png?dl=0

<adamR> rouslan: To be clear, the presense of both “Don’t Share” and “not now” is a problem, and I think it’s going to be fixed soon. But you get the idea.

rouslan: Does "push" allow for continuous install?

IJ: I don't expect background updates to happen while I'm visiting other sites.

adamR: If the service worker is on the same URL, it's not a new installation...it's just the app change.

IJ: I am hearing (1) get consensus here for explicit user permission (2) figure out details of how via github

<rouslan> +1

<jnormore> +1

<conorhwp> +1

RESOLUTION: Get explicit permission from user to approve the service worker registration. Figure out how on github

Issue 95

https://github.com/w3c/webpayments-payment-apps-api/issues/95

Monolithic data registration v. granular data registration

AdamR: I need to respond to this thread
... when a web site asks for a payment, there might be multiple matching apps and user needs to be able to select from among them

IJ: Thread on that issue gets into the manifest topic....

PROPOSED: Move from monolithic get/setManifest to more granular functions to get/set/delete data necessary for payment apps

IJ: Are people ok to move in that direction.

<rouslan> +0.5

<conorhwp> +1

IJ: One piece of rationale was you only need to update the things you need to update

<jnormore> +0

<conorhwp> 1-

AdamR: I think there was also a comms issue here of calling this "manifest"
... my sense is that this change is isomorphic.
... if you specify one you could implement the other via a polyfill
... I am fine to move in this direction.

[Discussion of "data for a given app" and "multiple apps"]

mathp: Would that create a state of stale payment methods?
... suppose a payment method has been removed from the user account.
... it may be simpler to just say to an app "Here's the current state" without having to query it, etc. and do things more fine-grained

conorhwp: I think it would be simpler to have just a simple object and let the app developer abstract way the construction of it
... I'd rather see a single object

jnormore: I agree the approaches are equivalent...I would lean towards consistency with other APIs
... what are good practices...let's take that into account

IJ: Should we bundle filters and payment methods?

AdamR: I am treating them separately. Later we can decide how to set/get filters

<mathp> happy to continue discussion on github

IJ: I am wondering if we should bundle payment method info and handler info since they are closely related. We could avoid duplication and management of changing data over time.

AdamR: I was thinking you do one payment option at a time
... and each option can take more than one payment method potentially.
... I think Marcos' document gets it right

<conorhwp> +1

<conorhwp> +q

conorhwp: I am ok with the proposal

Proposal:

* Move away from monolithic set manifest

* Avoid the word manifest

* Create some number of more specific get/set/delete functions

* Maintain the possibility of specifying the "current state" of payment method support in one call

AdamR: I am more comfortable giving more fine-grain, and then showing people how to set the whole state at once
... basically showing the polyfill

mathp: For an app it will be difficult to know what payment methods were there previously
... want to make it easy to put the best state from the server into the app

adamR: Would 'Delete all" work?

mathp: Fine-grain control may introduce bugs....raises maintenance cost

[No resolution]

mathp: I will weigh in on GitHub with my concern

Issue 98

https://github.com/w3c/webpayments-payment-apps-api/issues/98

AdamR: Marcos clarified he means permission grants not "one app per site"
... if that's the case we should all be on the same page.

Issue 97

https://github.com/w3c/webpayments-payment-apps-api/issues/97

AdamR: I am hearing a slight leaning toward a specific method on the event itself to open windows
... one reason is that it might be reusable in other contexts (so not specific to payemnts)
... but that might require additional coordination on this pattern

https://github.com/w3c/webpayments-payment-apps-api/issues/97#issuecomment-274787159

IJ: Who should we get to look at this issue (other than the usual suspects)?

Should we close 73 in favor of 97?

IJ: Should user agents be required to show payment app origin to the user?

rouslan: I think the web browser will handle that but ok to put in the spec as a recommendation

Next meeting

31 January