I tracked down a reply on another forum that didn't precisely identify the problem, but it did ask a question that ended up identifying the problem on my system.
Specifically, if CardSpace is failing to automatically create a "CardSpace" folder created under their C:\Documents and Settings\<user>\Local Settings\Application Data\Microsoft folder, this is most likely the solution.
A definitely problem relates to security settings under the C:\Documents and Settings\<user> directory branch. This is a subtle nasty "problem". I wouldn't say it's a "bug", but Microsoft could probably add some code to CardSpace to help user's
My entire C:\Documents and Settings\<user> branch did not have any security entry for <user>. Access was based entirely upon administrator. (<user> is an administrator.)
The solution is to make sure your actual sign-on user account is listed as having "full access" for the C:\Documents and Settings\<user> directory branch, including all subfolders. The fact that the user account might have administrator priviledges
doesn't count. These folder security settings are supposed to be the "normal" situation anyway, but system reconfigurations applied over time may have resulted in these entries not existing. There's a check box under the "Advanced" button for security settings
that'll make all subfolders under the <user> branch have the same security settings as the <user> folder.
I think what Microsoft is facing here is that CardSpace is probably the first application that a user will run that probably forces the security context to be specifically the signed-on user in order to fulfill the security restrictions CardSpace
wants to impose (in order to fulfill its security objectives). Since CardSpace has security objectives that are not a concern of other applications accessing \Documents and Settings\, this isn't really a "bug" in CardSpace. It does however mean that CardSpace
support is going to encounter the typical support problems associated with going "where no one has gone before".
I think this is definitely a candidate for a knowledge-base entry for starters. I think it is then a candidate for some user "help" code to be added to CardSpace that explicitly tests for the problem in the directory branch, and then tells
the user more clearly what is happening and what might need fixing. Presumably this wouldn't result in a security breach because presumably the user wouldn't be able to "fix" the problem unless they had the appropriate permissions anyway.
I would guess that this problem is most likely to occur on systems that have evolved through various user accounts. This was a LONG time ago, but I believe the current user account I use was not the original account when the system was first
configured. I think I cloned the original account into this new account because I wanted to shut down network access to the original default account. The cloning of the \Documents and Settings\ branch probably ended up creating this situation.