See also: IRC log
WebEx phone gateway is down for now
So you need computer audio I think
7 Dec
Tuesdays, 10am ET or 11am ET (for 1 hour)
Should we change to that time?
<rouslan> +1 either
Tommy: -1
... But I can live with it
<adamR> +1 either
https://github.com/w3c/webpayments/wiki/PaymentApp_Notes
WebIDL fix
Tommy edits regarding cancelation and failure handling:
Tommy: Main thing I did was to
say that the rejection of the promise is not necessarily
fatal.
... the user agenda can decide what to do next.
https://github.com/w3c/webpayments-payment-apps-api/issues/69
Proposal:
1) We refer to web app manifest rather than roll our own
2) We decide how much of that spec to reference
<Zakim> rouslan, you wanted to talk about icon
rouslan: I think you expressed my
view - we should reference web app manifest
... and follow their examples.
... this will benefit implementers
https://www.w3.org/TR/appmanifest/#manifest-and-its-members
IJ: Do we need all the manifest members?
rouslan: That's a hard question to answer here; I think we should continue discussion on GitHub
http://caniuse.com/#search=manifest
AdamR: Marcos may have an opinion on referencing it (re: stability)
IJ: Should I update the spec to say "we are looking at referencing web app manifest"
AdamR: +1 to reusing the two
names from that spec, and leaving a note to say we are looking
into importing or referencing web app manifest
... please include in examples so people can
understand
<scribe> ACTION: Ian to update the manifest information with pointer to this issue and updated member names [recorded in http://www.w3.org/2016/11/30-apps-minutes.html#action01]
previous action - AdamR to take a stab at writing up description of payment app function to return boolean if filter matches; see
https://www.w3.org/2016/11/02-apps-minutes.html#item03
AdamR: It was not clear from our last chat was whether we want to define a lambda-based mechanism, or if we want an algorithm for matching capabilities of payment apps with filters described by payment requests
rouslan: On declarative v.
procedural....
... data v. function
... I prefer the lambda approach
... I think Adam wanted to be sure that the function could not
access the network...I'm not sure how easy that would be to
enforce
... what would be good as well is a timeout
... e.g., 400ms
adamR: Will require some time to discuss; find out how sandboxes are described elsewhere
IJ: EME
https://www.w3.org/TR/secure-contexts/
https://www.w3.org/TR/secure-contexts/#monkey-patching-sandbox-flags
https://www.w3.org/TR/html51/browsers.html#parse-the-sandboxing-directive
AdamR: There's a chance that this is unique and will get odd glances
IJ: Due date?
AdamR: Regrets for 7 Dec
... suggest we review this 14 Dec
https://github.com/w3c/webpayments-payment-apps-api/issues/12
IJ: New views on this?
Rouslan: It seems that it's not
too difficult to support options
... but we haven't blended the UI of options and payment
apps
... we are still undecided on this
IJ: Should we have the spec say "provide option data and display may vary" or wait more to get experience?
adamR: I am ok with current
approach for the time being
... I think that if some browsers display options, there will
be pressure on browser vendors to display
IJ: The spec could say "browsers and payment apps may exchange option information"
AdamR: I'm ok to wait to see how
things land and update the spec
... I prefer that the data structures be defined and to say
that display of option is done at the preference of the
browser
... if not displayed, then the field could come through
undefined
... the issue is "more clicks" from the user to make things
happen when they can't choose options directly
rouslan: I am recalling recent
conversations on blink list about vagueness of spec
... so let's be more specific and say user agent SHOULD display
options
... and UA gets to experiment with exact user experience
AdamR: If option is not displayed, need to send appropriate (null) data to the payment app
[jenan asks UI question]
https://github.com/w3c/webpayments/wiki/PaymentApp_Notes#user-experience-descriptions
IJ: Yes, options might enable user to pick card (e.g.,) straight from mediator UI
AdamR: Goal is to minimize user actions
<jenan> roger, thanks!
Summary:
- include option data in the communications between mediator and payment app
- mediator SHOULD display options
- where user selects option, that information sent to the payment app
(AdamR: Yes, via a unique ID)
- where mediator does not support options, then ID is null to payment app
<TommyT> +1 to MUST
rouslan: chrome shows most
frequently used payment option, and user can expand to view all
of them
... so does that mean we are not displaying all options (and
violate MUST)?
Tommy: It's easier to implement
MUST than SHOULD
... since we need to implement support for payment apps that
supply options and those that don't
... the MUST here is on the mediator, but there's an option for
payment apps (to have options or not)
... are both options and not-options legal?
jenan: What about language that the user must be able to select all options (rather than speak about display)
<rouslan> +1
<rouslan> 1-
<rouslan> +1
rouslan: Yes, +1 to language about user must be able to select all options
<scribe> ACTION: Ian to update the spec to talk about options, user selection of options [recorded in http://www.w3.org/2016/11/30-apps-minutes.html#action02]
IJ: How is it going? can we help you as a group?
Tommy: I have received a lot of
requests from third party payment app implementers
... and they want a platform to test apps
... so I wanted to see if I could implement this in Chromium,
and our colleague from Samsung has started implementing the
difficult stuff.
... so I'm going to let him!
... I will try to tackle some of the easier problems
... we would like to be able to make some prototype versions of
Chromium for app implementers to test
... not sure how long it will take us...we've built some pieces
but not put them together yet
IJ: We could organize a hackathon (e.g., Boston)
OR
scribe: in Chicago around our FTF meeting (if we have it in march)
Tommy: We should be able to have something together in Q1
https://github.com/w3c/webpayments-payment-apps-api/issues
Regarding issue 23
AdamR: I think that is mostly
covered by our shift to service workers
... there are still questions about what permissions we expect
the apps to use
... I think we want apps to have access to the web platform
(e.g., cameras, etc for authentication or QR codes)
... it is a question we need to address
... I do expect the question will come up later
Ian: AdamR, perhaps you can weigh in by email on this proposal:
https://github.com/w3c/webpayments-payment-apps-api/issues/48#issuecomment-261786242