Payment Apps Task Force

22 Aug 2017


See also: IRC log


Frank, alyver, Ken, Sachin, adrianhb, Rouslan



Moving the Payments Apps discussions to Thursday's meeting

<rouslan> +1

(IJ talks about moving agenda to Thursday calls starting after PR API CR)


<frank> +1

(Some support for doing this)



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)


<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.

Example from Rouslan on two service workers


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



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

#178: Default handler icon. Can we make progress on this?


rouslan: For default icon we are still gathering implementation experience
... we need to consider scope as AHB suggested, need more implementation experience

#173 Ability to set default instrument for given handler

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


<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]

#190: respondWith behavior not specified

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

#116: Relation between merchant order of payment methods and payment app order of instruments


IJ: Propose we give Ken a week to add his proposal

Next meeting

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

Summary of Action Items

[NEW] 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]
[NEW] 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]

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2017/08/22 15:01:39 $