Payment apps and methods, are they the same?

[rsolomakhin]

I argue that https://bobpay.xyz can identify both a payment app and a payment method.

A payment app may live in https://bobpay.xyz/sw.js and may be described in https://bobpay.xyz/payment-app.json. The JSON file should contain the app's title and icons at the very least. This is also a good place to specify a list of all payment methods that this app supports.

A payment method may be defined in https://bobpay.xyz/payment-method.json. This JSON file should describe who is allowed to use this payment method. This can be either unrestricted or a whitelist of payment app identifiers, i.e., URLs.

Thus we have both a payment app and a payment method identified by https://bobpay.xyz. To make things slighly easier for ourselves, let's say that the payment app https://bobpay.xyz should always support the the https://bobpay.xyz payment method.

To be more concrete, let's take a look at an ecosystem of 3 payment methods and 3 payment apps.

Payment methods

• https://alicepay.xyz is an unrestricted payment method, as specified in https://alicepay.xyz/payment-method.json:

{
  "externally_supported_apps": ["*"]
}

• https://bobpay.xyz is a singleton payment method. Only one app is allowed to use it. This is specified in https://bobpayx.xyz/payment-method.json:

{
  "externally_supported_apps": ["https://bobpay.xyz"]
}

• https://charliepay.xyz is a payment method that allows a whitelist of apps to use it. Specified in htps://charliepay.xyz/payment-method.json:

{
  "externally_supported_apps": [
    "https://bobpay.xyz",
    "https://charliepay.xyz"
  ]
}

Payment apps

• https://alicepay.xyz is a payment app that works with only one payment method. This is specified in https://alicepay.xyz/payment-app.json:

{
  "name": "AlicePay"
  "icons": [],
  // Web payment extension.
  "payment_methods": ["https://alicepay.xyz"],
  "payment_app_service_worker": "/sw.js"
}

• https://bobpay.xyz is a payment app that works with all payment methods in this ecosystem. Specified in https://bobpay.xyz/payment-app.json:

{
  "name": "BobPay"
  "icons": [],
  // Web payment extension.
  "payment_methods": [
    "https://alicepay.xyz",
    "https://bobpay.xyz",
    "https://charliepay.xyz"
  ],
  "payment_app_service_worker": "/sw.js"
}

• https://charliepay.xyz is a payment app that works with only two out of three payment methods, as specified in https://charliepay.xyz/payment-app.json:

{
  "name": "CharliePay"
  "icons": [],
  // Web payment extension.
  "payment_methods": [
    "https://alicepay.xyz",
    "https://charliepay.xyz"
  ],
  "payment_app_service_worker": "/sw.js"
}

Exact fields are not set in stone. The manifests are based on appmanifest.

[ianbjacobs]

Here is my model:

• Payment apps and payment methods are different animals. Apps are software, methods are rules, etc.
• In many cases, the entity responsible for the payment method will also create the payment app for that method. The responsible entity could also authorize other parties to distribute apps that support the payment method. We are calling these "proprietary" payment methods.
• After discussion with Zach, I am comfortable with payment method identifiers designating manifest files that explain "how to use the payment method in the ecosystem". We have not yet specified what can go in those manifest files, but I am comfortable with "a variety of information" including, for example, information about which origins are authorized to distribute payment apps for a given proprietary payment method, where to download those apps, etc. I imagine we will want to
  discuss how much flexibility to support in manifest files between "inline data" and "data available by reference."

Thus, I would say "Payment methods are not the same things as payment apps." Payment method identifiers will point at manifest files that allow different parties the flexibility to say what they want about BOTH the payment method and the apps that support it.

Ian

[rsolomakhin]

I think we are in agreement here, actually. Yes, apps are not methods, but
a single URL can both identify a payment app and define a payment method.

On Sep 7, 2016 8:01 PM, "ianbjacobs" notifications@github.com wrote:

Here is my model:

• Payment apps and payment methods are different animals. Apps are
  software, methods are rules, etc.
• In many cases, the entity responsible for the payment method will
  also create the payment app for that method. The responsible entity could
  also authorize other parties to distribute apps that support the payment
  method. We are calling these "proprietary" payment methods.
• After discussion with Zach, I am comfortable with payment method
  identifiers designating manifest files that explain "how to use the payment
  method in the ecosystem". We have not yet specified what can go in those
  manifest files, but I am comfortable with "a variety of information"
  including, for example, information about which origins are authorized to
  distribute payment apps for a given proprietary payment method, where to
  download those apps, etc. I imagine we will want to discuss how much
  flexibility to support in manifest files between "inline data" and "data
  available by reference."

Thus, I would say "Payment methods are not the same things as payment
apps." Payment method identifiers will point at manifest files that allow
different parties the flexibility to say what they want about BOTH the
payment method and the apps that support it.

