so, one or more of 3 methods should make it reasonably resilient (assuming the email may not get delivered instantly for example, if email servers are under attack or in general are under load…)

client certs may be an option, but not for the average casual user on the internet, who is only too familiar with email and IM (so can adapt to jabber, because I would hate proprietary protocols of Yahoo/MSN/others in OpenID) but is not familiar with client certificates (for this reason, I did not insist on use of public-private keys either, just made it optional)

The OpenID standard must make sure that the providers support atleast one of the two methods below (to mitigate a costly set up, so a home user can also become an OpenID provider):

a) authentication via text message to your registered mobile phone. The text message should be a token generated using a hash of your public SSH key (which you uploaded at time of registration) or a security key (not necessarily SSH key) generated for you by the server at the time of registration. You must reply to that message with the earlier message contents (the token sent to you) and you will be authenticated. The web-page which was redirected to by the consumer would already have just given a message that you were not logged in (in case you were not) and a link to retry which would just invoke the same redirect (or an auto refresh of the same page); if logged in, it redirects back to consumer website

b) authentication using email. Same as above except that instead of a text message you receive an email at your registered address with the token in subject header and you just reply to that, keeping the token intact. If the provider is paranoid, they may ask you add, at end of subject line, or in email body (option) two random letters (which letters are required would be mentioned in the body of the email) from your atleast 10 letter password – the usual caveats of a strong password must be applied by the provider at time of registration – after all, it is going to be one of the very few passwords you will need because of OpenID.

If you, as a user, have neither a mobile phone nor an email account, you cannot use OpenID (unless there is a similar secure option, I do not like the static IP address option because it is limiting in my being able to use my OpenID from anywhere on internet)

Even if Open ID becomes secure due to proper authentication mechanism (use of only one of the explicitly methods must be allowed, and form based authentication as well as the need to enter the password must not be one of those methods), I dislike the idea that my OpenID roams freely on the internet – this can be prevented by making it mandatory in OpenID standard that all consumers send a one way secure hash (SHA/MD5 etc., the hash algorithm options should be explicitly stated in the OpenID standard) of the OpenID, not the OpenID itself. I know a non-legitimate consumer website will still be able to capture your OpenID (I do not want to give the user a cryptic one way hash string generated from their chosen login ID, at time of registration, to use as login ID at consumer websites in future)