14:54:38 RRSAgent has joined #apps 14:54:38 logging to http://www.w3.org/2017/02/21-apps-irc 14:54:52 agenda: https://lists.w3.org/Archives/Public/public-payments-wg/2017Feb/0040.html 14:55:02 Meeting: Payment Apps Task Force 14:55:06 Chair: Ian 14:55:10 Scribe: Ian 15:00:33 present+ 15:00:41 present+ Andre 15:00:44 present+ Frank 15:01:07 alyver has joined #apps 15:01:30 present+ Jake 15:01:39 present+ Adam 15:01:41 JakeA has joined #apps 15:01:48 frank has joined #apps 15:02:26 Proposal (summary of where we are on key issues): 15:02:26 https://github.com/w3c/webpayments-payment-apps-api/wiki/Proposal-20170130 15:02:44 Issues list: 15:02:44 https://github.com/w3c/webpayments-payment-apps-api/issues 15:03:04 Changes: https://github.com/w3c/webpayments-payment-apps-api/pull/104/commits/dc913b844e131a5f5c3156a41328da1154f2dee8 15:03:21 present+ AdrianHB 15:03:31 rouslan has joined #apps 15:03:39 To see the changes rendered in situ, see https://adamroach.github.io/webpayments-payment-apps-api/ — section 7 15:04:10 topic: The model 15:04:12 https://github.com/w3c/webpayments-payment-apps-api/wiki/Proposal-20170130 15:05:31 https://github.com/w3c/webpayments-payment-apps-api/issues/98#issuecomment-280652989 15:06:08 => https://github.com/w3c/webpayments-payment-apps-api/wiki/Proposal-20170130 15:06:14 "A payment app is a Web application that manages payment requests on behalf of the user by supporting one or more payment methods. " 15:08:42 Lots of things we need to sew together: 15:08:47 * relation to web app 15:08:49 * relation to options 15:08:51 * relation to service workers 15:08:53 * relation to origin 15:08:56 * location of code 15:08:59 * identifiers for matching 15:09:04 * registration 15:09:13 q+ to suggest a change to "A payment app registers support for payment methods with the user agent, through service worker registration." 15:09:17 ack adr 15:09:17 AdrianHB, you wanted to suggest a change to "A payment app registers support for payment methods with the user agent, through service worker registration." 15:10:01 AdrianHB: I think what you are saying is "the way that a payment app registers support is by registering a service worker, and during that registration process, it has the opportunity to register support" 15:10:34 AdrianHB: We want to cater to the audience, which is developers 15:11:16 Jake: When we did the service worker spec 15:11:19 ...for various events 15:11:25 ...none of these specs defined what a web app is 15:11:29 ...or what a push listening web app is 15:11:37 ...I'm worried that trying to define that is causing problems 15:11:48 ...instead we should be giving the ability for an app to handle payments 15:13:04 q+ 15:13:13 ack rouslan 15:13:27 +1 15:13:38 Rouslan: +1 to spec just talking about features 15:13:43 IJ: +1 15:13:47 q+ 15:14:13 IJ: FPWD is a good time to split out the info 15:14:15 ack Adr 15:14:32 AdrianHB: +1 to sentiment of separating spec feature definition from marketing material 15:15:17 "handler" is good 15:15:20 ...e.g., the spec could be named after the feature name 15:15:42 ...so it's less about payment apps and more about features that we are defining to let someone build a payment app 15:15:43 I’m weakly +1 on renaming 15:15:48 q? 15:17:40 q+ 15:17:50 Please let's not let recommended payment apps drive this design 15:17:56 q+ to talk about method/app relationship 15:18:09 IJ: Recommended payment apps...what are the identifier designs? 15:18:31 Jake: Regarding recommended payment apps, nothing better than link to a service worker 15:19:35 Huge -1 to whitelists 15:19:55 -1 to whitelists too 15:20:31 q? 15:20:35 ack JakeA 15:20:44 IJ: Recommended may mean "merchant preference; for browser discretin" 15:20:56 JakeA: :Even just a URL will look like a browser recommendation since in chrome 15:21:09 ..since just a URL it's less good than a LINK that can have title, link text 15:21:20 michielbdejong has joined #apps 15:21:33 ...I think it's important to keep info that is really about the landing page's content (e.g., recommendation) in the page 15:21:40 present+ michiel 15:21:46 q? 15:22:00 ack rous 15:22:00 rouslan, you wanted to talk about method/app relationship 15:22:22 rouslan: I think the primary argument for having recommended apps is that these identifiers are different from the payment methods 15:22:30 +1 to JakeA flow (noting that the PaymentRequest API calls fail silently) 15:22:36 (IJ: Agreed app identifiers are not the same as payment method identifiers) 15:22:57 rouslan: E.g., multiple payment apps may support a tokenized card payment method spec 15:23:23 ...but for proprietary payment methods, owners want to authorize payment apps to support those payment methods 15:23:36 ...therefore we need to be able to identify apps from payment method manifest files 15:23:39 Suggest that payment method manifest restrict apps by origin 15:23:57 (That's the question: do we need a URL or just an origin?) 15:24:03 q+ 15:24:15 For permission, just an origin 15:24:18 Rouslan: It's useful for the merchant to suggest 2 or 3 apps that work well with their web site 15:24:26 ...that's an argument in favor of recommended apps 15:24:40 JakeA: What's wrong with a link? 15:25:37 AdamR: I think it would be problematic if we required payment method manifests to contain a pointer to payment apps in order for them to be recommended. 15:26:04 @AdamR: The current payment method manifest proposal is to have a whitelist where the absence of a whitelist implies no restriction 15:26:16 q? 15:26:22 ack adam 15:26:46 q+ 15:27:02 IJ: There are two things we've talked about (1) expression of merchant preferences (2) bootstrapping the app ecosystem 15:27:23 Andre: -1 to whitelisting 15:27:44 Andre: I think there is value to merchants providing preference information that browsers can use to highlight 15:28:11 ...I also like the approach of linking recommendations to canMakePayment() [failure] 15:28:16 q? 15:28:18 ack aly 15:28:22 -1 to whitelisting by merchant BUT whitelisting by payment method manifest publisher is the current proposal 15:28:48 Why isn't the identifier the registration scope? 15:28:55 q+ 15:29:23 ack adam 15:29:34 adamR: Reminder - there are two things we are thinking about here. 15:29:53 ..one thing is "recommending code" a landing page that registers the app 15:30:04 ...but there is a different use case which is merchant recommendation of payment app 15:30:10 (e.g., special promotino) 15:30:16 ...the identifier for that will almost necessarily be different 15:30:17 payment option weighting seems fair 15:30:31 I think the only way we can cater for use case 2 is recommend by origin 15:31:23 q+ 15:31:26 ack AdrianHB 15:31:35 IJ: QUESTION: - recommend apps by origin? 15:31:52 AdrianHB: The merchant has no idea what options will be presented to the user; the merchant can't recommend options 15:32:09 ...merchants know payment methods and origins of extant payment apps 15:32:14 ...so at most they could recommend them by origin 15:33:35 topic: Adam's proposal re: options 15:33:54 https://github.com/w3c/webpayments-payment-apps-api/pull/104/commits/dc913b844e131a5f5c3156a41328da1154f2dee8 15:34:06 Adam: Replaces monolithic set/get manifest with more granular 15:34:17 ...it also incorporates to some degree our FILTERING direcion 15:34:29 ...so we no longer have lambda functions 15:34:35 ...this is based on filters/capabilities approach 15:34:43 agenda+ Status of filtering proposal from Rouslan 15:34:49 ...so we define two constructs: 15:35:03 * OPTIONS...for most payment methods this will resolve 1:1 to instruments like credit cards 15:35:20 * WALLETS...this is an additional container for use case where there is one origin that wishes to group payment options together 15:35:41 ...e.g., white list wallets, or personal/business groupings 15:35:49 ...or Multiple instruments held with a single provider 15:36:02 AdamR: The current document does not go into much detail on rendering 15:36:23 ...some ideas: if you have no wallets the browser renders payment app (e.g., manifest) info 15:36:31 ..but if you have wallets, those override the app-level information 15:36:34 So wallets are just a grouping for options? 15:36:40 (Yes) 15:36:51 q? 15:36:59 https://github.com/w3c/webpayments-payment-apps-api/issues/98#issuecomment-280747308 15:37:13 q+ to ask adam to re-explain "options" again. 15:37:39 Jake: Other things that talk about service worker treat registration as a "toplevel thing" 15:37:50 ...so "a payment handler" would be stored within a service worker registration 15:38:00 ...so an origin can have multiple payment handlers 15:38:21 ..the browser may group information 15:38:50 AdamR: To be clear, the concept is to decouple the grouping of what is shown to the user from how the web site chooses to structure handling 15:39:14 ...the notion here is to separate "how service workers are structured" from "how to render grouping to the user" 15:39:20 ...they may or may not be handled by different service workers 15:39:28 JakeA: Some concerns about complication 15:39:44 ..with fetch events, for instance, you have one fetch event. You don't have multiple different service workers handling requests from the same URL space 15:39:56 ...that means we don't have to manage "which service worker is this going to" 15:40:11 AdamR: We could add that restriction; it's orthogonal. 15:40:18 q+ to ask what happens if 2 service workers register the same walletKey 15:40:23 ack aly 15:40:23 alyver, you wanted to ask adam to re-explain "options" again. 15:40:43 https://dl.dropboxusercontent.com/u/53717247/amex.png 15:40:56 AdamR: In this proposal - wallet is container, option is instrument level 15:41:19 ..in the above image, the wallets are "American Express" and "American Express Business" 15:41:24 ..and the options are the individual cards 15:41:57 AdamR: These are like having H1 and H2 groupings of things 15:42:01 ..it's just a rendering construct 15:42:07 q+ 15:43:37 ack j 15:44:03 JakeA: It feels to me like this would be stored against a payment handler that is a SW registration that knows about cards and the grouping 15:44:08 AdamR: That's exactly it 15:44:14 JakeA: Sounds great! 15:44:16 ack Ad 15:44:16 AdrianHB, you wanted to ask what happens if 2 service workers register the same walletKey 15:44:32 AdrianHB: Agree it mostly sounds great. We said we are decoupling the presentation from the execution which is great. 15:44:40 ...that was the goal...BUT 15:45:11 ...I'm not sure we've achieved it. As an example, suppose PayPal gives me some service worker code... I want a single wallet, multiple service workers to handle different methods 15:45:20 ...so I want to group three service workers in one wallet 15:45:27 ...how does it work? 15:45:38 Having a single wallet spread across multiple SWs, that feels complicated 15:45:39 AdamR: If we decide to allow multiple SW/Registrations that should work 15:45:55 AdrianHB: I assuming the groupings are OPTIONAL for the browser to render 15:46:09 AdamR: I suspect that long term it will be implemented 15:46:35 AdrianHB: If options are not rendered, might be issues 15:46:58 ...if the user only sees OriginA and OriginB....if I have three service workers, what happens when user selects OriginA 15:47:16 AdrianHB: It may be that groupings are optional 15:47:37 QUESTION: Can we allow multiple service workers to register to handle payments? 15:47:39 q+ 15:47:55 ack J 15:48:21 JakeA: Many things that are built on service workers have allowed multiple things per origin (e.g., fetch listeners, background syncs) 15:48:31 ..but the restriction is that the TOP LEVEL is a service worker registration 15:48:40 ...a single push listener only deals with one service worker registration 15:48:49 ...you are tied in that case to a single service worker registration 15:48:53 +1 that speaks to the comment I made about terminology at the beginning I think 15:48:56 ...when you are updating code, it's updated in an atomic way 15:49:29 JakeA: A payment handler has a 1:1 mapping to a SW registration 15:49:36 ...you can't have more payment app handlers per SW registration 15:49:40 ...you can have less, but not more 15:49:44 q? 15:50:10 AdrianHB: How would you code multiple event listeners then? 15:50:28 JakeA: Each SW registration has one main SW. that's where the events are fired 15:50:38 ..if you want 2 PUSH subscribers, you need 2 active SWs 15:51:00 AdrianHB: Given that setting of options / wallets is done against the payment app manager (an extension of SW registration) I assume that was our intent 15:51:17 ..if I want different service workers handling different options, then I assume I need to register each one independently 15:51:25 q+ 15:51:51 AdrianHB: You can code it such that what you select triggers different SW 15:52:15 AdamR: I agree with issue about rendering options in that case 15:52:52 AdrianHB: You register a SW, you have an option to set some stuff (e.g., specific to payment request handling) 15:53:33 q+ 15:53:39 ack me 15:53:50 Ian: How do you propagate when options not shown? 15:53:51 ack Add 15:53:53 ack Ad 15:54:10 AdamR: I am not yet sold on necessity of multiple service workers 15:54:25 ...I like the simplicity of what Jake has described in other settings 15:54:36 AdrianHB: You can register multiple service workers (it's not one per origin) 15:55:14 JakeA: I mean to say "One per registration" for each Push subscription but you can have "Many registrations per origin" 15:55:25 ...suggesting the same for payments 15:55:37 ...a given payment handler is a service worker registration 15:55:44 (Top level) 15:55:54 ..you can have multiple per origin 15:56:59 IJ: The UX I want is (1) if options are shown, they are active (2) if options are not shown, open the payment app 15:57:28 AdrianHB: I don't know whether the browser is going to render options or not. So if the event is called for all service workers, I don't know whether I was actually selected 15:57:46 AdamR: The event includes the pointer to the ID of the option was selected. If the option was not selected, the field was not populated 15:59:16 JakeA: If the browser knows what the next selection is, the browser could then ask "What card?" 15:59:43 AdrianHB: I think that Zach has said we should not prescribe that level of user experience 15:59:56 (IJ: We have not discussed previously Jake's notion of "submenu") 16:00:03 q+ 16:00:18 AdamR: Developers can make a choice to use 1 or N service workers 16:00:20 ack JakeA 16:00:37 JakeA: You will still have the same screen space problem if you have lots of options from many origins 16:00:47 ...but I don't think we should have a different end state than on mobile 16:00:52 q+ 16:01:01 ...this is not really about specifying UX...it's up to the browser 16:01:09 AdamR: I see what you are saying 16:01:11 ack AdrianHB 16:01:34 AdrianHB: Seems ok to leave it up to the browser when the user makes a selection...one or more event handler will be fired..if it's N > 1 then there's no option id 16:01:46 JakeA: I would advise against a solution of firing multiple service workers at once 16:02:25 AdrianHB: Imagine I am bankA and the user has in their wallet the ability to pay with PayPal and also a bank card 16:02:40 ...I might separate event handlers ... one for PayPal and one for card 16:02:59 ...if both options are not displayed to the user, when user picks bankA, one approach was "fastest to respond wins" 16:03:06 ...Marcos indicated that's how fetch works 16:03:19 JakeA: That's not how fetch works. 16:03:29 ..I don't think we should create a system where the browser provides a partial answer 16:03:40 ..the whole benefit of the API is that you go through a large amount of the flow in the browser UI 16:03:49 ..if the browser bails at some point, it becomes difficult to test 16:03:57 ...and browsers might fail at different points 16:04:08 q? 16:04:25 summary 16:04:39 - we could limit system to not have multiple payment handlers per origin 16:05:00 JakeA: Origin is not the top level...service worker is the top level 16:05:17 ..if you are handling payments across multiple SW registrations...if you are racing across events, I think that's too complicated 16:05:40 ..if a payment handler is linked to a service worker registration, you can have many of these per origins, but trying to conduct a payment across multiples of those at once seems weird 16:05:54 I am hearing, the solution should not allow browsers to invoke multiple handlers for a single user selection 16:06:06 - where options aren't rendered at top level, allow browser to render second level 16:06:43 +1 16:06:57 q+ 16:07:11 ack AdamR 16:07:15 the normative req for that is, if the app registers options you MUST render them to the user 16:07:20 AdamR: The thing to keep in mind is that we also need to handle native apps on mobile devices 16:07:38 ...we might be able to convince people that for SW-based apps this is the model, but I think we'll get pushback for native apps 16:08:04 how a browsers renders native apps in the user choices is also browser UI decision 16:08:06 q+ 16:08:09 ack Jake 16:08:46 +1 if you accept options you MUST return an option id in the event 16:09:22 JakeA: All the spec would have to say is that if I have provided a series of options, the user agent must provide the user's selection in the SW event(s) 16:09:28 s/event(s)/event 16:09:29 q? 16:09:49 adamR: It seems reasonable 16:09:52 ..this is workable 16:10:03 ..as far as the spec goes 16:10:10 ...we'll need to convince the browser makers 16:10:21 i.e. AdamR persuaded me that an event with an empty option id is okay then JakeR persuaded us all that it's not :) 16:10:27 q+ I can talk about it 16:10:28 :D 16:10:31 ack rous 16:10:44 q+ 16:10:53 rouslan: We're not opposed to payment options in principle...if there is a case for them, please present the argument 16:10:58 ack JakeA 16:11:34 JakeA: In terms of getting browsers to implement this, going for the simplest thing in a way that allows us to add it later 16:11:48 ..take the extensible web approach. 16:12:22 q? 16:12:42 AdrianHB: Thanks for the proposal AdamR 16:12:55 AdamR: I don't think today's conversation affects the proposal as such.... 16:13:11 ...I think we can probably merge what's in the current spec...but it needs more details 16:13:43 AdrianHB: +1 to merge now 16:14:15 PROPOSED: merge AdamR's PR 16:14:19 +1 16:14:29 (IJ will update the running summary) 16:14:44 Topic: Next call 16:14:47 28 Feb 16:15:01 I have made the request to generate http://www.w3.org/2017/02/21-apps-minutes.html Ian 16:15:13 RRSAgent, set logs public 16:23:24 alyver has left #apps