Ian

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#35 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA-yGS5y27o69fjNUnRbRu1Z9RoTiyahks5qn3qNgaJpZM4J3fqZ
.

[ianbjacobs]

@rsolomakhin wrote:

I think we are in agreement here, actually. Yes, apps are not methods,
but a single URL can both identify a payment app and define a payment method.

That is the part that rubs me the wrong way. I would rather we say that these payment method identifiers designate information about a payment method's use in the ecosystem. And that's all they identify. The information may vary (and may involve apps!).

It may not matter from a technology perspective, but I find it confusing (at least from a communications perspective) to say that the URL identifies different things simultaneously.
I realize it may not bother others. :)

Ian

[rsolomakhin]

Should we recommend different URLs for apps and methods? For example, https://alicepay.xyz/app vs https://alicepay.xyz/method. The implication here being that browser will download https://alicepay.xyz/app/payment-app.json that defines the AlicePay payment app and https://alicepay.xyz/method/payment-method.json that describes the AlicePay payment method. Merchants would need to specify supportedMethods: ['https://alicepay.xyz/method'].

https://alicepay.xyz/app/payment-app.json example:

{
  "short_name": "AlicePay",
  "icons": [],
  "payment_methods": ["https://alicepay.xyz/method"],
  "payment_app_service_worker": "/app/sw.js"
}

https://alicepay.xyz/method/payment-method.json example:

{
  "externally_supported_apps": ["https://alicepay.xyz/app"]
}

It feels less cool, but is definitely more clear.

[ianbjacobs]

For proprietary payment methods, there's a reasonable case for combining payment method
and payment app information in a single manifest, controlled by the payment method owner.
Here's what I would expect to find in the manifest:

• Origins of parties authorized to distribute apps that support the payment method

• Links to payment app manifests, or the same data inline. If these are links, then
  presumably they would point to payment app manifests.

• Links to documentation (analogous to a payment method spec) about inputs
  and outputs for the payment method.

  Because the payment method owner controls the manifest, there are some security
  advantages to this approach.

For open payment methods, I think there's a stronger case for separation. It is not clear
what the payment method manifest would include. Indeed, we've been talking about
using short strings for W3C-published open payment method specifications, implying
no manifest is necessary. There is likely to be a payment method specification that
is of interest to app developers, but I have not heard support for using PMIs to
designate those specifications. Other parties publishing open payment method
specs might want to use payment method identifiers for this purpose.

So this means that:

• For an open payment method, there's not a big perceived need yet to be able to
  dereference the payment method identifier, but we need payment app identifiers to
  get payment app manifests (from the payment app distributors).
• For a proprietary payment method, there's value in having "one stop shopping"
  for manifest data via the payment method identifier. However, the payment method
  owner might want to reference payment app manifests rather than include them
  inline.

Some thoughts:

• I want to enable people to get payment app manifest information by dereferencing a URL.
• I want people to get payment method manifest information by dereferencing the
  payment method identifier (a URL).
• I don't want to say that payment app manifest data MUST NOT be found in
  a payment method manifest. I think we should not overconstrain here.

We've started to talk about "payment app identifiers" in the payment app spec:
https://w3c.github.io/webpayments-payment-apps-api/#payment-app-identification

Right now their usage is not very clear. However, I would support using them as follows:

• Data about an app (version, name, icons, etc.)
  • Link to get the app
  • Payment methods supported by the app
  • Any other data required for registration

As I said above, that same data could appear in a payment method manifest
and it would not bother me.

[rsolomakhin]

I pretty much agree with your broad brush strokes. The details can be worked out in the spec language.

[adrianhopebailie]

there's a reasonable case for combining payment method and payment app information in a single manifest, controlled by the payment method owner.

Agreed but we must not make the payment method identifier and the payment app identifier the same thing. A single identifier that identifies two different things is a horrible idea.

I am not a linked-data expert but I'm pretty sure that we can have a payment app manifest embedded inside a payment method manifest and have different URL's for both.

I'd like to hear from @ianbjacobs, @msporny or @dlongley (or anyone else that know this domain better than me) if having a payment method identifier of http://proprietarymethod.example.com/payment-method-manifest/ and a payment app identifier of http://proprietarymethod.example.com/payment-method-manifest/#default-app is legal (assuming that the payment app manifest object is embedded inside the payment method manifest and named default-app).

[adrianhopebailie]

A payment app may live in https://bobpay.xyz/sw.js and may be described in https://bobpay.xyz/payment-app.json. The JSON file should contain the app's title and icons at the very least. This is also a good place to specify a list of all payment methods that this app supports.

A payment method may be defined in https://bobpay.xyz/payment-method.json. This JSON file should describe who is allowed to use this payment method. This can be either unrestricted or a whitelist of payment app identifiers, i.e., URLs.

