-
Notifications
You must be signed in to change notification settings - Fork 56
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
Web payment method manifest #162
Comments
We now have a spec: https://domenic.github.io/payment-method-manifest/ |
Presumably feedback should now be filed as issues in the repo, right? There's now a blink intent to ship for this. |
Yep, good idea to file the issues here. |
One thing that came up in the TAG's initial 10-minute timeboxed discussion was the privacy implications here, that is, the question of when are these resources (the payment method identifier, the web payment manifest, the payment application manifest) are retrieved. But we'll discuss more in a subgroup. |
And another question that came up was the question of whether the level of indirection of retrieving one resource and looking at a Link header on it, rather than just using the URL of the manifest as the identifier, was a good idea or not. |
We had some further discussion of this, in the same two areas discussed above: Privacy@triblondon points out that one way the browser could obscure which users use merchants that use a particular payment is by the browser proxying the retrieval of the manifests through a central server, if it wanted to do so. We should file an issue against the spec that it should have a Privacy Considerations section, which should discuss the issues where some of the parties involved can learn things about what others are doing in possibly unexpected ways, and what could be done to mitigate that. Indirection in manifest retrievalThe justification the spec offers for the extra level of indirection is that the URL that is the identifier is designed to be more human-readable. @triblondon walked through some possibilities:
|
The pending external feedback label seems a little insufficient here. We recorded discussion of two issues in #162 (comment) above. For the first (Privacy), an issue has been filed and acknowledged (but not fixed). For the second (Indirection in manifest retrieval), we don't seem to have solicited any external feedback yet. We presumably should decide if we want to recommend one or more of the four possible courses we enumerated above. |
Discussed in today's TAG teleconference. There seemed to be the most support (and no objection) behind option 2 above:
I'll open an issue in the spec's repository about this issue. |
Can you expound a bit more on that? This is in direct contradiction to a decision the WG made some time ago, so I'd like to better understand the rationale. Thanks! |
We are waiting to hear back any feedback on our comment on their issue 10. |
@zkoch we're aware this is about to ship in Chrome stable. Could you give us an up to date response on your issues 10 and 7 that we raised? |
One question/thought: how likely is it that a developer will produce a single manifest that serves as both a PWA web app manifest and a payment manifest? It appears that none of the keys conflict today, but is this something that Web App Manifest maintainers should take into account when adding new fields in the future and perhaps non-normatively document in their spec? |
Taken up at our call 29-08. We agreed we still need an answer. We will take it up at the f2f. @slightlyoff going to do some research. |
So I spoke a bit with @zkoch, and it seems like there is potential for some conflict if developers do this. At a minimum, perhaps it would be good to have @marcoscaceres and @mgiuca come up with some sort of agreement about how to keep keys from colliding. |
Right now, it's not a problem because I'm tracking all of them (🤞). I think it will have to remain a community effort to make sure we don't stomp on each other for now. |
Closing this review now. TAG remains concerned about two issues that we don't think are yet completely addressed:
|
Hello TAG!
I'm requesting a TAG review of:
We'd prefer the TAG provide feedback as:
The text was updated successfully, but these errors were encountered: