Last modified: 2014-07-12 01:34:14 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.
We'll need to evaluate and test the existing openid extension, see if it meets our needs...
Depends on bug 9604 first.
Not really. You can become an OpenId provider without actually using OpenId for login yourself.
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. -- ~~~~
(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.
Related reading: http://strategy.wikimedia.org/wiki/Proposal:Support_OpenID
"Recent" discussion: http://lists.wikimedia.org/pipermail/wikitech-l/2010-May/thread.html#47911
set to high importance
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.
(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.
(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.
What's the latest here? I see bug 9604 but this bug has no deps or blockers set atm.
(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.
