Toronto's Brent Ashley has an article at IBM Developer Works about "Shaping the future of secure Ajax mashups" which covers the vulnerabilities of various AJAX techniques and most interestingly, discusses proposals for overcoming them properly:

• JSONRequest proposal: Browsers implement a new object that acts much like the existing XMLHttp object with several modifications:
  • JSONRequest would be exempt from the Same Origin Policy.
  • A minimal set of HTTP headers would be used, reducing the overall size of requests.
  • No cookies would be transferred, ensuring that cross-site cookie issues are avoided.
  • JSONRequest would accept only valid JSON text, which would ensure that raw executable code could not be sent for execution.
  • After a communication failure, random delays are introduced before retry to frustrate certain classes of attacks.
  • Each request would return a sequence identifier, allowing asynchronous responses to be associated easily with their original requests.
  • Specific support for duplex connections would enable the server to asynchronously initiate communications through an open communications channel.
• <module> tag proposal: A new HTML tag partitions a page into a collection of modules that are secure from each other but can communicate safely:
  • The <module> tag would be able to access third-party resources, exempt from Same Origin Policy.
  • Cooperative communication between page and module would be available only through specific interfaces. Modules would not be able to communicate with each other -- only with the page. A page can choose to facilitate communication between modules.
  • Communication would be restricted to valid JSON text, in contrast to communicating JavaScript objects, which could possibly cause security leakage through attached code.
  • Restrictions are proposed to ensure that modules and pages cannot interfere with one another's display, causing security issues.
• Content restrictions header: Gervase Markham proposes a content restrictions header specification that would allow authors to express their full intent on how their content should interact with content from other sites. A compliant implementation would submit a content restrictions header containing a policy string.
• W3C Access Control List (ACL) System: The W3C ACL System could be used as a model for an ACL-based system to govern access to HTTP-served resources in Ajax mashups.
• Cross-domain.xml: Flash objects look for a file called cross-domain.xml on the server before they attempt to access their specified URL. This file specifies which sites can host applications that access the services provided on that server. Many Web service providers already implement this file.

Blake in the comments notes the issue of phishing -- that is, making a fake website duplicating the look and feel of a real website to capture passwords and identity. As far as I can tell, OpenID has no good solutions (here's a discussion that doesn't end up being that helpful).

Here's a few ideas I've had mulling over this:

• run your own identity server with your own unique look and feel. This may not be too hard with Amazon EC2 type services, particularly if you could do something like run Java Servlets.
  
• Identity servers should mail you new sites that you've accessed, possibly putting a hold on your account if there's suspicious activities
• Identity servers could provide multiple levels of passwords; lesser passwords could be used for establishing identity at untrusted sites; the highest password could be used for direct administration of the identity account

On other security issues:

• preventing replay attacks (summary: it's handled by the best libraries)
  
• trust, spam and signing comments (summary: out of scope)