search

w3c / payment-method-manifest

Specification for Web Payments payment method manifests
https://w3c.github.io/payment-method-manifest/
Other
9 stars 13 forks source link

Allow additional properties in manifest #43

Open adrianhopebailie opened 4 years ago

adrianhopebailie commented 4 years ago

It would be useful to merge the properties in this manifest with a Web App manifest where, for example, the payment method has a single app which is the default.

E.g. If a developer builds a payment app and hosts the app manifest at https://example.com/manifest.json they could also make this the payment method manifest by adding the properties:

The payment method identifier would then also be https://example.com/manifest.json

Can the following text be removed or modified to allow for this: The resulting JSON object must contain at most two items, with the possible keys "default_applications" and "supported_origins".

domenic commented 4 years ago

I'm hesitant about this. This opens us up to future compatibility hazards for both specs, if they ever end up with overlapping keys.

If we were to encourage merging of manifests, then I think we should just merge this spec into the web app manifest spec, so that they stay coordinated by the same editor group.

rsolomakhin commented 4 years ago

Ideally we'd have a clear suggestion to the web developers to either always merge or always separate the manifests. This will make implementer's job easier (one fewer feature to implement and test) and web developer's project planning easier (one less decision to make). @marcoscaceres - Do you have an opinion on the correct approach here?

cc @danyao

danyao commented 4 years ago

I agree with @domenic about the compatibility risk. Editors of both specs would have to keep this special use case top-of-mind with all future changes; otherwise, a simple name conflict may silently break something and be hard to debug. The benefit is not clear to me to be worth this risk.

I can support either merging the payment method manifest into the web app manifest spec, or vice versa per @domenic 's suggestion.

marcoscaceres commented 4 years ago

@marcoscaceres - Do you have an opinion on the correct approach here?

Web Manifest are tied to the document that declares the <link> relationship, including how CORS behaves when downloading sub-resources (e.g., the icons) - so default_applications really doesn't make sense, because it breaks the document -> manifest relationship.

If we move to a world where payment handlers are installed web applications (just like Web Share Targets are), then it would be appropriate for "supported_origins" to be part of Web Manifest, maybe under some new member like "payment_handler".

That would negate the need for this specification - but comes at the cost of supporting JIT. Personally, I think it's fine... we don't JIT Web Share Targets, so we probably shouldn't need to JIT payment handlers either.