RFP: Payment Method Manifest about standards-positions HOT 7 CLOSED

Update from TPAC: Google would like to move this to FPWD in the next few weeks.

The proposal enables interesting things for payments, but I would appreciate some help with the security and privacy aspects: this does a lot of cross-origin requests and interactions and could have privacy/security implications. So if at all possible, I would like a few of us to discuss what they are proposing before the WG publishes FPWD.

from standards-positions.

Some of my previous thoughts in this space are in the TAG review of Payment Method Manifest, the TAG review of Payment Handler, and a comment in the TAG review of Payment Method Identifiers.

from standards-positions.

I'm inclined to mark this as worth prototyping. Does that make sense?

from standards-positions.

Makes sense.

from standards-positions.

I'm actually having second thoughts about that. I think given that #23 will be defer, I think this probably should be as well.

I've also been concerned with this spec in the past about whether it's going to do things in a way that leads to interoperability. That is, does the manifest have enough information for an implementation to understand how to handle the payment method... and is that information specified in the spec.

from standards-positions.

(Or to put it another way -- is it the case that the payment applications linked to either (a) use Payment Handler or (b) don't have a known way to handle payments? Or is there some other mechanism I'm missing here?)

from standards-positions.

"Defer" is good... there is a lot of work to be done on this spec + also the Payment Handler. Once they are in better shape, we can reevaluate our position.

from standards-positions.