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
We'll need to evaluate and test the existing openid extension, see if it meets our needs...
Bryan.TongMinh wrote:
Not really. You can become an OpenId provider without actually using OpenId for login yourself.
dzonatas wrote:
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
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.
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. -- ~~~~
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.
see also Wikimedia as OpenID consumer ("RP" = relying party)
https://bugzilla.wikimedia.org/show_bug.cgi?id=9604
(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).
(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?
(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.
(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.
(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.
(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.
(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.
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.
(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.
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.
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.
(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.
(In reply to T. Gries from comment #10)
set to high importance
Not high priority until bug 9604 is fixed...
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).
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).
@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.
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?
@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.
(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?
(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.
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.
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.
I wonder if there are studies of how big a "loyalty" increase one gets from users by becoming an OpenID provider. My impression, seeing all the providers which were born and died, is that the successful ones are those which have an interest in keeping you around.
Yahoo! disbanded pretty much anything but not OpenID, why? probably because they are desperate about keeping users with any excuse possible. Wikimedia is, too... if people end up logging in and visiting Wikimedia projects more in order to use other websites (because they trust Wikimedia more than other providers), in principle that's an easy win for everyone. Would be nice to have some numbers to back this theory so that the project can be prioritised over more "traditional" recruitment and engagement tactics.
Also, Google shut down OpenID 2.0 on 2015-04-20. People may be looking for other providers.
OpenID has little support today. To some extent it has been replaced by OpenID Connect (not as a federated identity system, but at least as a standard method of proving your identity at a specific website). IMO we can decline this in favor of T254063: OAuth extension should support OpenID Connect.
Yes. Sign in for Wikimedia-related tools has been supported by OAuth for many years now. And even if it made sense to support logging into unrelated sites with a Wikimedia account (a huge if), OpenID would no longer be the way to do it. That's why there has been no real activity on this ticket in 8 years.
It seems pretty unlikely to me that Wikimedia would implement OpenID or OIDC support with some non-MediaWiki software, so I don't see the difference.
Anyway, as noted in that task, Wikimedia is mostly an OIDC provider already. It doesn't technicall pass all MUST requirements from the spec, and doesn't implement any of the (optional) discovery features, but it's close enough that most clients probably work (and could be improved with a limited amount of work).