OpenID Connect

"It is important to recognize that this proposal is being driven by the fact that OpenID adoption has largely stalled. That has happened because the sites that folks want to use want a little—or a lot—more information about those who are signing up for or using their services."

Beware of assuming that the problem people are working on is the only problem, or even the most important one. Wikipedia has never required any info at registration except username and password -- even an e-mail address is optional. But it doesn't support OpenID, as either a provider or a consumer. Why? It just never seemed worth the effort to implement, given all the other things to do. There's a MediaWiki extension for it, but sysadmins haven't looked it over to check whether it's suitable for Wikimedia sites (e.g., scalable enough). They have other things to do.

When people have suggested that the popular proprietary forum system vBulletin use OpenID, and when anyone employed by its developer commented, the reaction was similar: something in the vein of "I don't see the point." vBulletin, too, doesn't collect a particularly large amount of personal data.

To me (as a web developer), apathy and poor cost/benefit sound like much more compelling reasons than privacy to not support OpenID. Even if you wanted to farm lots of info out of users, you could just ask them for that on signup, no? Just let them use OpenID instead of asking for a password, and ask for everything else like normal.

Mozilla's Account Manager sounds like a much better direction to head in than OpenID. A central identity store layered on top of an in-browser UI has the advantages of being more resistant to phishing, and not having to prompt the user separately for every site on what central store to use (because the browser can remember between sites).

A built-in browser method can also provide far superior security guarantees when you do use simple passwords, like to log into your central identity provider. There are schemes that will authenticate client to server *and* server to client by using the password as a shared secret, without disclosing any information to eavesdroppers, and without disclosing any information about the password to either party if the passwords don't match. These cannot be done without browser UI support -- if a site implements it in JavaScript, you have no way to tell if it's actually implementing the algorithm or just stealing the password.