Not sure where you got that idea. The entire purpose of SAQ A-EP is to bring the hosting site into PCI scope.
Are you arguing that it wouldn't be trivial to replace the iframe form with a malicious iframe form? or to add an event handler and capture credit card numbers from the form used to submit using stripe.js?
This is why SAQ A-EP exists! What you are saying was correct for PCI DSS v2.0
There is a comparison of PCI SAQ A and EP, if all you do is link to a 3rd party site (or load an iFrame) and the CC is loaded in that PCI compliant site, you are OK in SAQ A.
Stripe.js is tricky. Stripe says their QSA has verified that the new version of Stripe.js will let their merchants qualify for SAQ A since the transport of credit card info happens through a iframe (you can see the updated Stripe.js https://js.stripe.com/v2/stripe-dss3-debug.js). I personally disagree with that, but Stripe Checkout definitely falls under SAQ A.
Per the linked doc:
What types of e-commerce implementations are eligible for SAQ A-EP vs. SAQ A?
SAQ A: Merchant website provides an inline frame (iFrame)to a PCI DSS compliant third-party processor facilitating the payment process.
SAQ A-EP: Merchant website loads or delivers script that runs in consumers’ browsers (for example, JavaScript) and provides functionality that supports creation of the payment page and/or how the data is transmitted to the payment processor.
I would agree. If you have the form markup in your page, then your JS can siphon off card details (with an iFrame rendered by someone else with the form in the iFrame, you cannot). I do not know the full story on the Stripe DSS3 code but it's trivial in their payment-form submit event handler to grab details before calling Stripe.card.createToken.
Examples of e-commerce implementations addressed by SAQ A include...[merchant] website provides an inline frame (iFrame) to a PCI DSS compliant third-party processor facilitating the payment process...Examples of e-commerce implementations addressed by SAQ A-EP include...[merchant] website creates the payment form, and the payment data is delivered directly to the
payment processor (often referred to as 'Direct Post')
Right. Which is why SAQ A-EP was invented -- to prevent merchants from gaining compliance based on the loophole that they are using a js library or offsite link to collect payment.
Are you arguing that it wouldn't be trivial to replace the iframe form with a malicious iframe form? or to add an event handler and capture credit card numbers from the form used to submit using stripe.js?
This is why SAQ A-EP exists! What you are saying was correct for PCI DSS v2.0