And... OpenID is back, with OpenID connect, which companies are getting behind. It is now based on oAuth, so things are coming together in a positive way.
http://techcrunch.com/2014/02/26/openid-foundation-launches-openid-connect-identity-protocol-with-support-from-google-microsoft-others/

Meanwhile, Mozilla has dropped Persona, which I consider good news, people are getting in line with a single stack of standards.

Given all this, probably this issue is now about implementing OpenID connect.

We can look at Google's "Site Verification API" if we implement a strong oAuth framework, as this will let people verify their sites for Webmaster Tools very easily.

Also Google Analytics APIs.

Discussed on live chat, the following were all the social networks people were interested in for oAuth login: Facebook, Twitter, Google.

Covered on this spreadsheet:
https://docs.google.com/spreadsheets/d/1_yaJeGzDIsxq33I7Wg9I-lTBDk3YS22WPBwJ971v5tI

Implemented with Hybridauth. I've improved Hybridauth a lot so it can meet our needs, and to bring the project forward generally.

It's a little different to described in this issue, but better.

Composr's own OAuth implementation, used for non-login APIs, is unchanged. It's best to just leave that alone for what it is good for and have Hybridauth fully handle login integration with its own more advanced OAuth implementation.

Google Analytics APIs have already been used by the new v11 stats addon.

Google's "Site Verification API" is not actually interesting on review. People can always set a CNAME record or something, so I don't know what problem we'd really be solving with it, really we'd just be making Google a special snowflake for no good reason.

This issue was a v12 bedrock issue, but I've done it for v11 as I always hated our Facebook login integration and how it used JS. Having it all go through a nice standardised server-side OAuth library, along with other integrations, is really nice. And I need it for a client site.