Add a reference to issue #38

[msporny]

Add a reference to issue #38.

[zkoch]

I think this is an issue for the registration spec when we have one. I don't think it belongs in PaymentRequest.

[msporny]

Agreed that it eventually belongs in a registration spec, but we won't have one for FPWD, so we do want to raise awareness that we're thinking about this issue. We could add to the spec issue text that we'll eventually have a registration spec (or integrate registration into this spec).

[adrianhopebailie]

👍 for adding a note on this here until we have a registration spec to put it in

[mountainhippo]

@zkoch if you're unhappy with this being in the API spec, we could instead include a note or issue marker in the architecture spec in the payment app section (section 2.2). But I agree with @msporny and @adrianhopebailie that we should flag this issue in the FPWD.

[adrianhopebailie]

@mountainhippo and @msporny - having re-read the issue I think we should leave it out of the FPWD.

I don't think we should place any mechanism for browsers to synchronise payment apps or payment instruments between installations as explicitly in scope.

This seems like a feature browsers may offer to assist their users but I'm not sure if we can mandate that browsers support sharing of user data with other browsers?

That said, I think that when we address registration we should ensure that it is possible for payment apps to keep themselves synchronized across all of their installed/registered instances. i.e. If I have the same payment app installed on my phone and desktop and add new payment method data to one the other should get updated and this should not be something user agents can control/prevent unless there emerges a very strong security or privacy argument against it

[mattsaxon]

@adrianhopebailie, response made within issue #38

[msporny]

Withdrawn in favor of pull request #96.