Paul Trevithick notes that most users don’t know what the purple information card logo might mean on a website and thus have no incentive to click on it to attempt to log in.

That observation is of course correct, and identical to the observation about the OpenID logo: most users don’t know what that means either, and so won’t try to use it.

Paul goes on to suggest that perhaps it would be more effective to show the logos of prominent information card issuers with which the user is more likely to be familiar with.

Which is exactly which led to the line of reasoning in the OpenID world to show, on a relying party site, the logos of prominent OpenID providers such as Google, Yahoo, Myspace and the like. Because the list of those is so long and grows all the time, this has been referred to as OpenID’s NASCAR problem.

Paul’s line of reasoning shows that the exact same problem applies to information cards for the exact same reason. The argument that is sometimes heard ("information cards don’t have the NASCAR problem because of the client-side selector") is incorrect.

[The NASCAR problem could be alleviated if the client-side component was responsible for rendering the issuer logos on the browser canvas displaying the relying party site, and only showed those logos that corresponded to applicable cards in the user’s card store. But as far as I know, no selector currently does that, and even if it did, it is not obvious that a site would let the selector "pollute" its page without knowing what exactly does show up on that page. Again, OpenID would have the same problem with client-side components such as Mozilla’s.]

What about we drop the NASCAR argument in the OpenID vs. information cards discussion, and figure out how to solve the common issue instead? ;-)