If you believe you have found a security issue with the OpenID protocol, for the time being, please do this:
We expect to adapt/improve this process as the need arises in the future.
OpenID is more susceptible to phishing because malicious RPs can be easily set up to lure users into entering their authentication information at a web site that poses as the user's OP. The OpenID Phishing Brainstorm page contains ideas from recent discussions on the OpenID general mailing list.
This is a response to a blog post reporting a possible security problem with some OpenID servers. Essentially the problem is that by logging in with OpenID, one provides the information: that one is currently logged in to one's OP, along with the username. Malicious OpenID relying parties could use this information to submit forms to the OP utilizing the user's auth cookie, unbeknownst to the user. (using javascript to submit a form in an i-frame, or similar) Therefore web applications that serve as identity providers must be especially careful to protect the user's account.
To protect against this attack, commonly known as Cross-Site Request Forgery (abbreviated CSRF or XSRF), you must make sure that the form was served for the user and not for some attacker. One method is to check the referrer header on the form submission, but this may not be reliable, as some user agents may not provide this header. Another method is to put a hidden form element containing something based on a secret and data in the user's session object. Thus only a form served for a particular user will generate a submission valid for that user. Many reputable OpenID providers already use this method to secure form submissions, but it's the type of thing that smaller, less comprehensive implementations may neglect.
Here's a long list of threats to think about.
return_to cannot be trusted (link)
3rd-party widgets (sourced outside the RP's site) endanger OpenID's privacy model (link)