Re: [w3ctag/design-reviews] Web payment method manifest (#162)

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)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/162#issuecomment-298143339