I think Kim’s second comment referred more to the attacker trawling the web and trying the ill-gotten credentials on OpenID enabled sites until one lets them in.

I think Kim was referring to the OpenID URL being on the sites so that the evil people could discover which sites you had an account at. Likely the only places that would be showing my OpenID would be blog comment sites showing who made the comment.

My point is that there are many unique identifiers that if publicly visible could be used to determine someone has an account at a site, and given that many people use the same password at different sites, having captured an existing password would enable an evil-doer to impersonate the user as well.

Currently manuy peoAgree, but for many people that use the same username (email) and password at sites,

I think you are right in questioning where the vulnerability lies. Current phishing attacks stem from the vulnerability to social engineering of both the user experience and the default authentication mechanism used by both schemes: passwords.

It does appear that both OpenID or Infocards only offer anti-phishing properties when coupled with a client side agent. Unfortunately, those users most likely to fall victim to socially engineered phishing attacks will also probably be the last to start using such client software.

By contrast, mutual authentication schemes such as Passfaces or RSA’s "Site-to-user Authentication" (formerly Passmark’s "site-key") can be used to alert the user that they may be falling victim to social engineering without requiring them to install and use a client component.

With a graphical auth scheme such as Passfaces, the user is unable to give away their authentication secret unless that user’s specific images are shown. The great advantage of such systems is that they do not rely on having to educate users to be aware of the threat.

It is great that OpenID and Infocards allow for multiple authentication technologies, but perhaps we need to be careful not to treat user authentication as an optional extra to identity management but as an integral part of it.

If you could provide some information on the identity assurance aspect of OpenID it would be greatly appreciated.

To provide a reasonable or high confidence the correct person is provide the correct access and the person is not impersonated. A validation process of the identity has to take place to have the confidence the correct person is who they say they are. If there is no assurance of the identity, basically a user is managing their own Single Sign On capability with no identity assurance to low risk low sensitivity data.

If an organization required trust in the identity to provide access to their service I am not sure that OpenID provides this capability.

I think that as OpenID Providers start marketing themselves, they will all offer security features to thwart these attacks similar to how sites use SSL certificates when taking payment information.

The OpenID Authentication protocol proves the "user" controls an identifier. In some ways, it is as if we have automated providing a user name and password at a site. There is no more identification of the user happening.

OpenID Attribute Exchange allows the movement of attributes which may be signed by trusted third parties about the user.