RE: Seeking feedback on "user consent" text in Web Payments Working Group specification

The secure context requirement mitigates rogue script being inserted externally, say by a MITM, but not the risk of bad script generated by a compromised third-party script server or poor site administration procedures. Given the honeypot the API creates it could be a good idea to have a belt & braces approach, say with a new "allowpaymentrequest-src" CSP directive i.e: 

Content-Security-Policy: allowpaymentrequest-src paywidgit.com; [other CSP directives] 

-----Original Message-----
From: Adrian Bateman [mailto:adrianba@microsoft.com] 
Sent: 07 October 2016 19:14
To: Mike O'Neill <michael.oneill@baycloud.com>; 'Ian Jacobs' <ij@w3.org>; public-privacy@w3.org
Cc: 'Adam Roach' <abr@mozilla.com>; 'Telford-Reed, Nick' <Nick.Telford-Reed@worldpay.com>; 'Adrian Hope-Bailie' <adrian@ripple.com>
Subject: RE: Seeking feedback on "user consent" text in Web Payments Working Group specification

> On Fri, Oct 07, 2016 at 06:42:59, Mike O'Neill wrote:
> I wonder if the "allowpaymentrequest" attribute on an iframe is
> sufficient to stop rogue script dynamically creating iframes which
> present bogus payment requests to the user. Maybe a CSP directive would
> work here, or at least block payment requests from iframes when the top
> level context is not secure.

iframes for which the top level context is not secure are not Secure Contexts
and so the PaymentRequest API isn't available.