See also: IRC log
https://lists.w3.org/Archives/Public/public-payments-wg/2017Aug/0014.html
<rouslan> +1
(IJ talks about moving agenda to Thursday calls starting after PR API CR)
https://lists.w3.org/Archives/Public/public-payments-wg/2017Aug/0014.html
<frank> +1
(Some support for doing this)
https://github.com/w3c/payment-handler/pull/170#issuecomment-318779874
IJ: Any suggestions for how to
make progress? Rouslan and I are planning to chat with
AdamR
... One idea froM Rouslan is "send less data" (e.g., just PMIs
and related filters) to reduce (but probably not eliminate)
fingerprintability
... Privacy issue is payment app knowing where you are
shopping
... Options we have discussed:
- merchant does computation (but then merchant knows everything about user environment)
- browser does computation (but browser vendors have said they don't want to do that)
- payment app does computation via lambda run by browser (but marcos has indicated this is not viable in JS)
- payment app does computation itself (but raises privacy issues about knowledge about merchants where I am shopping)
https://github.com/w3c/payment-handler/pull/170#issuecomment-318801051
<Zakim> rouslan, you wanted to ask whether anyone remembers the problem with capability filtering
rouslan: One things we might
proposal is to use capability filtering for basic card
(in-browser computation) but for other payment methods invoking
canMakePaymentEvent
... basic card or other w3c-defined payment method spec
IJ: My expectation is to chat more with AdamR about this.
https://github.com/rsolomakhin/rsolomakhin.github.io/blob/master/pr/sw.md
IJ: High level questions - is this the right design? Should we include it in the spec? elsewhere? The use case is "two payment apps from the same origin"
rouslan: The example shows 2 scopes...allows compartmentalization of payment instruments
<Zakim> rouslan, you wanted to talk about this example.
rouslan: e.g., the biz wallet and
personal wallet from the same company
... I think having two service workers with different scopes is
the best way today to do this
... soon after I did this example, some of our partners came to
us and said they needed this functionalitty
... and they tried it and said "This doesn't work!"
... so I looked into it more deeply and it turns out that there
was a Chrome bug ("one payment app per origin")
... we've fixed that bug and now the examples work
IJ: Were the partners thus satisfied?
rouslan: Yes
<Zakim> AdrianHB, you wanted to ask how the icons etc work with scopes?
AdrianHB: My question is how do
the manifests work with different scopes?
... is that how you will have different icons and labels?
rouslan: We want to use Web App
manifests
... currently, when service worker is registered, we look for
manifest file and pull icons and name from there.
... you could have to create 2 web app manifests for 2
apps
... you need to register 2 different payment handlers
... We are currently doing this, but I'm not sure if this
approach is the best
... it does not use the payment method manifest
... another approach might be to think about the scope as the
payment method
... and follow the payment method manifest spec to download the
manifest instead of using the link from the web page
... one advantage of this approach is that "recommended
applications" (if we go that route) can be proposed
... the payment method manifest itself points to the web app
manifest
... if we continue to rely on a web app manifest file linked
from an HTML page, it's not clear how we could do recommended
payment apps
... so specific design may change but ultimately we get
name/icon from web app manifest
https://w3c.github.io/payment-method-manifest/
https://w3c.github.io/payment-method-manifest/#manifest-example
AdrianHB: Going through payment method manifest may be problematic for basic card wallets with personal/business distiction
rouslan: Regarding overlapping
scopes...if you have /webpayments and /webpayments/personal, I
think that the question of which worker gets invoked is defined
in the spec (e.g., "most specific service worker")
... in terms of the web app manifest "scope," I hadn't
considered that previously
... that's a really interesting idea that we should try to
integrate into the payment handler spec and our
implementation
... I think we need to get some more implementation experience
as well
Proposed: Rouslan to update example illustrating 2 payment apps from the same origin
<rouslan> +q
<scribe> ACTION: Rouslan to update example illustrating 2 payment apps from the same origin [recorded in http://www.w3.org/2017/08/22-apps-minutes.html#action01]
Ian: This is actually closest to issue 153, so maybe just update your examples
https://github.com/w3c/payment-handler/issues/178#issuecomment-309778321
rouslan: For default icon we are
still gathering implementation experience
... we need to consider scope as AHB suggested, need more
implementation experience
rouslan: Not sure how much
excitement there is for this notion (either from google or
mozilla).
... behavior is not yet clear
... perhaps a more concrete proposal would help, but I suggest
that we postpone discussion for now
AdrianHB: Regarding issue 173, I think we've not had much discussion about the issue
https://github.com/w3c/payment-handler/issues/173#issuecomment-317497373
<scribe> ACTION: Ian to put issue 173 on this week's WPWG call [recorded in http://www.w3.org/2017/08/22-apps-minutes.html#action02]
rouslan: I think this is
currently in progress.
... a Chromium review expressed concern in reviewing
paymentrequest.respondWith() and asked for more defined
behavior.
... I think that review of the PR is ongoing
https://github.com/w3c/payment-handler/issues/116#issuecomment-317890522
IJ: Propose we give Ken a week to add his proposal
29 Aug
<AdrianHB> +1 to move conversation to Thursday call. Do we know if other implementors are showing interest in Payment Handler? (i.e. Microsoft, Apple etc)
<AdrianHB> I wonders if they will stop joining Thurs calls if we just focus on Payment Handler