No subject

tag that references a facebook.com server. You're asking your visitors 
to trust Javascript from a third party that you cannot vet, and therefore 
cannot trust.

OpenID, by contrast, doesn't ask your users to execute any third party
Javascript (unless you're using something like ID Selector or whatever
it's now called, which I think is a bad idea, too).

Allowing my site visitors to use OpenID poses *zero* risk from a security
standpoint and a privacy standpoint. That's why we're embracing OpenID,
and rejecting Facebook Connect.

I don't think Connect *has* to be this way, at least not for Facebook
to act as an IdP.[1] They could do something like ask RPs to embed an IMG 
link to facebook.com that uses HTTP redirects to make info available to 
vetted first-party JS, and then use AJAX and WS calls to communicate with 
the facebook backend. Connect isn't just easy for RPs, it takes the easy, 
and insecure route, for Facebook, too.

Perhaps one answer to Connect would be for OpenID to develop an alternative
that didn't violate best practice guidelines for embedding client-side code?
For those who wanted an easy install and didn't care about best practices,
a version of the required Javascript could be hosted on openid.net and
utilize code running on openid.net. For those who do care, the JS<->server
interaction would be well documented so entities could host the JS and 
required server code themselves.

-Peter

[0] I've expressed these concerns directly to Facebook staff, without any
sort of response. 

[1] Using something like <script> makes it much easier to embed chunks
of HTML *and* maintain full control over the HTML. But they also could offer
vetted HTML that an RP could embed if the Facebook WS said it was OK. Or
pass the chunk of HTML to the RP so the RP could check it before embedding it.