The current version of http://www.mediawiki.org/wiki/OAuth was written by me and Dario. It's definitely a starting point and not a finished proposal. I am not sure to what extent the OAuth 2 protocol has evolved since this was written but that definitely needs to be checked.
Diederik On Fri, Apr 27, 2012 at 1:52 PM, Chris Steipp <[email protected]> wrote: > 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 > _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
