Multiple payment apps per origin #98
Comments
|
This sounds like a very artificial limitation to me. What is the advantage? Our Payment Apps are pretty much just Service Workers. Service Workers are limited to one per scope (not one per origin), why should Payment Apps be different? |
|
Sorry, there was clearly some bad wording on my part: I was not proposing 1 per origin. What I was trying to say is, you can register as many service workers as you like, but the "feature" is controlled per origin (like any other power feature). Like all other browser features:
|
|
I want to be clear, my reaction is to the misnomer that there is a "payment app". There is no "Payment app", just like there is no "Geolocation app", and no "Push Notification App" - supporting "payment handling" is just another (permission gated) powerful feature - there is nothing special about these kinds of web applications. |
|
And even going further, one could even display the number of registered payment methods like this:
... but now I'm going off the rails. Anyway, I hope that clarifies things further. |
There's one "push notification" permission per origin, but there's up to one "push subscription" per service worker, meaning there can be many per origin. I've taken "payment app" to be akin to "push subscription". I agree that the permission part is per-origin. |
|
On 24 Jan 2017, at 11:13 pm, Jake Archibald ***@***.***> wrote:
@marcoscaceres
There is no "Payment app", just like there is no "Geolocation app", and no "Push Notification App" - supporting "payment handling" is just another (permission gated) powerful feature - there is nothing special about these kinds of web applications.
There's one "push notification" permission per origin, but there's up to one "push subscription" per service worker, meaning there can be many per origin.
I'm trying to say exactly what you just said. Language is hard :(
I've taken "payment app" to be akin to "push subscription". I agree that the permission part is per-origin.
That's also exactly how I'm viewing it. Why I don't like the whole "payments app" thing (and I think saying "app" is leading to problems and poor design choices) - it's a subscription of sorts... just another "powerful feature", as per Permission API parlance.
… —
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
We had lonnnnnnnng discussions about how to talk about this work with people. We did not like the term "digital wallet" as it is overloaded. We chose "payment app" to say "The software that you pay with". We have invested a lot in the phrase "payment app" for communications purposes and I would not throw it out lightly. Ian |
|
On 25 Jan 2017, at 1:12 am, ianbjacobs ***@***.***> wrote:
We had lonnnnnnnng discussions about how to talk about this work with people. We did not like the term "digital wallet" as it is overloaded. We chose "payment app" to say "The software that you pay with". We have invested a lot in the phrase "payment app" for communications purposes and I would not throw it out lightly.
You don't need to. No spec talks about "progressive web apps", for instance; yet we have a good understanding of the tech that comes together to form them.
So please don't mix marketing and communication with normative prose - that just makes for really bad times - and it's clear to see how it's already led to poor design choices in this spec (the manifest duplication).
… Ian
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
We were not planning to duplicate the manifest. We had an open issue to discuss with you how to manage this since we recognized the overlap. This conversation is part of clearing all that up. I would not call it a bad design choice because our goal has always been to avoid duplication...we just haven't had all the answers until these recent threads. I am convinced we need a term to refer to what we are currently calling payment apps, and that term should be part of the specification. I support cleaning up the normative text to stay closer to Web primitives. Ian |
If that's the case, then this seems to be a matter of simple confusion. I agree that payment permissions need to be managed in the same way we manage other permissions. But this doesn't for the basis for "identification" of an app. If you agree, then it would appear that this is a simple matter of confusion, and we can close the issue. [@ianbjacobs: I'd like to hear positive confirmation from @marcoscaceres before we close the issue] |
This is an oversimplification. A browser does not have many geo-location handlers or push-notification handlers. There are two sides to payments: does an origin have permisson to request payments and does it have permission to handlepayments? But there is also more granularity. Can a specific ServiceWorker handle payments for a specific payment method and is it permitted to do so. I am hearing @marcoscaceres say that, per the web security model, we cannot assign different permissions to two Service Workers from the same origin (i.e. app1 has permission to handle basic-card payments and app2 has permission to handle bobpay). I don't think this is a problem as the notion of 'supporting" a payment method is different to the notion of having permission to handle a payment method. WRT terminology, since these components are able to spin up a new UI and therefor present a fully featured application to the user I think the terminology app is appropriate. Any software architecture literature I have read refers to handlers as simple functions that process events or messages. These are usually a component of larger application or (as they are often called on the Web platform, an app). Nothing in the current design prevents the Service Worker that handles the payment request from also performing a plethora of other functions that are part of a larger application. On the topic of "manifest duplication", I personally attempted, on more than one occasion, to engage the editors of the app manifest specification to provide input into this work or review our use case. Specifically I wanted to find ways to re-use parts of app-manifest without duplicating it but those attempts, to put it politely, didn't end well, so let's leave that there. |
We're not talking about those kinds of permissions. We're talking about "do you give example.com permission to install a payment app in your browser?" This is going to be a "yes/no/always/never" kind of thing set on the origin, just like all other browser permissions. |
|
Tl;dr: @adamroach, indicating in the affirmative. Please close this issue. @adrianhopebailie, wrote:
I'm really sorry that we the Editors let you down - but the reality is that what you were asking for didn't make any sense to us, which is why we were doing so much head scratching when you reached out to us. We were all like, "...but... we already provide all that stuff, why do you want it again?". Anyway, just trust the page to include: |
Based on your recent comment "...the "multi-paypal" example is totally bogus. If there are two totally different things, then they would be in totally different origins (hence different apps).", it sounds very much like you still think that there can be only one payment app per origin -- so I don't think this is ready to close until you've explained more completely what you mean. |
|
Wish we could stop calling them "apps"... it's making this really confusing (because these things are inside web apps). Anyway, In the other bug I said:
why we should not allow multiple payment handlers.
|
|
I am +1 to only having one payment app per origin. |
|
We must differentiate between the permission a user grants to an origin to "handle payment requests" and the ability of a payment app (a Service Worker with a scope under that origin) to handle payment requests for a specific payment methods. Therefor there are two things that happen:
I think we must still decide if 2. requires user consent, this feels like a separate issue. Concrete proposal to close THIS issue:
|
|
@adrianhopebailie, you wrote: "I am +1 to only having one payment app per origin." Please say more about versioning in this case. Ian |
|
Given that an origin can have multiple service workers, I can't see how "one per origin" works, nor what it achieves. |
|
On 25 Jan 2017, at 11:18 pm, Jake Archibald ***@***.***> wrote:
Given that an origin can have multiple service workers, I can't see how "one per origin" works, nor what it achieves.
Wait, no - maybe the terminology has also confused you?: one can have as many Service Workers as one likes using the API (each having N registered payment methods). Just that only one "web app" shows up in the "Select how you want to pay" dialog on the merchant's site.
Works exactly the same as any other SW using feature. Should be the same as Push Notifications.
… —
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
@marcoscaceres Are you saying the browser merges all the payment methods across an origin's service workers? An origin can have many active push notification subscriptions. |
|
On 26 Jan 2017, at 3:09 am, Jake Archibald ***@***.***> wrote:
@marcoscaceres Are you saying the browser merges all the payment methods across an origin's service workers?
I'm unsure if they are merged at this point. I don't think they should merge (depends also what merge means in this context).
An origin can have many active push notification subscriptions.
The same here: you could have many active payment handlers.
… —
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
@marcoscaceres -- Wait, what? You seem to be all over the map on this. You previously said:
const reg1 = await serviceWorker.register("app1.sw");
const reg2 = await serviceWorker.register("app2.sw");
reg1.paymentManager.setName("SUPER COOL CARD MANAGER");
reg1.paymentManager.setIcon("super-app1.png");
reg2.paymentManager.setName("I'M A TOTALLY DIFFERENT CARD MANAGER");
reg2.paymentManager.setIcon("TOTALY_DIFFERENT_APP.jpeg");
await Promise.all([reg1.paymentManager.register(), reg2.paymentManager.register()];But now you seem to be saying it's... okay? Or maybe okay? I'm getting whiplash trying to follow your can-or-can't have multiple payment apps[1] per origin. [1] Which, for avoidance of doubt, is the term we have been using as shorthand for "service worker that is registered to handle one or more payment methods." |
I think that would be the height of confusion. @adrianhopebailie's example using business and personal apps from the same bank seems highly realistic, and mashing together the personal and business payment options to make them look like one thing is exactly wrong. |
|
Hi all, another perspective: It is highly likely that a PSP may want to host many payment apps on a single origin. For example many whitelabelled apps on behalf of various merchants. I would not consider this an edge case. |
|
@adamroach wrote:
I've not changed my position, AFAICT - but I clearly didn't articulate my position well and kept getting confused by the existing terminology (which is why I provided code and images, which are subject to less ambiguity). From my very first proposal, I held that I view "payment web apps" as single origin progressive web apps - meaning you could have as many service workers registered to handle requests per payment as needed. I.e., they were exactly the same as any web application today. Sorry if I was not clear. Also, should I, or anyone, change their position by coming to a new understanding in light of new information, that's a good thing - not something to be mocked. I'm not here because I like s***posting or making an ass of myself. If I am wrong, or proved wrong, I will be totally happy with that. But I will continue to question as to assure that this is the best solution for users, developers, merchants, payment processors, implementers and the Web as a whole. I still think we can do better - and we are a long way from anything I would support publishing as a FPWD or would feel comfortable taking back to Mozilla to allow us to consider implementation.
That's not the definition I was using - and that definition is the source of all confusion (which is why I removed it from my counter proposal - and continue to argue to drop it from this spec too). The definition I was using was from a user's and developer's perspective (and basically what everyone else in the web community would call these things, and how user's would understand them): "web apps that can handle payments". This image (the actual web application) represents what is meant (wallet.com is a payment app):
A end-user would see when making a purchase:
(one web application: multiple payment methods) Thus, "a payment app is a web application that is registered to handle requests for payment via one or more payment methods. Payment methods are processed via one or more service workers". If we can get behind a logical definition, that is consistent with the rest of the web platform, then we can stop all the confusion. Now, with regards to permissions we could even refine the proposal as follows: // Register once on static PaymentManager method.
PaymentManager.requestPermission().then(async result => {
// can do both Visa and Amex
const multiHandler = await serviceWorker.register("visa_and_amex.js");
// can do only MasterCard
const masterCard = await serviceWorker.register("mastercard.js");
// Add payment methods
await multiHandler.paymentManager.methods.set("visa-4756", {
name: "Visa",
methods: ["basic-card"],
icons: [...visaIcons],
});
await multiHandler.paymentManager.methods.set("amex-5361", {
name: "Amex",
methods: ["basic-card"],
icons: [...amexIcons],
});
await masterCard.paymentManager.methods.set("mastercard-1234", {
name: "MasterCard",
methods: ["basic-card"],
icons: [...mastercardIcons],
});
});@adrianhopebailie wrote:
I'm of the opinion that the web application need not ask a user for consent to manage payment methods. It should be a goal of this spec to enable developers to build apps like "wallet.com" above - which include saving payment hander details, handling the payment processing (in coordination with payment processors), and being able to store shipping/billing information, and whatever else will help to make for a speedy checkout experience. I can't build "wallet.com" if I have to annoy the user every time they want to add or modify a payment method. Lastly, as an implementer, I want developers to have exactly the same API that we would use to build a card management interface in Firefox - this includes Firefox also having to ask for permission to handle credit cards on behalf of the user, etc. I don't want the browser to have any special things that are not available to developers unless there is some demonstrable privacy or security restriction that can't be handled in any other way (e.g., in fetch API, developers can't override certain headers for security reasons - I want the same here, where it makes sense). Again, in pictures, to reduce ambiguity: Firefox settings to manage credit cards and wallet.com are the same thing, and must use the same APIs:
In fact, I should be able to host Firefox's credit card manager at "mozilla.com/manage-payments" or whatever, without requiring any browser-only APIs. If this spec doesn't let me do that, then it's not meeting the use cases. |
|
You wrote: "A payment app is a web application that is registered to handle requests for payment via one or more payment methods. Payment methods are processed via one or more service workers". Here are my annotations:
What about this, merging your text with some of the text in the task force's spec, something like: "A payment app is software that enables the user to fulfill a payment request for one or more payment methods. A payment app that conforms to this specification is a Web application where one or more service workers handle the payment request and response." Regarding consent from the user:
Ian |
Sure, but they are not our concern.
The above is confusing, because you are defining the same thing twice. |
|
What I like about the first sentence is that it is user-friendly and implementation independent. "A payment app enables the user to fulfill a payment request for one or more payment methods. A payment app that conforms to this specification is a Web application where one or more service workers handle the payment request and response." |
Can you clarify the above - I don't understand what that means? |
|
Hi @marcoscaceres, We are still discussing the topic what the browser shows to the user (and how much detailed information the payment app might want to supply) so that the user can choose a payment app to pay. Although that topic is still open, we have consensus that IF we support the payment app providing detailed options to the browser, the browser is NOT REQUIRED to ALWAYS display that AdamR is working on a proposal that enables the payment app to provide information to the browser, which can then choose whether and when to make use of it to improve the user Ian |
|
@ianjacobs, @adrianhopebailie, @marcoscaceres and others: I have spent some time reading the specs and thinking about how we can connect Payment Apps and Service Workers / Payment Options, and I've written down a few thoughts and some very rough algorithms here: https://github.com/tommythorsen/webpayments-demo/blob/gh-pages/proposals/Apps%20and%20Workers.md WDYT? |
It is true. See https://w3c.github.io/ServiceWorker/#register-algorithm - at 4 it gets an existing registration of that scope and updates it if it exists. This ensures you can't register two service workers with the same scope.
This isn't useful for payments. You don't want to associate an app with a service worker, you want to associate with a service worker registration, otherwise you'll lose payment apps during a service worker update.
If we do something about that issue, we won't be adding multiple registrations for a single scope. APIs already assume that scope to registration is 1:1, eg https://w3c.github.io/ServiceWorker/#navigator-service-worker-getRegistration. |
|
Aha, I had missed that part of the algorithm. Thanks @jakearchibald! I'll update my text. This won't actually make any difference for the algorithms, though, since we can't match this scope against those of the Service Workers. |
|
Hmm, what have I missed? I thought we agreed that payment apps should be identified by their service worker scope, since they're stored against the service worker registration. |
|
That was true a couple of iterations ago. Since then, we've redefined the term "Payment App". It used to mean "a Service Worker that can handle payments", but it now means "a Web App that can handle payments". The service workers are still used to register Payment Options and subscribe to Payment Request events, though. |
|
Is there a summary for this change including reasons? |
|
Here's a running summary of key issues and where I think we have consensus (and don't): On this topic specifically:
Ian |
|
Also @dlongley's comment from earlier in this thread was a pretty good explanation.
I mention this particular statement in the introduction to my proposal document. I have no idea how identifying apps by their origin could ever work, and I strongly suggest we consider some other form of identifier. I propose to use the url to the Web App Manifest file. |
|
Here is my understanding of where we have arrived:
My summary, therefore, is that there is not currently a need for a special "payment app identifier." (I welcome comments on whether this is a fair summary, what is missing, etc.) |
This is the key IMO. Well put. It seems that what many of us are calling "apps" only ever have to identified explicitly as "user choices". If I re-write my set of choice from before it would look like this: What is not clear to me yet is what combination of Service Worker registration code and calls to |
|
I disagree with the "A Payment App is an origin" definition that you are arguing above. I really liked the "A Payment App is a Web App that can do payments" definition that I thought we had some consensus on. I think most people's idea of the concept "Web App", is that it is the collection of web pages that are related to a particular Web App Manifest. I think most people think of a "Web App" as the thing you can install to the home screen of your phone if you're on a page that links to such a manifest. I think most people do not think that a "Web App" is an origin. I know the permissions model works on origins but that, I believe, is unrelated to the concept of a "Web App" and to the concept of a "Payment App".
I agree with this. But in my opinion, the above statement is not compatible with your earlier statement: "We are currently planning to identify payment apps by their origin". Any disagreements we have here are likely to be caused by us having differing definitions of the term "Payment App" or of the term "Web App". If I seem to be spouting complete gibberish, please take a moment to consider your definitions, and whether or not they match mine, which I have laid out in the initial paragraph of this comment. |
This is exactly what I hope to address in my PR. I should have a concrete proposal to talk about on our call on Tuesday. |
|
@adrianhopebailie said:
I agree with this. All we need to do is specify:
I think origins and permissions are orthogonal to this particular problem. We already have a clear model for those: An origin requests permission to "handle payment" -- and, if granted, they may then specify whatever choices they want, whenever they want to (they can change them at will). We just need to pin down exactly what the API looks like for specifying choices and how the browser will communicate user selections back to the developer in a way that they expect. There is a secondary piece to the "how developers specify choices" which involves the ability to group choices so users can make more fine grained selections if the browser wants to expose this in their UI (but it likely isn't a requirement). @adrianhopebailie's comment shows an example of this. I don't know that we even care what the identifiers are for the choices. Those could be left entirely up to the developer. All that needs to happen is the browser must effectively communicate them back to the developer once a user has made their selection. What is important is that the developer knows how to write the code to receive the selections. It may be that a particular Service Worker |
Yes, this is what we need to figure out next. My proposal suggests that the second level of your hierarchy comes from the Web App Manifest, and that the third level is provided (by means of |
|
If an origin is an installed payment app, and that origin has 10 service worker registrations, which service worker gets the What happens if that service worker registration is unregistered? Is the payment app still installed? My understanding is the payment app would no longer be installed, as it no longer has somewhere to fire the If my understanding is correct, there's a very definite 1:1 relationship between a payment app and a service worker registration. Given that a service worker registration has a primary key in the form of its scope URL, this is the only straight-forward way to identify an installed payment app. Don't be distracted by permissions. Just because a permission is origin-level doesn't mean an instance of the feature is. Take notifications - the permission is origin level, but there can be many notifications from an origin at once. Also, although there's one push origin permission, each service worker registration can have its own push registration, and they're tied to the life of the service worker registration. Don't be distracted with "recommended payment apps". As far as I know, no one has been able to define how this could happen without presenting large security issues #48 (comment). Don't be distracted by doing work across multiple service workers for a single payment. If the payment app chooses to open a window, it can do so to any page on its origin. That means the page could be controlled by another service worker to the one that owns the payment app registration. Also, one service worker can message the others on the same origin. However, the payment app is still registered against a particular service worker registration. Don't get hung up on the definition of a "web app". Some web apps take up a whole origin, some origins have many. Some web apps have zero service workers, some have one, some have many. Hell, some service workers span across multiple apps. Ignore all that, the definition is fuzzy. This group should define how a website can register a web payment provider, independent to whatever concept the developer has of a "web app". |
A developer may want to group multiple payment options under a single "Payment App", but implement different options via different service worker registrations. A Payment App may have more than one payment option that it registers. Imagine a scenario where the Payment App uses two service worker registrations, A and B. Service worker registration A could register payment option 1 and, therefore, its active service worker will receive the As long as some payment option is registered for a particular Payment App and the service worker registration persists, then the Payment App is "installed". |
What's the benefit of allowing this (given the massive complication it brings)? |
Seems like a natural division of code. As a developer, you may want to implement payment method X in service worker script I think the difficulty here may still be related to the terminology. I think we should stick to saying that what we register is a "payment option" -- and when the user selects that payment option, a So, from that perspective, I don't understand why we should force the developer to divide their code such that all options that will be grouped together must be handled via the same script. However, if this restriction is required in order to avoid "massive complication", then it's worth imposing it. I just don't know what "massive complication" you're referring to. Thinking through it further now, I can see an unfortunate complication -- that only arises, I believe, from the fact that we don't plan on requiring browsers to surface more granular options. If we register these payment options from @adrianhopebailie's example above: One browser may surface these as simply: While another may show the full granularity of the options for user selection. Given this fact, it will be difficult for a developer to know which service worker script would receive the |
|
Service workers can already import scripts, and that gets even easier with es6 imports. So it isn't true that we'd be forcing developers to use the same script. The benefit of spreading payment options across multiple service workers isn't really clear, and doesn't fit in with how other service worker APIs work. Feels like we need stronger reasoning given how much this complicated the API. By adopting something that wraps service workers, you're now having to define a whole new life cycle. Also, developers will have to manage the life cycle of service workers within this life cycle. I think this complicated approach makes implementations unlikely. |
I didn't mean to imply that there wasn't an alternative route to accomplishing code division, but we are closing off one route for doing it. My default position is: Don't close off routes for developers unless you have a good reason to. If there would be "massive complication" if we didn't close off one route then that's a perfectly good reason to do it, especially when we can offer the developer a slightly different alternative to what they'd like to do. I'm just not sure what the massive complication is that you're referring to. However, I have specified a concrete complication above that I think is sufficient to warrant restricting payment option registration in the way that you suggest. So we're in agreement now, but perhaps for different reasons.
My suggestion above was not to wrap service workers, it was to decouple grouping information. It was to simply let the developer say, in a service worker registration: "Offer this option to the user and show it under the banner of payment app X." If no service worker registrations exist with payment options for payment app X, then nothing is shown under payment app X (it doesn't exist). There is no additional life cycle beyond service workers and nothing new to manage. Anyway, this doesn't work because some browsers may only implement choosing the Payment App directly, not granular choices underneath its "banner" -- and then the developer wouldn't know where to expect to receive |
|
Closing this issue as new mechanism ("wallet") has been added to the spec. |
|
In light of FTF discussion on 24 April [1], I am reopening this issue in order to put a marker in the FPWD. |
|
This was resolved in the WG call on 20 July. The "wallet" has been removed however a reference to this issue remains in the spec as it may be re-added if there is sufficient demand. This issue provides valuable context to anyone investigating the topic. |
Currently, the Payment App spec allows an origin to host as many payment apps as they want to (e.g., to allow for different versions, different account types, etc.). In @marcoscaceres' Payment Request Handler document, he proposes that origins be limited to hosting a single payment app.
I think this proposal is problematic. I'm opening this issue to allow discussion of support for and opposition of such a constraint.
The text was updated successfully, but these errors were encountered: