Wikimedia Bugzilla is closed!

My understanding is that this will be on the drawing board once the framework
for bug 57 is in place, and it will not be considered before then.  Changing
dependency accordingly.

Well, bug 57 seems unsolvable.
My idea of "How OpenID on Wikipedia should work" :
 * create a sub-domain for hosting OpenID accounts ( eg. id.wikimedia.org)
 * create your openID on id.WM.org
 * link your OpenID and your "local account" (double confirmation, with OpenID
and local accounts)
 * use your OpenID (where you have not a "local account") and your local account
(where you have one)

In fact, your unique OpenID and yours local accounts are attached.

(In reply to comment #2)
> Well, bug 57 seems unsolvable.
> My idea of "How OpenID on Wikipedia should work" :
>  * create a sub-domain for hosting OpenID accounts ( eg. id.wikimedia.org)
>  * create your openID on id.WM.org
>  * link your OpenID and your "local account" (double confirmation, with OpenID
> and local accounts)
>  * use your OpenID (where you have not a "local account") and your local account
> (where you have one)
> 
> In fact, your unique OpenID and yours local accounts are attached.

Well, bug 57 has been solved now.

Do we know if the code is ready for use?

Good question.  I'd like to be able to use my WM identity elsewhere.

Added bug 17637 as dependency for this bug since for now OpenID extension only supports "FileStore" storage, which would need access through NFS.

remove shell keyword not ready for shell yet

I would say this is good, but we shouldn't give full user privileges because we can't apply account creation blocks as effectively and, as our Wikipedia article says, there is a higher phishing risk. I would suggest limiting the privileges to user, non-autoconfirmed, and give them a username as idusername@providername. Full privileges simply require creating a local username and password.

Related reading:
http://strategy.wikimedia.org/wiki/Proposal:Support_OpenID

*** Bug 27428 has been marked as a duplicate of this bug. ***

Mass maintainer change.

For those who want to test, the present version in trunk (OpenID 0.929-beta) works ***very*** well. If someone gives me the possibility to install it on a WMF wiki, please let me know.

removed blocker. It does not "block" the Provider property.

see also Wikimedia as OpenID Provider https://bugzilla.wikimedia.org/show_bug.cgi?id=13631

(In reply to comment #8)
> I would say this is good, but we shouldn't give full user privileges because we
> can't apply account creation blocks as effectively and, as our Wikipedia
> article says, there is a higher phishing risk. I would suggest limiting the
> privileges to user, non-autoconfirmed, and give them a username as
> idusername@providername. Full privileges simply require creating a local
> username and password.

Are these limitations still applicable? If so why? (I cannot seem to find the article mentioned explaining why.)

There's currently a proposal on the English Wikipedia village pump to turn on OpenID. Is there any reason (technical or practical) that this wouldn't be feasible?

(In reply to comment #16)
> There's currently a proposal on the English Wikipedia village pump to turn on
> OpenID. Is there any reason (technical or practical) that this wouldn't be
> feasible?

I am currently working on an improved version, so an implementation should wait until the new version is code reviewed and committed (perhaps in 2 weeks).

Also, there are a number of open bugs that make E:OpenID in its current form impossible to deploy functionally to WMF.

Does the village pump specify as a consumer or a provider? We'll need a designer to fix the UX issues to use it as a consumer. There's a number of bugs in the provider code, though Thomas is working on them.

see discussion on http://lists.wikimedia.org/pipermail/wikitech-l/2013-February/066774.html

assigned to the master

Making this clearer per comments on bug 13631.