@Pierre, @Tom Chiverton
"As far as I can tell (which is not terribly far), once you've been MITMed, no encryption technique can save you. Unless of course you have pre-shared unique pairs of keys."
No, a MITM attack does not defeat all possible cryptographic protocols. If it did, there'd be no need for SSL/TLS, because they'd be entirely worthless (instead of merely mostly worthless, largely due to terrible user interaction).
Nor do you need "pre-shared unique pairs of keys". You need one pre-shared key: the public key for verifying a trusted CA's signature. Then the critical parties can pass around certificates signed by that CA to verify their identities, and that can be used to construct protocols for verifying someone else's identity.
And that's what Cardspace does. Bob goes to foo.com. foo.com says, "Prove you're Bob; we'll believe it if any of these third parties (STSs) that we trust vouch for you". Bob selects one of those third parties - he's already verified his identity to it, or he does so now - and the third party sends a token to foo.com. The token is signed by the third party, and that signature can be verified using the certificate chain back to the CA.
A MITM can watch those messages, but it never sees any private keys or other confidential information. (Bob's exchange with the STS can be protected in any of a number of ways, because it's a long-term, pre-established relationship.) It could modify the messages, but that would invalidate the signatures.
If foo.com is hostile, all it got was a token proving - to it - that Bob is Bob. It can't use that token for any other purposes. It never sees Bob's credentials, so *it* can't impersonate Bob.
Cardspace is sort of like a generalized Kerberos - not in the details of the protocols, but in the sense that you have one or more third parties that are trusted by the participants to verify a user's identity. Once you have that, users no longer need to send credentials to origin servers, and origin servers don't have to keep user credentials or verifiers (eg password hashes). It's a mechanism for transitive trust, plus a fairly nice UI on the client side.
And yes, Cardspace resists spoofing in the browser by web sites. When a server asks for a Cardspace identity, the UI displays a list of "cards", which represent identities the user has registered. Each card includes an image. Part of the idea is that the images are chosen by the user, so an attacker can't predict how any one card should look - much less how many cards the user might have, or what they should say. It's infeasible to guess.
Of course, a great many users are easily fooled, and a significant portion would probably be taken in by an HTML form with the caption "Hey, dumbass, enter your username and password here. PS this is Cardspace so you're totally safe". This is an unsolved problem in software design.