See also: IRC log
<adamR> https://adamroach.github.io/webpayments-payment-apps-api/
https://adamroach.github.io/webpayments-payment-apps-api/#payment-app-manifest
AdamR: If canHandle is absent
then you are expected to handle all payment methods declared in
the manifest
... if present then expected to take in method data and
details, and to iterate over them and return an object
... the object has keys of options it can handle
... the values are modifiers to the option (and -1 if no
modifier)
... a bit strange if "-1" is a common response (which I expect
it will be)
... a description for canHandle is somewhat informal (in
7.3
... in section 8 it will be more formal.
... we also probably want an extension point in PR API on
determining what is an accepted method
... the way that we do that will be based on this registered
function
... I think in PR API we need a clean extension point "Here is
where you run the steps of payment apps"
rouslan: I noticed the callback function returns an object instead of interface/list of interfaces/dictionary/list of dictionaries
adamR: This is the best I could
figure out based on your proposal.
... with a dictionary you need to define the keys in the
spec
... if you think it should be a list we can spec it out that
way as well
rouslan: we could change the
proposed syntax to return a sequence of dictionaries
... where each dictionary has two keys
AdamR: One key would be an id, the other would be an index
Rouslan: Yes
... This also lets us add another value
AdamR: +1
IJ: You could also replace -1 with nothing, so that makes the common case easier
<adamR> [ { “id”: “ABC” }, { “id”: “DEF”, “modifier”: “2” } ]
AdamR: +1
IJ: What about the more formal definition?
AdamR: There are 16 baroque steps not worth reviewing here...but I want to highlight step 10
https://adamroach.github.io/webpayments-payment-apps-api/#matching
scribe: apparently this is
relatively easy to implement
... people are doing something like this (step 10) with “pac”
files
... we may want some W3C-defined terms to define this "almost
null" operating environment...but I would prefer to point to
existing specs
IJ: Let's review offline...what should we pay close attention to?
AdamR: Focus on 7.3 (which will
become sequence of dictionaries) and 8
... I'd like people to review before we merge
IJ: any links to the issue?
AdamR: There was a link that's still there
IJ: Proposed is 2 thumbs up means we can merge
(Ian will look at the IPR issue in github)
https://github.com/w3c/webpayments-payment-apps-api/issues/73
Rouslan: Want to be able to open
a window in a browser to authorize a payment
... so when the browser invokes the service worker with the
payment request event, at this point the app will want to call
clients.openWindow to show a window to the user
... the issue is that we need to make sure that this function
call does not fail.
... it's not clear whether the payment request is a user
gesture.
... to avoid inconsistencies in implementations we should
specify in web payment app api that payment request handler in
the service worker should be able to use clients.openWindow
AdamR: Yes, I think that's the
intention
... we did say previously that payment request show() should
require some user interaction
rouslan; That's not specified explicitly. In Chrome, show() does not require user action; but user action is required to approve payments
scribe: BorisZ raised the
question about ambiguity
... one thing that I noticed that's not specified is that
clients.openWindow needs to be supported
AdamR: My strong preference would be to require user gesture requirement on invoking PR API
<scribe> ACTION: AdamR to raise an issue on PR API [recorded in http://www.w3.org/2016/12/14-apps-minutes.html#action01]
alyver: Two things
... first agree that user action should be required on
invocation of PR API
... the button has to be clicked in order to show the payment
sheet
... I have a question on clients.openWeb....is that a separate
application window? Is this just desktop?
AdamR: The notion is that it will
be implementation dependent.
... in Firefox I expect that we will have a slide-down sheet
that is used to select the payment app itself (and pick billing
address, etc.)
... and then as soon as the user submits that, we'll replace
the contents of that space with something like a spinner
... if the payment app calls openWindow, the construct will
become the window.
... but we should not constrain how other UAs do this
<rouslan> +1
https://www.w3.org/TR/service-workers/#clients-openwindow
IJ: How much do we need to specify here? Where are security aspects covered?
AdamR: I think security aspects we care about handled by service workers
https://w3c.github.io/webpayments-payment-apps-api/#payment-app-display
"Payment Apps that require user input can open a payment window using the clients.openWindow() method defined in [SERVICE-WORKERS]. "
Proposed change to something like:
"User agents MUST support clients.openWindow() method defined in [SERVICE-WORKERS] so that payment apps that require user input can open a window."
"User agents MUST support clients.openWindow() method defined in [SERVICE-WORKERS] so that payment apps that require user input can open a window to collect input."
AdamR: +1
IJ: what is the relationship of
the rest of the first para of 10.3 to this new
requirement?
... I think we should put the selection bits in 9, and leave
the display bits in 10, so the first para of 10.3 might be
shrunk
Requirements:
1) Browsers must allow payment apps to invoke clients.OpenWindow()
<adamR> “Because the user must interact with the browser to trigger a payment request, the user agent MUST treat a paymentrequest event as user interaction for the purposes of determining whether the service worker is allowed to open a window.“
AdamR: In service worker spec, it
says "you must not open a window unless there's been an
associated user interaction event"
... Originally the expectation was that this would be at
"selection of the payment app"
... but we also want to optimize in some cases (no payment app
selection) in which case the user interaction event has to go
upstream to clicking the buy button.
... currently PR API does not have a user interaction
requirement (so we'll address that in a WPWG issue)
... the use case I had in mind here was, e.g.,
micropayments
rouslan: remember about user
gestures that the way they are implemented, once they start
there is a 200ms window, and there's an assumption of
invocation by user
... if the browser shows a UI to the user to review shopping
cart before invoking payment app, then invoking the payment app
will not be the user interaction
... what AdamR writes above works.
alyver: Rouslan said what I
wanted to say...distinguish 2 user interactions (1) open
payment request (2) open the payment app selected by the
user
... the second sentence is ambiguous; needs to specify the
second interaction
<Zakim> Ian, you wanted to talk about payment app opening window v. payment app display
IJ: so clients.openWindow is not just for gathering user data; it's also for displaying yourself (to the extent you need to)
let's write scenarios:
* payment app needs no display, e.g., after first authentication within the same session
* payment app never needs display; just returns data
IJ: Can browser suppress display?
AdamR: Should be the payment app that does that on config
* payment app always has some user interaction
IJ: notes:
- service worker requires user interaction
- in some cases user will interact directly with payment app in a window invoked by the payment app
- but in some configurations (to streamline payments) the user may not have explicit user interact, and for the purposes of service workers requirement this specification considers invocation of payment request API to be the user interaction
IJ: this last bit feels like a note for readers
<Zakim> rouslan, you wanted to suggest Boris or Dominic to craft the exact language
<scribe> ACTION: Ian to take a stab at rewriting the first paragraph of 10.3 [recorded in http://www.w3.org/2016/12/14-apps-minutes.html#action02]
(Question of whether "invocation of PR API" requires user interaction)
<Zakim> alyver, you wanted to give an example of where launching payment app with only the PR user interaction is necessary
alyver: One scenario where you might rely only on PR API invocation ... if a merchant specifies 2 payment methods and the user only has one payment app....shoudl that be launched automatically?
IJ: Yes!
(We have explicitly suggested that.)
https://github.com/w3c/webpayments/wiki/PaymentApp_Notes#user-experience-descriptions
IJ: Is user configuration a user
action?
... I will leave in a note on our wonderings about what
constitute user gesture when we want automatic behavior
actions?
Adam: I think I want to drop my action on PR API
Summary:
* People are going to review AdamR's lambda proposal
* Ian is going to look at 10.3 (Payment App Display) intro text with use cases, a requirement on UAs, and some notes on user gestures
4 Jan 2017 at 9am ET