[paymentrequest] Conflation of manifest + payments seem unnecessary (#70)

> 1.) It allows us to leverage an existing specification that already defines a way of providing necessary branding elements (icons, colors) that are useful from a UI perspective. 

Although desirable, this doesn't equate to trust. Anyone can steal another person's manifest and icons. 

> 2.) It allows the User-Agent to fetch information about a payment app independent of an explicit install request from the payment app provider website.

I'm not sure this is so. The security model of manifest is bound to the Document that contains the manifest. It's not possible, or desirable, to use the manifest independently of the Document that contains that manifest. 

> Payment apps communicate with the service embedding the iFrame (e.g. the User-Agent) via postMessage.

Using an iframe seems problematic. You really want some kind of "overlay browsing context" that is distinct from an iframe: it would work like a "slide in" or "overlay" browsing context where payment can be securely made without needing to send messages back and forth. 


> 1.) We could implement a message passing mechanism wherein the first message the payment app posts back to the parent is whether or not UI is necessary. If not, the payment app could immediately post back the requisite information for payment. This is fine, but it still requires the use of iFrames and postMessage.

It seems you always want to show UI for payment confirmation. Using iframes and postMessage seems like a recipe for disaster. Please avoid this and just come up with a proper API.   

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/WICG/paymentrequest/issues/70