Thus we have both a payment app and a payment method identified by https://bobpay.xyz.

I don't like this model of fixed names for the manifests at all. This feels like the favicon debacle all over again. If you want to identify a payment method use the actual URL where the manifest file is not an origin that then gets converted into a URL by some magic formula.

If we used this model how could a single origin define multiple payment methods or apps?

If there is a desire to specify which origins can publish apps for a method then that can be the format for a specific property in the payment method manifest eg: allowed_app_origins : ["https://bobpay.xyz"] but the manifest can also specify specific apps eg: allowed_apps: ["https://bobpay.xyz/payment-app.manifest"] or even inline:

//Allow any apps from bobpay.xyz origin
allowed_app_origins : ["https://bobpay.xyz"],
//Also allow this specific app from alicepay.xyz
allowed_apps : [{
    "short_name": "AlicePay",
    "icons": [],
    "payment_methods": ["https://alicepay.xyz/method"],
    "service_worker": "/app/sw.js"
  }]

[ianbjacobs]

@adrianhopebailie wrote:

"I don't like this model of fixed names for the manifests at all."

See related comment from @marcoscaceres:
#33 (comment)

[adrianhopebailie]

@ianbjacobs - not sure I see why this is related?

My point is, we shouldn't have an identifier of http://bobpay.com if the manifest URL is http://bobpay.com/payment-manifest.json.

Use the ACTUAL URL of the manifest as the identifier.

[ianbjacobs]

@adrianhopebailie wrote:

"..not sure I see why this is related?"

My fault. I in my haste I conflated two topics that have been uttered in the context of network performance optimization:

• All method/app manifest data in one file
• URL patterns for manifest files, which enable a browser to auto-fetch the data.

Ian

[jakearchibald]

Use the ACTUAL URL of the manifest as the identifier.

Is the service worker is doing the processing, then the service worker's scope should be the identifier. It's the primary key here.

[adrianhopebailie]

When I said:

Use the ACTUAL URL of the manifest as the identifier.

I was referring to the payment method manifest

For the payment app identifier I agree.

To confirm: The scope is a URL and it is relative to the URL of the service worker .js file?

Also: Is it possible to publish a service worker with a scope "higher" than the path of the .js file?
i.e. Can the sw at http://example.com/~bob/sw.js declare it's scope to be http://example.com/~alice/?

[jakearchibald]

The scope is a URL and it is relative to the URL of the service worker .js file?

The default scope is ./ relative to the script URL, but it can be set manually.

navigator.serviceWorker.register(url, {scope});

[jakearchibald]

Also: Is it possible to publish a service worker with a scope "higher" than the path of the .js file?

Only if the script has a response header Service-Worker-Allowed containing the maximum allowed scope.

[adrianhopebailie]

Only if the script has a response header Service-Worker-Allowed containing the maximum allowed scope

Perhaps I am misunderstanding but that means the sw at http://example.com/~bob/sw.js can declare it's scope to be http://example.com/~alice/ and the thing that allows this is the service that serves the http://example.com/~bob/sw.js script.

i.e. Bob gives Bob permission to set his scope to be Alice

[jakearchibald]

Yeah, as you said in another thread the only real security boundary on the web is an origin. If this was widely understood, http://example.com/~bob/sw.js would be able to control the whole origin, no questions asked. Unfortunately a lot of the web is built assuming ~username is a boundary, so we added the scoping restrictions.

Some history: https://jakearchibald.com/2014/launching-sw-without-breaking-the-web/

[adrianhopebailie]

Unfortunately a lot of the web is built assuming ~username is a boundary, so we added the scoping restrictions.

I think I am still misunderstanding. because it seems like the entity controlling Bob's restrictions is Bob himself. He sets the Service-Worker-Allowed header when the browser fetches his sw so he can decide that he will give himself access to ~alice.

[jakearchibald]

Yep, if ~bob has that degree of server control he can do that. We're only protecting static servers.

[adrianhopebailie]

Yep, if ~bob has that degree of server control he can do that. We're only protecting static servers.

I have to say that feels a bit scary. Maybe I am being naive but are there other ways that allowing a user to specify headers in a response effectively gives them control of the origin?

[jakearchibald]

If you can run script on the origin you already have control of the origin. The security boundary is the origin - weren't you quoting that at me a day or two ago? That's where all the storage etc is scoped to.

Service worker made a concession for naive static hosts. It's shipped like this for a couple of years now in multiple browsers. If this is something you want to dig up & go round and round on, this isn't the thread or repo.

[adrianhopebailie]

If this is something you want to dig up & go round and round on, this isn't the thread or repo.

👍 no, that is not my intent 😄

Thanks for the help in understanding this stuff, still a bit fuzzy for me but certainly getting clearer.

[rsolomakhin]

I think my question was resolved.