See also: IRC log
<conorhwp> Hi. Joining the call now
* Integrated changes re: recommended apps, registration, display of windows
* Integrated PaymentAppResponse dictionary
AdamR: Let's wait; some things are in flux
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
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
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
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.
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
31 January