-
Notifications
You must be signed in to change notification settings - Fork 42
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Payment apps and methods, are they the same? #35
Comments
Here is my model:
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 |
I think we are in agreement here, actually. Yes, apps are not methods, but On Sep 7, 2016 8:01 PM, "ianbjacobs" notifications@github.com wrote:
|
@rsolomakhin wrote:
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. Ian |
Should we recommend different URLs for apps and methods? For example,
{
"short_name": "AlicePay",
"icons": [],
"payment_methods": ["https://alicepay.xyz/method"],
"payment_app_service_worker": "/app/sw.js"
}
{
"externally_supported_apps": ["https://alicepay.xyz/app"]
} It feels less cool, but is definitely more clear. |
For proprietary payment methods, there's a reasonable case for combining payment method
For open payment methods, I think there's a stronger case for separation. It is not clear So this means that:
Some thoughts:
We've started to talk about "payment app identifiers" in the payment app spec: Right now their usage is not very clear. However, I would support using them as follows:
As I said above, that same data could appear in a payment method manifest |
I pretty much agree with your broad brush strokes. The details can be worked out in the spec language. |
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 |
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: //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"
}] |
@adrianhopebailie wrote: "I don't like this model of fixed names for the manifests at all." See related comment from @marcoscaceres: |
@ianbjacobs - not sure I see why this is related? My point is, we shouldn't have an identifier of Use the ACTUAL URL of the manifest as the identifier. |
@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:
Ian |
Is the service worker is doing the processing, then the service worker's scope should be the identifier. It's the primary key here. |
When I said:
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? |
The default scope is navigator.serviceWorker.register(url, {scope}); |
Only if the script has a response header |
Perhaps I am misunderstanding but that means the sw at i.e. Bob gives Bob permission to set his scope to be Alice |
Yeah, as you said in another thread the only real security boundary on the web is an origin. If this was widely understood, Some history: https://jakearchibald.com/2014/launching-sw-without-breaking-the-web/ |
I think I am still misunderstanding. because it seems like the entity controlling Bob's restrictions is Bob himself. He sets the |
Yep, if |
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? |
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. |
👍 no, that is not my intent 😄 Thanks for the help in understanding this stuff, still a bit fuzzy for me but certainly getting clearer. |
I think my question was resolved. |
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 inhttps://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 apphttps://bobpay.xyz
should always support the thehttps://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 inhttps://alicepay.xyz/payment-method.json
:https://bobpay.xyz
is a singleton payment method. Only one app is allowed to use it. This is specified inhttps://bobpayx.xyz/payment-method.json
:https://charliepay.xyz
is a payment method that allows a whitelist of apps to use it. Specified inhtps://charliepay.xyz/payment-method.json
:Payment apps
https://alicepay.xyz
is a payment app that works with only one payment method. This is specified inhttps://alicepay.xyz/payment-app.json
:https://bobpay.xyz
is a payment app that works with all payment methods in this ecosystem. Specified inhttps://bobpay.xyz/payment-app.json
:https://charliepay.xyz
is a payment app that works with only two out of three payment methods, as specified inhttps://charliepay.xyz/payment-app.json
:Exact fields are not set in stone. The manifests are based on appmanifest.
The text was updated successfully, but these errors were encountered: