Ticket #1458 (closed enhancement: wontfix)

Opened 10 years ago

Last modified 10 years ago

Allow OpenID authenticate on wiki

Reported by: candrews Owned by: gismo
Priority: normal Component: accounts
Keywords: Cc:

Description

There's a mediawiki extension that's well developed: http://www.mediawiki.org/wiki/Extension:OpenID

Thanks!

Change History

comment:1 Changed 10 years ago by roh

i read up a bit about openID, but are really not sure if we want that. after all its a big thing trusting other instances.

i'll leave this open for now in case somebody has a more detailed explanation why one would want to use this, and if in what configurations it makes sense.

the most disturbing part was that there seem to be no forced security around the communication with the id provider instance.
also how does the 'free choice of id providers' help a site-admin? nobel goal, but what hinders spammers running their own authentication-provider and spamming your wiki/trac/webapp with the 'identities' which it provides?
somehow nullifies the idea a bit for me.
please correct me when i understood something wrong.

comment:2 Changed 10 years ago by candrews

What stops people from registering and spamming now? OpenID just makes it so you don't have yet another password to remember for yet another site.

The OpenID spec does detail secure protocols between the consumer and provider. And a good number of services consume and/or provide OpenID - it's not an off the wall idea that is broken and no one uses. For example, myspace, yahoo, aol, identi.ca, and many more use OpenID.

It will definitely help users use the site (as they won't use weak passwords, forget their password, or simply not contribute because registering is annoying).

comment:3 Changed 10 years ago by roh

  • Status changed from new to closed
  • Resolution set to wontfix

i invested an hour again to research this and came to the conclusion that this would
a) generate quite some work to implement properly and
b) we should not endorse systems which have that big concept problems when it comes to securing personal data.

please read this section http://en.wikipedia.org/wiki/OpenID#Criticism and see the discussion on http://en.wikipedia.org/wiki/Talk:OpenID

most important is this page http://idcorner.org/2007/08/22/the-problems-with-openid/ which provides a nice collection why one doesnt want to use this and why its a bad idea in a world of phishing and people who will just 'hit every ok button they will be presented with' to support or endorse a system which moves responsibility from the authentication provider to the user (who by default must be seen as 'needs protection' not as 'can protect himself').

in addition to that one needs to know that while yahoo, microsoft, google, verisign and ibm are corp-board members at openID (not that this names would suggest anything a user can trust more than anybody) these companies do not even support openID on their own webapps.

thus i will close this as wontfix, till openID either fixes its fundamental conceptual problems or gets replaced by something sane.

there are currently >10000 user accounts in wiki.openmoko.org, so i cannot let the 'need to register' argument be valid.
spamming is not worse and not better with or without openid, so thats no argument either.

if there is spam, one needs to revert it by hand anyways, and the user account will be blocked. if it happens again, we can still blacklist ipranges/add captchas or implement other spam protection methods.

Note: See TracTickets for help on using tickets.