I would consider using "Facebook OpenID App" as OpenID server.

While it is certainly possible to implement a functioning OpenID server with facebook's platform, I don't believe that it can be done very elegantly this way. For example:

• An app can't add stuff to the HEAD element of a user's profile, so it wouldn't be possible to use the "public profile" as an identifier
• You can't host the identifier URLs under apps.facebook.com either, because you can't add HEAD elements in the Facebook canvas
• The user's OP would effectively be you (the implementor), not Facebook.

For these reasons, I would not use an identifier provided in this manner for anything that wasn't completely trivial.

All there statements are obviously disadvantages of this solution. There currently is no way to turn one's profile URI into OpenID URI, so the OpenID URI would have to be provided by the app on another domain. Delegation solves this problem a bit. If you don't like the URI, delegate from your own (I would delegate even if the OpenID support was official).

The third problem with OP being the app, not facebook is also true. However the user might never see the difference. And if you delegate from your URI, than you can switch to native Facebook OpenID once it is available.

And after all, I never said this was ideal. Facebook should support OpenID natively. Provider AND consumer. No question about that.

I don't want to come across as a "hater". I like the "community bootstrapping" nature of these identity proxies, but they do have this irritating problem that they provide no transition mechanism for when "official" support becomes available: if I get an account on idproxy.net and then later Yahoo! becomes an OP, I have to start again. Yahoo! was never really my OP, they were just the guys doing the authentication.

I would welcome Facebook as an OpenID consumer. But there are more than enough OpenID servers already.