>
> It sounds OK to me, although we should all sleep on it for a bit. The
> reason this header exists is exactly because mobile code fetching random
> web resources can result in surprising security holes.
>

That's fair. From the server perspective, I'd argue that payment requests /
payments already need to be publicly accessible endpoints. Current
practical use requires support for cross-app/cross-device requests for
them. It seems like a reasonable logical extension to explicitly allow for
them to be accessed cross-site as well.

For this to be useful, someone would have to actually want to fully
> implement the payment protocol (with its own root cert store, ASN.1
> parsing, RSA etc) in browser-sandboxed Javascript rather than just
> providing a real app for people to download.
>

I think there is still value in fetching the payment request cross-site
even if the request payload is validated by a 3rd party using a more
conventional TLS/crypto suite. Exposing x.509/RSA/ASN.1/chain verification
functionality strikes me as a useful thing browsers could easily offer but
that's another discussion entirely but sure it could be done all in JS. In
certain environments downloading a "real app" isn't possible/practical.


> Is that really going to be popular, though? I think it's unclear.
>

It certainly won't be if there is no ability :)

-Andy