Requests for comment/OAuth handover

The following request for comments is closed. No consensus. This RFC has been opened for more than one year. Given the few comments on talk and the concerns by some users, the low participation and the outstanding questions I feel there's no consensus for a community handover of this permission yet. —MarcoAurelio 16:49, 20 November 2016 (UTC)

---

Background

OAuth is a standard way of sharing authorization between a website and external applications, by which a user can tell the website that an external application is allowed to perform certain actions in the user's name. Wikimedia sites have implemented this standard in late 2013, but due to very limited resources, there never was much attention given to the administration of these applications, which is now done by a random group of developers.

OAuth administrators do the review of new applications; every application needs to be approved by an OAuth admin before users can start using it. This has been done so far on an ad hoc basis and the requirements for OAuth apps will also need to be fleshed out (Chris Steipp provided a draft for that).

It is also OAuth administrators who can block (and unblock) an already approved application if it is somehow causing problems.

Proposal

We would like to hand over OAuth administration to the community so that selecting OAuth administrators and deciding about OAuth policies can be done in a more transparent manner. This would involve creating a new functionary group (or possibly selecting an existing one, such as stewards), defining the process of adding and removing group members, creating the policy or guideline by which new apps are judged, and creating the necessary documentation so that OAuth admins can do their job.

Your involvement in all that would be highly appreciated.

Draft approval policy

When approving an OAuth application, the reviewer is stating, to the best of their knowledge:

1. This Consumer is likely to respect the intent of the users authorizing it. For example,
   • the Consumer's author is a respected developer in the MediaWiki community, or
   • the Consumer's source code is public, and it is likely that the website the callback url points to is really running that code, or
   • the Consumer is requesting rights that are difficult to abuse ("Authentication only" or "basic rights" only really can't be used for anything abusive), or the description of the application describes functionality that seems likely to require the requested permission (we trust users to be responsible when handing over rights).
2. This Consumer is likely to protect the privacy of the authorizing users. For example,
   • the Consumer has a privacy policy, or
   • the Consumer is open source, and limits the amount of data it logs / stores about the users who approve it.
3. This Consumer isn't likely to be confused with another Consumer, owned by another user, based on its name or description,
4. The Consumer is likely to protect the secrecy of their Consumer's Secret.
   • Consumers that are desktop apps, mobile apps, or "thick" javascript apps should not be approved at this time.

Some specific things an admin should check for:

• If the application doesn't use https for their callback, they should have a good reason for not doing so
• The callback shouldn't have an overly broad callback prefix (if enabled), and there shouldn't be a way for the callback prefix to prefix an open-redirect url on the target site

update: I missed this when writing the proposal but Deskana also wrote a draft policy some time ago; it's available at User:Deskana_(WMF)/OAuth_consumer_guidelines

Glossary

Discussion and documentation of OAuth-related features can be confusing (there are multiple standards with slightly different vocabulary, and they are all hard to understand so we try to use different terminology in MediaWiki software, not always consistently). This section is an attempt to clarify things. Please request additions if something is not clear.

• consumer, client, application, app, tool: these all mean the same thing - a software that you can allow to perform actions in your name on some Wikimedia project.
• consumer (client etc.) secret - a kind of password that is only known to the application (but not to the users of the application).
• grant - a permission from a user to an application to do a certain type of thing (e.g. delete pages) under the user's name. Applications need to define up front what kind of grants they are going to ask for.
• callback, callback url: the URL where your browser is sent back after you grant permissions via the authorization dialog (this thing).

Comments

See Talk:Requests for comment/OAuth handover.