Why the resistance?
What's supposed to happen is that a merchant can only get the 3DSecure liability shift if they're not on the Visa/Mastercard "chargeback monitoring" list. This means they're less of a "risk" as far as the card issuers are concerned and as such get a lower "cost-per-transaction" rate.
The merchants are happy because they get a lower card processing fees and liability shifts to the card issuing bank for fraudulent transactions (although not for "goods not received" chargebacks).
The acquiring (merchant) banks get a reduction in certain transaction rates and the issuing banks, well, they're bound by the industry code they're in - but I guess they're hoping for improved "trust" in online shopping and therefore an increase in online transactions.
3DSecure is an improvement - but it's not ideal... better would involve a physical card reader (generating some sort of per-transaction hash value) combined with online login and punters would never enter [full] card details on any website ever again.
It's an attempt at nice fluffy web of trust as it stands... however the only drawback is how that trust can be broken.
The preferred method of embedding the 3DSecure login in an iFrame means that the user can't see where that login page actually comes from. If I wanted to set up a scam website I could just as easily set up a scam 3DSecure login page and capture those details as well.
Alternatively, If it IS possible to poison the DNS system (as has been recently highlighted) a sophisticated attack _might_ be able to inject it's own fake 3DS login page into that iFrame and capture the details (highly unlikely though, there are easier ways).
Once the bad guys have got your 3DSecure login the whole "trust" thing starts to crumble.
----
As an aside - I'm not quite sure how this will affect reliability... data gets bounced around a lot. Card details go from the merchant to the payment gateway and then a load of transaction id's and hash values are thrown around in a big loop. Something like:
merchant -> payment gateway -> merchant -> 3DS bank page -> merchant -> payment gateway -> merchant.
If simplicity is the key to robustness I can see this falling over occasionally; you've introduced a third point of failure into the system. Without 3DS it's a much more pleasant:
merchant -> payment gateway -> merchant.
--
posted AC as I'm in the middle of implementing it