Skip to content
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

Closed
rsolomakhin opened this issue Mar 27, 2017 · 17 comments

Comments

Projects
None yet
10 participants
@rsolomakhin
Copy link

commented Mar 27, 2017

Hello TAG!

I'm requesting a TAG review of:

We'd prefer the TAG provide feedback as:

  • open issues in our Github repo for each point of feedback
  • open a single issue in our Github repo for the entire review
  • leave review feedback as a comment in this issue and @-notify @zkoch and @rsolomakhin
@rsolomakhin

This comment has been minimized.

Copy link
Author

commented Apr 13, 2017

@RByers

This comment has been minimized.

Copy link

commented Apr 18, 2017

Presumably feedback should now be filed as issues in the repo, right?

There's now a blink intent to ship for this.

@rsolomakhin

This comment has been minimized.

Copy link
Author

commented Apr 19, 2017

Yep, good idea to file the issues here.

@torgo torgo added this to the tag-f2f-tokyo-2017-04-27 milestone Apr 27, 2017

@torgo

This comment has been minimized.

Copy link
Member

commented Apr 27, 2017

@dbaron

This comment has been minimized.

Copy link
Member

commented Apr 27, 2017

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.

@dbaron

This comment has been minimized.

Copy link
Member

commented Apr 27, 2017

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.

@dbaron dbaron changed the title Web payment manifest Web payment method manifest Apr 29, 2017

@dbaron

This comment has been minimized.

Copy link
Member

commented Apr 29, 2017

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 retrieval

The 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:

  • what the spec does now, where a Link header is used from the identifier URL to find the manifest (disadvantage: extra level of indirection)
  • require that the URL used as an identifier point directly to the payment method manifest (disadvantage: URL used as the identifier is less human-readable)
  • making the URL of the manifest be a /.well-known/ URL that can be formed from the identifier URL without any network interaction (disadvantage: has to be at that URL)
  • using a request header (e.g., Accept) to allow the identifier URL to produce a payment method manifest (disadvantage: requires using Vary: Accept, although that may often be needed anyway)
@dbaron

This comment has been minimized.

Copy link
Member

commented May 16, 2017

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.

@dbaron

This comment has been minimized.

Copy link
Member

commented May 23, 2017

Discussed in today's TAG teleconference. There seemed to be the most support (and no objection) behind option 2 above:

  • require that the URL used as an identifier point directly to the payment method manifest (disadvantage: URL used as the identifier is less human-readable)

I'll open an issue in the spec's repository about this issue.

@zkoch

This comment has been minimized.

Copy link

commented May 23, 2017

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!

@torgo torgo modified the milestones: tag-telcon-2017-07-04, tag-telcon-2017-06-13 Jun 27, 2017

@torgo

This comment has been minimized.

Copy link
Member

commented Jun 27, 2017

We are waiting to hear back any feedback on our comment on their issue 10.

@plinss plinss modified the milestones: tag-f2f-london-2017-07-25, tag-telcon-2017-07-05 Jul 5, 2017

@triblondon

This comment has been minimized.

Copy link

commented Jul 25, 2017

@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?

@slightlyoff

This comment has been minimized.

Copy link
Member

commented Jul 25, 2017

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?

@torgo torgo modified the milestones: tag-telcon-2017-08-08, tag-f2f-london-2017-07-25, tag-telcon-2017-08-29 Jul 25, 2017

@torgo

This comment has been minimized.

Copy link
Member

commented Aug 29, 2017

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.

@slightlyoff

This comment has been minimized.

Copy link
Member

commented Sep 26, 2017

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.

@marcoscaceres

This comment has been minimized.

Copy link
Member

commented Dec 6, 2017

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.

@torgo torgo modified the milestones: tag-f2f-nice-2017, tag-f2f-london-2018-01-31 Jan 31, 2018

@triblondon

This comment has been minimized.

Copy link

commented Jan 31, 2018

Closing this review now. TAG remains concerned about two issues that we don't think are yet completely addressed:

  • Indirection in the retrieval of the manifest (see w3c/payment-method-manifest#10)
  • Avoiding collisions between this and web app manifest (and consideration of merging the two)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.