Stealing the Security Token

The Ruhr Uni Bochum claims that they can steal the security token in a CardSpace scenario.... The experts from the German computer magazine c't could not verify the attack...
After reading the paper that describes the attack I must say that I find it very unrealistic.

The attack is described for managed cards. The browser is tricked to load malicious code and then the real RP's code is loaded and presented to the user. The malicious code then loads the root certificate for the malicious RP's SSL certificate and asks the user to install it into the trusted store. This is the biggest assumption in the scenario. Next the user clicks the purple CardSpace icon.

Case 1) Auditing Mode
Assume that CardSpace is tricked to request a token for the malicious RP. When this is the first time CardSpace sees this RP (which is likely) then there might be little CardSpace can do to help the user to recognize the malicious site (because of the installed root certificate). When this is not the first time then CardSpace will warn the user who will probably terminate the transaction.
But who installs a root cert into a trusted store might continue the transaction even when CardSpace raise all flags and blinks all warning lights.

First: The IdP might reject to issue a token to an RP with which it does not have a contract or is outside the (enterprise) circle of trust. Then this attack does not work.
Second: When the IdP issues a token to the malicious RP then that RP can decrypt the token and read the (private) claims. Then it encrypts the assertion for the real RP. The malicious code in the browser (loaded from the malicious server) receives the newly encrypted token and presents it to the form for it to be submitted. The assumption that the malicious code can now reuse the security token to whatever purpose it likes at the RP is not true because the auditing mode restrict its use to the malicious RP.

Case 2) Non-Auditing Mode
Assume the same prerequisites as in case 1. The user is super stupid and the token is stolen and not restricted to the malicious RP. So whenever the real RP expects a security token the malicious code in the browser can provide it.

Do I have to say that an attackers code running inside my browser is probably deadly anyway? Even when the token is not stolen the likelihood that the claims will be a visible part of the "next" page is high, so they can be stolen this way too.

Can't wait to hear what Microsoft writes about this. I had a long busy day and will rethink the whole thing tomorrow.