Proposal:Implement OAuth for MediaWiki (and employ in Wikimedia)

Status (see valid statuses)

---

The status of this proposal is:
Request for Discussion / Sign-Ups

Strategic Priorities

Every proposal should be tied to one of the strategic priorities below.

Edit this page to help identify the priorities related to this proposal!

1. Achieve continued growth in readership
2. Focus on quality content
3. Increase Participation
4. Stabilize and improve the infrastructure
5. Encourage Innovation

Share this:

This is a featured proposal. This template automatically categorizes into Category:Featured proposals. All proposals marked by this template should be on this list too.

Summary

MediaWiki has a write API. This means you can edit, change and interact with MediaWiki data and users without using the MediaWiki interface. This is currently basically only used by bots.

The write API inspires the idea of editing Wikimedia via something other than MediaWiki. A completely different interface could be used. MediaWiki suffers feature overload, and the larger Wikimedia projects in particular suffer from instructions overload. What should be a brief introductory paragraph turns into an essay designed to answer the needs of dozen of distinct groups. The end result is that it is mostly irrelevant for nearly everyone, and nearly everyone just ignores it.

For large projects, the body of users becomes too big to be considered a single community. For new users it is unwelcoming and can seem to be one undifferentiated mass of difficultness. The Wikimedia community has created one way of helping deal with this -- WikiProjects (especially topic-focused ones). WikiProjects create a smaller, more identifiable group that is easier to interact with.

Now imagine an interface that was completely targeted to a particular WikiProject. Linguistics. Mathematics. Military history. Pokemon. Hurricanes. These WikiProjects all exist and they all have their own articles of interest, members, ratings, to-do lists, discussion forums (talk page), categories, templates, newsletters, barnstars even. In generic MediaWiki you have to hunt to find these things, because they are not relevant to all users. But if you were building an interface just for users in that WikiProject, you could easily customise it and make these things easy and obvious to find and access. This would help overcome one usability hurdle (you still need to edit using wiki syntax, probably), and also help cement a sense of community belonging (something that can easily go missing in very large projects).

This proposal is not about forking the content of any Wikimedia project. Any edits made would be made to the content on the Wikimedia server, and visible there just as with regular edits. It's about allowing an alternative way of editing that content in order to better support communities of interest.

Now on one level, this is possible today. But if someone tried to build such an interface, they would immediately run into a problem that means no one would be able (or allowed) to use their app: (authentication and) authorisation.

Authentication is, how do users tell a third-party service they are who they say they are? i.e. logging in. w:OpenID is well known here. There is a MediaWiki extension that is used on Wikitravel (it has not been activated on Wikimedia). Longstanding bug.

Authorisation is, how do users tell a provider (MediaWiki/Wikimedia) that a third-party service is allowed to interact with the provider on their behalf?

Currently, the only way to solve these problems is to get the user to give their username and password directly to the third-party service. This is especially bad:

• awful for security - bad idea to have any third party collecting logins
• only all-or-nothing control for the user - the only way to de-authorise the third party is to change their password. There's no way they can authorise the third party for some actions but not others, or put a time limit on the authorisation.

Proposal

w:OAuth [1] "is an open protocol [...] to allow secure API authorization in a standard method for desktop, mobile and web applications."

The user experience is something like this:

1. User visits third-party app and likes it
2. User wants to enable third-party app and clicks on some button that says "use me!"
3. Third-party app sends user to original provider (MediaWiki/Wikimedia)
4. Provider makes user confirm that they want to authorise this app, maybe some options, time limit
5. If user hits OK, they get sent back to the third-party app, with permission in place.
6. Any actions the user makes via the third-party app are sent back to the provider, with identification that they came from this particular app.
7. If the user goes back to the provider, they can easily see which apps they currently have authorised, and revoke them from there, if necessary.

I believe the following will also be possible, for the provider:

• Require third parties to register for OAuth access before serving the public.
  • This could include requiring them to meet any minimum requirements, e.g. Not Evil, not contrary to project mission, or open source, or undergo code review
• Then, reasonably block any apps which are not using OAuth
• Monitor which apps currently have access
• Easily identify edits made by an app
• Block an app, or mass-revert edits made by an app, if it "goes rogue"

So my proposal is that for the purpose of encouraging community strengthening and technological innovation, the Wikimedia Foundation should support the creation and enabling of OAuth for the Wikimedia wikis.

(NB. I am not particularly attached to OAuth, if we decide it is better to roll our own, or use some other alternative, so be it. But the basic idea is solving the authorisation problem.)

Motivation

• Attracting new participants. Reducing barriers to participation, attracting new users. Helping community flourish in very large projects.
• Encouraging mash-up style experimentation and innovation. Lower barrier to entry for developers, too.

Key Questions

• How technically difficult is it to make MediaWiki an OAuth provider?
• If we don't do this, how else might we enable interesting uses of the write API?
• Could it somehow socially harm a large existing project?

Potential Costs

• Software developer time and effort

References

• Initial wikitech-l thread about the idea (not terribly well-received initially)
• A post I wrote about Decentralising Wikimedia
• mw:OAuth

Community Discussion

Do you have a thought about this proposal? A suggestion? Discuss this proposal by going to Proposal talk:Implement OAuth for MediaWiki (and employ in Wikimedia).

Want to work on this proposal?

1. User:I-20
2. .. Sign your name here!