Wikimedia should become an OpenID provider
OpenPublic

Description

Author: Bryan.TongMinh

Description:
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.


Version: unspecified
Severity: enhancement
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=9604

bzimport added a subscriber: wikibugs-l.
bzimport set Reference to bz13631.
bzimport created this task.Via LegacyApr 6 2008, 5:28 PM
brion added a comment.Via ConduitApr 8 2008, 11:51 PM

We'll need to evaluate and test the existing openid extension, see if it meets our needs...

bzimport added a comment.Via ConduitMay 18 2008, 10:04 PM

inedible_bulk wrote:

Depends on bug 9604 first.

bzimport added a comment.Via ConduitMay 19 2008, 7:29 AM

Bryan.TongMinh wrote:

Not really. You can become an OpenId provider without actually using OpenId for login yourself.

daniel added a comment.Via ConduitOct 6 2008, 11:42 AM

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.

daniel added a comment.Via ConduitOct 24 2008, 6:18 PM

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. -- ~~~~

bzimport added a comment.Via ConduitOct 17 2009, 11:56 PM

wearenotamused wrote:

(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.

Wikinaut added a comment.Via ConduitAug 15 2012, 7:26 PM

set to high importance

Wikinaut added a comment.Via ConduitAug 15 2012, 7:35 PM

see also Wikimedia as OpenID consumer ("RP" = relying party)
https://bugzilla.wikimedia.org/show_bug.cgi?id=9604

Parent5446 added a comment.Via ConduitAug 16 2012, 1:21 PM

(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).

scfc added a comment.Via ConduitSep 27 2012, 2:36 PM

(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?

Parent5446 added a comment.Via ConduitSep 27 2012, 3:51 PM

(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.

scfc added a comment.Via ConduitSep 27 2012, 4:57 PM

(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.

Parent5446 added a comment.Via ConduitSep 27 2012, 5:31 PM

(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.

scfc added a comment.Via ConduitOct 1 2012, 12:46 AM

(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.

Parent5446 added a comment.Via ConduitOct 1 2012, 12:56 AM

(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.

bzimport added a comment.Via ConduitOct 1 2012, 12:36 PM

john wrote:

(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.

Parent5446 added a comment.Via ConduitOct 1 2012, 12:58 PM

(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.

bzimport added a comment.Via ConduitOct 1 2012, 3:27 PM

Bryan.TongMinh wrote:

(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.

csteipp added a comment.Via ConduitOct 1 2012, 6:54 PM

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.

jeremyb added a comment.Via ConduitMay 24 2013, 3:08 AM

What's the latest here? I see bug 9604 but this bug has no deps or blockers set atm.

Jdforrester-WMF added a comment.Via ConduitMay 24 2013, 7:58 AM

(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.

Aklapper added a comment.Via ConduitMar 12 2014, 3:36 PM

(In reply to T. Gries from comment #10)

set to high importance

Not high priority until bug 9604 is fixed...

Mattflaschen added a comment.Via ConduitApr 29 2014, 12:54 AM

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).

Nemo_bis added a comment.Via ConduitApr 29 2014, 6:35 AM

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).

Wikinaut added a comment.Via ConduitApr 29 2014, 6:43 AM

@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.

csteipp added a comment.Via ConduitApr 29 2014, 3:50 PM

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?

Wikinaut added a comment.Via ConduitApr 29 2014, 5:08 PM

@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.

csteipp added a comment.Via ConduitApr 29 2014, 11:54 PM

(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?

Wikinaut added a comment.Via ConduitApr 30 2014, 12:30 AM

(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.

bzimport added a comment.Via ConduitJul 11 2014, 12:50 AM

sjekjr wrote:

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.

Dereckson added a comment.Via ConduitJul 11 2014, 1:06 PM

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.

Add Comment

Column Prototype
This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.