Proposed changes for #95 (and #96)

[adamroach]

No description provided.

[bentian]

The interface name conflicts with PaymentOptions dictionary. May this get confusing?

[bentian]

an extra 'A' here

[tommythorsen]

Replacing setManifest/getManifest with the options attribute seems like a good change, but I'm not so sure about the wallets attribute.

While we have talked about the usefulness of being able to let a single origin contain multiple "Apps" that again can contain multiple "Options", I don't necessarily think that containing this entire hierarchy inside of a single Service Worker is a good idea. Will each of these "Wallets" typically be presented to the user as an "App"? Or will they again be grouped inside another "App" container?

[adamroach]

@tommythorsen -- The notion here is to allow payment app developers to structure their service workers in whatever way makes sense for them, independently of how they wish options to be presented to the users. The current proposal would allow multiple service workers to handle different options within the same wallet, or a single service worker to handle multiple wallets. There seems no reason to artificially constrain the way applications structure their service workers just to change how things are presented to users.

In terms of rendering, what I would expect -- since wallets are optional -- is that browsers would show app-level information for payment apps without wallets, and wallet-level information for payment apps with. They would appear "at the same level," so to speak.

So, for example, if American Express had registered two wallets (one app!), and Bank of America had registered one app (but not used the wallet concept at all), it would be reasonable to render this to the user as:

[tommythorsen]

@adamroach: In the screenshot above, have you given any thought to where the "Bank of America" string and the red Bank of America icon should come from? I'm interested in starting to implement some of these things, or at least write some example code, but I have a hard time nailing down where "App" level information should exist, and even what a "Payment App" really is.

Maybe we should specify "App" level information from the Service Worker too? Maybe something like:

interface PaymentAppManager {
    attribute PaymentAppDetails app;
    attribute PaymentAppOptions options;
    attribute PaymentWallets wallets;
};

dictionary PaymentAppDetails {
    DOMString appKey;
    required DOMString name;
    sequence<ImageObject> icons;
};

[adamroach]

@tommythorsen --

In the screenshot above, have you given any thought to where the "Bank of America" string and the red Bank of America icon should come from?

The notion here is that the service worker has been registered from some context (i.e., an HTML page), and that context provides information specific to the web app. I'm hardly an expert here, but my understanding is that modern web browsers get the name from:

• The Web App Manifest indicated in the HTML via <link rel="manifest" href="name of manifest file">
• If that is not present, indicated in the HTML via <meta name="application-name" content="app name">
• If neither is present, via <title>app name</title>

Similarly, the icon comes from:

• The Web App Manifest indicated in the HTML via <link rel="manifest" href="name of manifest file">
• If that is not present, indicated in the HTML via <link rel="icon" href="icon location">
• If neither is present, from /favicon.ico

To be clear, I'm not proposing this per se; it is my understanding that this is how Web Apps in general are assigned names and icons for presenting to users. If we decide that this model isn't appropriate for payments, I don't personally have a problem with changing it -- but if we have an already-established pattern and set of tools for this kind of thing, we'll need some clear reasons for doing things another way.

[tommythorsen]

@adamroach I agree with that way of doing it. I think that the only time this information is available to us, is at the time when we register the Service Worker. We'll probably need to pick the information out of the browsing context somehow, and store it along with the other information in the PaymentAppManager.

What do we do if the Payment Provider would like to rebrand, and change the name and icon that belongs to a Payment App? Aren't we going to need some way to update these from the installed service worker?

[ianbjacobs]

@tommythorsen wrote:

"What do we do if the Payment Provider would like to rebrand, and change the name and icon that belongs to a Payment App? Aren't we going to need some way to update these from the installed service worker?"

Wouldn't that be taken into account the next time I visit the site? (There may be a separate issue about how caching is managed for this information, but that seems out of scope for our spec.)

Ian

[adrianhopebailie]

@tommythorsen wrote:

"What do we do if the Payment Provider would like to rebrand, and change the name and icon that belongs to a Payment App? Aren't we going to need some way to update these from the installed service worker?"

Isn't this up to browsers to define? Do we need to specify anything as relates to UI? The Service Worker life cycle is already well-defined.

[tommythorsen]

@ianbjacobs

Wouldn't that be taken into account the next time I visit the site? (There may be a separate issue about how caching is managed for this information, but that seems out of scope for our spec.)

Well, each page within the site can have different icons and names. It would be feasible to update this information every time the user visits the exact same web page from which they originally registered the service worker. However, how likely is it that they will ever visit that exact page again? The service worker was probably registered from some kind of a "signup" page. Why would the user go there again?

@adrianhopebailie

Isn't this up to browsers to define? Do we need to specify anything as relates to UI? The Service Worker life cycle is already well-defined.

I think this is up to us to define. We have introduced these names and icons, and it's up to us to define their entire life cycle.

It would be nice if we could inherit this behavior from the Web App Manifest specification, but that particular section is not very helpful. In light of this, it doesn't seem unreasonable to postpone thinking about updating this information until after v1 of our specification, though.

[dlongley]

I think this is up to us to define. We have introduced these names and icons, and it's up to us to define their entire life cycle.

Can we spec it such that when the service worker is updated, the icons/other information will be updated as well?

[adrianhopebailie]

I think this is up to us to define. We have introduced these names and icons, and it's up to us to define their entire life cycle.

Can we spec it such that when the service worker is updated, the icons/other information will be updated as well?

My point is, I don't think we can even define how the browser gets the icons and labels without treading in dangerous security territory.

As a develop I can register a bunch of options that I want the user to be prompted with but ultimately, how those are rendered to the user is up to the browser. Will they have icons and labels at all?

Before we spend too many cycles figuring out how to specify the icons and labels let's agree that the browser will use them.

As a sidebar, and illustration of the security risks, PayPal is being phished extensively by scammers that have got SSL certs from LetsEncrypt and thereby showing the "green bar of safety" to users.

Any visual affirmation a user gets that a payment app published by a reputable brand should be carefully controlled, especially if it is shown inside browser generated UI.