Last modified: 2014-07-12 01:34:14 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 13631 - Wikimedia should become an OpenID provider
Wikimedia should become an OpenID provider
Status: NEW
Product: Wikimedia
Classification: Unclassified
Extension setup (Other open bugs)
unspecified
All All
: Normal enhancement with 9 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on: 9604
Blocks: 64475
  Show dependency treegraph
 
Reported: 2008-04-06 17:28 UTC by Bryan Tong Minh
Modified: 2014-07-12 01:34 UTC (History)
25 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Bryan Tong Minh 2008-04-06 17:28:58 UTC
Too facilitate verification of a Wikimedia user for external tools without the need to give the password to that tool, Wikimedia should become an OpenID provider.
Comment 1 Brion Vibber 2008-04-08 23:51:56 UTC
We'll need to evaluate and test the existing openid extension, see if it meets our needs...
Comment 2 Inedible Bulk 2008-05-18 22:04:06 UTC
Depends on bug 9604 first.
Comment 3 Bryan Tong Minh 2008-05-19 07:29:24 UTC
Not really. You can become an OpenId provider without actually using OpenId for login yourself.
Comment 5 Daniel Kinzler 2008-10-06 11:42:16 UTC
Having this would make cooperation with other wiki-ish projects much nicer. OpenStreetMap and OpenLibrary come to mind. Wikipedians could edit on these projects using their Wikipedia account -- which is nice if information from these projects are referenced or even transcluded on wikipedia.
Comment 6 Daniel Kinzler 2008-10-24 18:18:15 UTC
This would also greatly benefit the Toolserver. Right now, toolserver tools can't be personalized without some major effort, and the hassle for users to create an extra account. Using OpenID would also allow simple implementation of opt-in services, which are using nasty workarounds right now. -- ~~~~
Comment 7 wearenotamused 2009-10-17 23:56:50 UTC
(In reply to comment #3)
> Not really. You can become an OpenId provider without actually using OpenId for
> login yourself.

and become part of the biggest problem with current OpenID "adoption"? Please don't. To provide without relying defeats the purpose for the end user.
Comment 8 Jan Kucera (Kozuch) 2010-07-30 09:22:28 UTC
Related reading:
http://strategy.wikimedia.org/wiki/Proposal:Support_OpenID
Comment 10 T. Gries 2012-08-15 19:26:00 UTC
set to high importance
Comment 11 T. Gries 2012-08-15 19:35:05 UTC
see also Wikimedia as OpenID consumer ("RP" = relying party)
https://bugzilla.wikimedia.org/show_bug.cgi?id=9604
Comment 12 Tyler Romeo 2012-08-16 13:21:25 UTC
(In reply to comment #0)
> Too facilitate verification of a Wikimedia user for external tools without the
> need to give the password to that tool, Wikimedia should become an OpenID
> provider.

(In reply to comment #6)
> This would also greatly benefit the Toolserver. Right now, toolserver tools
> can't be personalized without some major effort, and the hassle for users to
> create an extra account. Using OpenID would also allow simple implementation of
> opt-in services, which are using nasty workarounds right now. -- ~~~~

OpenID is not the proper tool for either of these. OpenID is made so that users can use their identity on one site to log in to another site. If our aim to allow users to let external tools access their account without a password, OAuth would be the thing to enable.

(In reply to comment #4)
> Created use-case (and learning resource):
> http://en.wikiversity.org/wiki/Ethical_Management_of_the_English_Language_Wikipedia/Ethics_and_MediaWiki/Use_cases#OpenID_at_Wikimedia:_account.openid.wikimedia.org

None of these use cases necessarily involve Wikipedia becoming an OpenID provider. In both use cases, they would both work just fine if the user had an OpenID identity somewhere else. What they really depend on is login using OpenID, which is in bug 9604.

----

From what I can see, there is not really a point of making WMF an OpenID provider. The only reason you would want to is to allow users to log in to other sites (StackOverflow, for instance) using their Wikipedia account as an identity. I do not think this is the intended goal, nor should it be. Login through OpenID, on the other hand, is probably the better solution (along with OAuth).
Comment 13 Tim Landscheidt 2012-09-27 14:36:58 UTC
(In reply to comment #12)
> (In reply to comment #0)
> > Too facilitate verification of a Wikimedia user for external tools without the
> > need to give the password to that tool, Wikimedia should become an OpenID
> > provider.

> (In reply to comment #6)
> > This would also greatly benefit the Toolserver. Right now, toolserver tools
> > can't be personalized without some major effort, and the hassle for users to
> > create an extra account. Using OpenID would also allow simple implementation of
> > opt-in services, which are using nasty workarounds right now. -- ~~~~

> OpenID is not the proper tool for either of these. OpenID is made so that users
> can use their identity on one site to log in to another site. If our aim to
> allow users to let external tools access their account without a password,
> OAuth would be the thing to enable.
> [...]

That's not what Daniel wrote.  The aim is to allow external tools to verify that a user has authority over a wiki account.  Take a look at http://toolserver.org/~magnus/tusc.php to understand what hoops users now have to jump through.

Chris, given http://permalink.gmane.org/gmane.org.wikimedia.toolserver/5295:

| [...]                          There are hacks like TUSC that we want
| to replace with better systems/services (e.g. OpenID/OAuth).

| [...]

what's the current status of this bug?  The "2012-13 Goals" lists for "Q1 (July-September)" "OAuth/OpenID/SAML - initial test implementation for highest value use cases".  "Are we there yet?" :-)  http://www.mediawiki.org/wiki/OAuth suggests that OpenID is not in consideration by the WMF.  Can we close this bug then as WONTFIX?
Comment 14 Tyler Romeo 2012-09-27 15:51:32 UTC
(In reply to comment #13)
> (In reply to comment #12)
> > (In reply to comment #0)
> > > Too facilitate verification of a Wikimedia user for external tools without the
> > > need to give the password to that tool, Wikimedia should become an OpenID
> > > provider.
> 
> > (In reply to comment #6)
> > > This would also greatly benefit the Toolserver. Right now, toolserver tools
> > > can't be personalized without some major effort, and the hassle for users to
> > > create an extra account. Using OpenID would also allow simple implementation of
> > > opt-in services, which are using nasty workarounds right now. -- ~~~~
> 
> > OpenID is not the proper tool for either of these. OpenID is made so that users
> > can use their identity on one site to log in to another site. If our aim to
> > allow users to let external tools access their account without a password,
> > OAuth would be the thing to enable.
> > [...]
> 
> That's not what Daniel wrote.  The aim is to allow external tools to verify
> that a user has authority over a wiki account.  Take a look at
> http://toolserver.org/~magnus/tusc.php to understand what hoops users now have
> to jump through.

That still doesn't change my point. OAuth is the appropriate tool for external applications to verify a user's identity and then perform operations on that user's behalf.
Comment 15 Tim Landscheidt 2012-09-27 16:57:36 UTC
(In reply to comment #14)
> [...]
> That still doesn't change my point. OAuth is the appropriate tool for external
> applications to verify a user's identity and then perform operations on that
> user's behalf.

The point of TUSC isn't necessarily to perform operations on a user's behalf, but for example just to ensure their consent to aggregate personal data as required by https://wiki.toolserver.org/view/Rules#Privacy_Policy.  That's a subset of what OAuth offers, but can very well be accomplished with OpenID.
Comment 16 Tyler Romeo 2012-09-27 17:31:46 UTC
(In reply to comment #15)
> (In reply to comment #14)
> > [...]
> > That still doesn't change my point. OAuth is the appropriate tool for external
> > applications to verify a user's identity and then perform operations on that
> > user's behalf.
> 
> The point of TUSC isn't necessarily to perform operations on a user's behalf,
> but for example just to ensure their consent to aggregate personal data as
> required by https://wiki.toolserver.org/view/Rules#Privacy_Policy.  That's a
> subset of what OAuth offers, but can very well be accomplished with OpenID.

But that's still something that should be done with OAuth. You may not be doing stuff on behalf of the user, but you are accessing the user's data, which is a permission that can be granted using OAuth. OpenID is supposed to be used for single sign-on.
Comment 17 Tim Landscheidt 2012-10-01 00:46:47 UTC
(In reply to comment #16)
> [...]
> > > That still doesn't change my point. OAuth is the appropriate tool for external
> > > applications to verify a user's identity and then perform operations on that
> > > user's behalf.

> > The point of TUSC isn't necessarily to perform operations on a user's behalf,
> > but for example just to ensure their consent to aggregate personal data as
> > required by https://wiki.toolserver.org/view/Rules#Privacy_Policy.  That's a
> > subset of what OAuth offers, but can very well be accomplished with OpenID.

> But that's still something that should be done with OAuth. You may not be doing
> stuff on behalf of the user, but you are accessing the user's data, which is a
> permission that can be granted using OAuth. OpenID is supposed to be used for
> single sign-on.

In a perfect world you are maybe right.  But any solution will have to be implemented, thoroughly reviewed, deployed and maintained.  AFAIK, acting as an OpenID provider will not open up any attack angles to WMF's infrastructure as it is passive.  So, given past experiences, it could maybe be deployed by christmas.

OAuth on the other hand seems to require schema changes, a rewrite of core code and a long term commitment because if for example Facebook acts as a launch customer and adds editing functionality to their site, they do certainly not want to rely on experimental features.  I wouldn't want to speculate, but my guess is that OAuth is much harder to implement, much harder to review, much harder to deploy and much harder to maintain which results in general availability much later than OpenID's.

So I'd rather have OpenID now (well, this year) than OAuth some time in the (farther) future.
Comment 18 Tyler Romeo 2012-10-01 00:56:36 UTC
(In reply to comment #17)
> In a perfect world you are maybe right.  But any solution will have to be
> implemented, thoroughly reviewed, deployed and maintained.  AFAIK, acting as an
> OpenID provider will not open up any attack angles to WMF's infrastructure as
> it is passive.  So, given past experiences, it could maybe be deployed by
> christmas.
> 
> OAuth on the other hand seems to require schema changes, a rewrite of core code
> and a long term commitment because if for example Facebook acts as a launch
> customer and adds editing functionality to their site, they do certainly not
> want to rely on experimental features.  I wouldn't want to speculate, but my
> guess is that OAuth is much harder to implement, much harder to review, much
> harder to deploy and much harder to maintain which results in general
> availability much later than OpenID's.
> 
> So I'd rather have OpenID now (well, this year) than OAuth some time in the
> (farther) future.

OAuth should not require any core changes. From what I've put together, all it would require is three additional tables to store authentication information. From there, it would latch into the ApiCheckCanExecute hook (https://gerrit.wikimedia.org/r/20905).

Furthermore, that still doesn't change the fact that OpenID is limited in its capabilities since it's not actually meant for service authentication. So maybe in the case above, where the only thing the toolserver app needs to do is verify the user's identity, it would work, but for any app that actually needs to do something on behalf of the user, OpenID is useless.
Comment 19 John Du Hart 2012-10-01 12:36:26 UTC
(In reply to comment #18)
> 
> OAuth should not require any core changes.

No, it will. It shouldn't be implemented as an extension. If it's going to be done correctly, it needs to be done in core.
Comment 20 Tyler Romeo 2012-10-01 12:58:07 UTC
(In reply to comment #19)
> (In reply to comment #18)
> > 
> > OAuth should not require any core changes.
> 
> No, it will. It shouldn't be implemented as an extension. If it's going to be
> done correctly, it needs to be done in core.

Please explain why this is so. OAuth is not a requirement for MediaWiki, so there is no reason for it to be part of the core. And if MediaWiki is really trying to move to a more modular approach, then it is much more appropriate for it to be implemented as an extension.
Comment 21 Bryan Tong Minh 2012-10-01 15:27:46 UTC
(In reply to comment #18)
> 
> Furthermore, that still doesn't change the fact that OpenID is limited in its
> capabilities since it's not actually meant for service authentication. So maybe
> in the case above, where the only thing the toolserver app needs to do is
> verify the user's identity, it would work, but for any app that actually needs
> to do something on behalf of the user, OpenID is useless.

Exactly, but that is precisely the case that I was aiming for, and I fully agree with comment #17, that it is better to have a good solution soon, rather than a perfect solution in the distant future.
Comment 22 Chris Steipp 2012-10-01 18:54:58 UTC
One of the most recent issues we encountered when we tested enabling the OpenID extension as a provider was that it's didn't fully integrate with the other authentication extensions. Specifically, when the provider wiki used ldap for it's authentication, users weren't able to complete the openid process.

I need to dig in an see if this was some error in our setup, or if the extension isn't calling all of the hooks. I'll add some blocker bugs when I get it reproduced.
Comment 23 jeremyb 2013-05-24 03:08:59 UTC
What's the latest here? I see bug 9604 but this bug has no deps or blockers set atm.
Comment 24 James Forrester 2013-05-24 07:58:09 UTC
(In reply to comment #23)
> What's the latest here? I see bug 9604 but this bug has no deps or blockers
> set atm.

Have tidied bugs up a bit; yes, this is blocked on 9604. Timing is 'unsure', but it's definitely in the plan.
Comment 25 Andre Klapper 2014-03-12 15:36:12 UTC
(In reply to T. Gries from comment #10)
> set to high importance

Not high priority until bug 9604 is fixed...
Comment 26 Matthew Flaschen 2014-04-29 00:54:29 UTC
I don't think this is related to bug 64475.  That can be solved/improved within the current SUL/CentralAuth system.

OpenID is a system that would allow a user to say to a separate site, "I'm Wikipedia user Foo" and be able to prove it (this can kind of be done already with OAuth, but that's not the main purpose of OAuth).
Comment 27 Nemo 2014-04-29 06:35:48 UTC
Thanks, I know what it means. OpenID could be used to authenticate with Wikimedia credentials to some non-MediaWiki Wikimedia services (e.g. an issue tracker).
Comment 28 T. Gries 2014-04-29 06:43:11 UTC
@Nemo ... OpenID could be used to authenticate with Wikimedia credentials to some non-MediaWiki Wikimedia services (e.g. an issue tracker).

Simply: yes.

I still maintain the extension, and run already (apart from my personal installation) a testwiki on labs for this purpose. A few code issues have still to be fixed.

And a further discussion is needed with the other experts, whether and when we want to start a test run for more users.
Comment 29 Chris Steipp 2014-04-29 15:50:12 UTC
I've talked about this with some of you individually, but I wanted to document on this bug that "OpenID 2.0 has been superseded by OpenID Connect" (http://openid.net/developers/libraries/obsolete/). Combining OAuth and OpenID's properties (i.e., OpenID Connect) seems like the direction that is going to be most supported in the long term.

Neither of the current OAuth or OpenID extensions support OpenID Connect (OIDC) yet. Should we convert this bug to be, "Support OIDC"? Or is there any reason we should enable OpenID 2.0 in the near term on WMF wikis? We decided it did make sense to implement OAuth 1.0a because last year because the security properties were much easier to deal with. Maybe we should consider that for OpenID too?
Comment 30 T. Gries 2014-04-29 17:08:03 UTC
@Chris: thanks, you are right. However, I found it a little bit disappointing, that you haven't contacted me personally regarding this.

Having followed all recent publications about OpenID Connect I can say this:

"I cannot transform the current extension OpenID into a version which supports OpenID Connect. If you want to go one, please look for a new maintainer."

This is not a declaration of resignation, but I simply do not have the skills, and time to develop such a new extension. 

In my view, going towards OpenID Connect (and perhaps BrowserID) should be a paid development funded by Wikimedia Foundation.
Comment 31 Chris Steipp 2014-04-29 23:54:57 UTC
(In reply to T. Gries from comment #30)
> @Chris: thanks, you are right. However, I found it a little bit
> disappointing, that you haven't contacted me personally regarding this.
>

Apologies, I should have pinged you on that one.
 
> 
> In my view, going towards OpenID Connect (and perhaps BrowserID) should be a
> paid development funded by Wikimedia Foundation.

I definitely wasn't implying you should take it on! It's a big project, and probably best handled by a small team if we have any hope of getting it out in a reasonable amount of time.

Until we're able to work on it (which would probably be fall at the very earliest), I'm still interested if there is a compelling reason to get OpenID installed on the cluster. Is there?
Comment 32 T. Gries 2014-04-30 00:30:14 UTC
(In reply to Chris Steipp from comment #31)
> (In reply to T. Gries from comment #30)
> > @Chris: thanks, you are right. However, I found it a little bit
> > disappointing, that you haven't contacted me personally regarding this.
> >
> 
> Apologies, I should have pinged you on that one.

Okay, accepted!

I like the OpenID extension and think, we should start internally with it, i.a.  to makee the requesters happy.

In a parallel develoment, a new team can develop a new Open Connect extension.
Comment 33 SJ 2014-07-11 00:50:56 UTC
> I'm still interested if there is a compelling reason to get OpenID installed on 
> the cluster. Is there?

I see good reason to get Open ID installed on the cluster.  The use cases requested above seem reasonable and valuable.

A future OIDC project would take an unclear amount of time, and might not have much marginal benefit (in the mid term) over Open ID.
Comment 34 Dereckson 2014-07-11 13:06:13 UTC
Pure OpenID identification on blogs, solutions like BitBucket use OpenID 2.0.

OAuth doesn't accomplish the goal of universal identification (but provides authentication) solution usable everywhere, so yes, for me, it makes absolutely sense to deploy OpenID 2.0 on WMF, in addition to OAuth and not to wait OIDC, which has not been universally deployed yet.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links