Posted Jun 3, 2010 18:54 UTC (Thu) by Simetrical (guest, #53439)
Parent article: 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 littleor a lotmore 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).