Petr, OAuth is something we're committing to on the roadmap for Summer/Fall of this year. So baring anything crazy occurring, oauth should be happening over the next few months. I'm planning to help drive the process from WMF's side, but it's something I'm hoping some people in the community will also take on and help with.
I've heard the mobile, api, and labs all want oauth to help with their projects. But can we start collecting specific user stories from anyone who wants to use oauth? It looks like most of the wikitech conversations have made it to http://www.mediawiki.org/wiki/OAuth, but would someone be willing to make sure it's up to date? I'll try to also get to over the next few days. Thanks! Chris On Fri, Apr 27, 2012 at 4:40 AM, Petr Bena <[email protected]> wrote: > Some updates on this? Is WMF or someone going to work on this or it's > waiting for someone to start? > > On Fri, Mar 16, 2012 at 3:19 PM, Petr Bena <[email protected]> wrote: > > Sorry, few typos: > > > > So, right now a question is if it's supposed to be implemented as > > extension or in core, or both (in case extension can't be created now, > > update core so that it's possible). > > > > ^ that's what I was about to say > > > > On Fri, Mar 16, 2012 at 3:17 PM, Petr Bena <[email protected]> wrote: > >> So, right now a question is if it's supposed to be implemented as > >> extension or in core, or both (in case extension can't be created now, > >> updated core do that it's possible). > >> > >> I would rather make is as extension since there is a little benefit > >> for most of mediawiki users in having this feature. I think it's > >> better to keep only necessary stuff inside core and keep extra stuff > >> as extensions. > >> > >> Is there any objection against implementing it as extension? Thanks > >> > >> On Wed, Mar 14, 2012 at 12:49 AM, John Erling Blad <[email protected]> > wrote: > >>> Just as an idea, would it be possible for Wikimedia Foundation to > >>> establish some kind of joint project with the SimpleSAMLphp-folks? > >>> Those are basically Uninett, which is FEIDE, which is those that > >>> handle identity federation for lots of the Norwegian schools, colleges > >>> and universities.. The SimpleSAML solution is in use in several other > >>> projects/countries, not sure whats the current status. The platform > >>> for FEIDE is also in use in several other countries so if the log on > >>> problems in Norway are solved other countries will be able to use the > >>> same solution. > >>> > >>> Note also that OAuth 2.0 seems to be supported. > >>> > https://rnd.feide.no/2012/03/08/releasing-a-oauth-2-0-javascript-library/ > >>> > >>> In april this year there is a conference GoOpen 2012 > >>> (http://www.goopen.no/) in Oslo and some folks from Wikimedia > >>> Foundation is there, perhaps some folks from Uninett too? Could it be > >>> possible for interested people to sit down and discuss wetter a joint > >>> project is possible? Uninett is hiring for SimpleSAML development and > >>> that could be interesting too! > >>> > >>> John > >>> > >>> On Wed, Mar 14, 2012 at 12:13 AM, Thomas Gries <[email protected]> wrote: > >>>> > >>>> > >>>> There's really two separate things that these systems can do. > >>>> > >>>> The classic OAuth scenario is like this: > >>>> > >>>> site A: Wikipedia > >>>> user A > >>>> site B: Huggle > >>>> > >>>> Site B initiates a special login on site A using a shared secret; on > >>>> success, site A passes back authentication tokens to site B which > verify > >>>> that user A allowed site B access. > >>>> > >>>> Site B then uses those tokens when it accesses site A, in place of a > >>>> username/password directly. > >>>> > >>>> > >>>> OpenID, SAML, etc seem to be more appropriate for this scenario: > >>>> > >>>> site A: Wikipedia > >>>> site B: University > >>>> user B > >>>> > >>>> These systems allow user B to verify their identity to site A; one > >>>> possibility is to use this to associate a user A' with the remote > user B, > >>>> letting you use the remote ID verification in place of a local > password > >>>> authentication. (This is what our current OpenID extension does, > basically.) > >>>> > >>>> > >>>> These are, IMO, totally separate use cases and I'm not sure they > should be > >>>> treated the same. > >>>> > >>>> > >>>> The Extension:OpenID can be used for both cases ( given, that you set > >>>> $wgOpenIDClientOnly = false; ) > >>>> https://www.mediawiki.org/wiki/Extension:OpenID . > >>>> > >>>> "The extension makes a MediaWiki installation OpenID 2.0-aware and > lets > >>>> users log in using their OpenID identity - a special URL - instead of > >>>> (or as an alternative to) standard username/password log in. In that > >>>> way, the MediaWiki acts as Relying part (RP) = OpenID consumer.[1] > >>>> > >>>> *As an option, it also allows the*_*MediaWiki to act as OpenID > >>>> provider*, _so that users with an account on that wiki can use their > >>>> userpage URL as OpenID with which they can log in to other > OpenID-aware > >>>> web sites." > >>>> > >>>> set > >>>> $wgOpenIDClientOnly = false; > >>>> if you want this > >>>> > >>>> Tom. > >>>> > >>>> > >>>> _______________________________________________ > >>>> Wikitech-l mailing list > >>>> [email protected] > >>>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l > >>> > >>> _______________________________________________ > >>> Wikitech-l mailing list > >>> [email protected] > >>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > _______________________________________________ > Wikitech-l mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
