OAuth (obsolete info)/User stories

This is a place to collect user stories for OAuth. Here are the hypothetical users for the stories:

• Richa - a steward and administrator on several projects
• Skye - an experienced editor with a good reputation on wiki, but no special permissions
• Caroline - a beginning editor, with less than 100 edits on her home wiki
• Clay - a Wiki reader without an account
• Jimar - a feature developer setting up a wiki on Labs
• Bao - a Gadget developer
• Ryan - a bot author
• Jon - runs a web service to support WikiProjects

Labs testing for editing

Skye has heard about a new feature in development, and found out that the feature is available on Labs, being developed by Jimar. The wiki is at unicorntears.wmflabs.org. Skye would like to test this feature, so visits unicorntears.wmflabs.org. Jimar has configured unicorntears not to allow anonymous editing, but has configured it so that anyone with a valid CentralAuth account not blocked on mediawiki.org can edit. Skye clicks on the edit tab, is directed to a login page on mediawiki.org. After she logs in, she is redirected back to unicorntears, where she can edit.

Comments/votes

This is either a case for OAuth psuedo-authentication, or for OpenID (or SAML) -- RobLa-WMF (talk) 20:59, 27 April 2012 (UTC)

Securely uploading media to Commons from 3rd party website

The website instacommons.com allow users to send their pretty pictures to Wiki Commons automatically. Caroline registers with instacommons.com, then clicks a button to grant instacommons.com limited access on her behlf. She logs in to Wikicommons, approves that instacommons.com can use the "Upload Files" function on her behalf for a particular time period. After this, instacommons.com receives a token that allows it to upload pictures for as long as the token is valid. Caroline is confident that instacommons.com doesn't know her Wikimedia password, nor can instacommons.com make arbitrary page edits on her behalf that could harm her reputation.

Comments/votes

The title of this user story is too generic, that's one of the broad functions of OAuth, not a user story. I changed it to be more specific, hope it's ok. --DarTar (talk) 16:49, 30 April 2012 (UTC)

This will be highly desirable for photo upload apps, too (see Third Party Mobile Apps below). Eventually this could be relevant on Wikipedia when uploading images to Commons from the context of a WIkipedia article, and especially when SUL is not available. (It is quite possible that a username on Commons is not available on Wikipedia, simply because there are so many more users on Wikipedia.) --Philinje (talk) 20:48, 23 May 2012 (UTC)

Web-based editing assistance tool

Third party apps that enable various forms of editing support would be covered below under Third Party Mobile Apps. Or there are variations of the Huggle user stories that would fit here.

Comments/votes

May have use cases for power-edit tools, vandalism fighting tools, editors integrated with citation managers.

Editing Wikidata through Wikipedia

Caroline is doing some maintenance work on an article in her home Wikipedia. She notices that there is a version of that article in Hungarian that is not connected to her home wiki yet. Instead of going to Wikidata, where the interwiki links are maintained, she uses an in-place editor user interface widget (similar to what is suggested in the Interlanguage design pass by the WMF). In order to edit the links in place from inside Wikipedia, Wikidata needs to offer OAuth to Wikipedia. Both Wikidata and Wikipedia might be using the same SUL.

Comments/votes

I am not sure if I described the story correctly. Please let me know if something is not clear. --Denny Vrandečić (WMDE) (talk) 16:01, 30 April 2012 (UTC)

Depending on how Wikidata is implemented, CentralAuth / SUL may be a better tool for this usecase 216.38.130.162 22:36, 1 June 2012 (UTC)

Huggle 3x

(This is actually how this is going to work in future)

The application running on pc of user open embedded browser directed to login page of a project which user wants to logon to, the user put the credentials in that and the website return back the login token which is grabbed by application and used in order to perform edits to wiki using api.

Comments/votes

For better security it could be possible to open the external browser and have user put the token back by hand, but it would be annoying. 90.183.23.27 08:48, 30 April 2012 (UTC)

The mobile team talked to me about a similar application, which would be nearly the same use case, although even more cumbersome to input the token by hand. So it may be worth it to support "Resource Owner Password Credentials" CSteipp (talk) 19:06, 9 May 2012 (UTC)

Huggle web

(This is actually how it could work right now if it was possible)

The web application open a window of wikimedia project with return url, user insert the credentials there and return url open back the web application passing the token into it. Token is cached by the application and used as long as user is logged in to perform edits to project.

Comments/votes

Third Party Mobile Apps for Article Editing

Caroline is a new Wikipedia user who loves to use her mobile phone. She recently downloaded BrandNewShinyWikipedia App that allows her to post comments on users talk pages and add to her watchlist. She loves these new features but is uncomfortable with giving this third party (non wmf) app her Wikipedia log in info.

Third Party Mobile Apps watchlist addition

Caroline again. This time adding a page to her watchlist.

Bot editing specfic namespaces

Ryan is a bot author who is running a service that occasionally triggers updates in a wiki. He doesn't fully trust the server that the bot is running on, so would prefer the bot only create/delete/edit in a set of namespaces. It should also be able to read its watchlist to see when pages are updated.

Comments/votes

It's probably possible to handle the namespace editing via a bot account and group priveleges. It living on an untrusted server makes the OAuth credentials important. -- Ryan Lane

The important distinction about this use case is that there may not be ready access to a web browser for a complete transaction in real time.

Third party WikiProject social network/online community platform

Jon runs a website to provide dedicated support to WikiProjects. The project allows social network features to allow WikiProject members to add each other as contacts, or send each other messages. Instead of creating a totally separate space for user 2 user communication, Jon wants to allow users to post messages via Wikipedia's User Talk pages but with a nicer interface. To do this, it needs to allow WikiProject members to post messages to each other's User Talk page on their behalf. (Existing project U Washington will be working on with NSF funding)

Comments/votes

Editing is possibly limited to a specific namespace (User talk)

Third-party moderation tool

• new page patrolling
• feedback (AFT/Moodbar) moderation

limited to specific permissions other than edit

Game-like interfaces to do large-scale maintenance operations

• Add categories
• Correct errors
• Add metadata to images to improve image search

Delegating fine grained rights

Richa trusts Skye, but not sooo much, and only during the holidays. Richa wants to allow Skye to moderate a group of pages, but noting else. Richa, selects manually these pages, selects the rights he wants to grant for each page, selects the start and end date of the derogation and, of course, select a user: Skye. Richa goes on holidays, Skye takes care of moderating the group of pages. --ClementD ([[User talk:ClementD|talk]]) 08:20, 8 June 2012 (UTC)

Supporting web apps on mobile devices without requiring password logins or explicit device flow support

Skye has a new B2G powered mobile phone wants to try out a new "Spoken Wikipedia Recorder" web app which will allow him to make voice recordings with his phone, manage the recordings offline and edit them, and then have them uploaded to Wikipedia and automatically placed into articles as a spoken Wikipedia voice-over. "Spoken Wikipedia Recorder" needs to log in to Wikipedia as Skye so it uses OAuth and sends him to Wikipedia's OAuth page. Skye does not want to log in to Wikipedia in full on his phone and finds that entering his very well thought out and secure password is annoying on his phone but is already logged in on his laptop. So instead of logging in on his device Skye taps the "I'm already logged in on another computer." button on the OAuth page. The page asks him to visit a page on Wikipedia on the computer he is already logged in and enter an 8-digit number into it, saying it'll expire in 1 minute. Skye opens up Wikipedia on his laptop and goes to the url he was given. On that page he enters the 8-digit number displayed on his phone and submits the form. It then tells him that he should go back to his device. Skye unlocks the lock screen on his phone bringing the authorization page back into view and taps the "Proceed" button on it. He is then asked if he wants to "Allow" or "Deny" access to his Wikipedia account to "Spoken Wikipedia Recorder". Skye taps "Allow" and is sent back to "Spoken Wikipedia Recorder" and can now start recording article voice-overs.

Supporting anonymous read-only clients with rate-limit reductions

Jon's WikiProject web service offers an open tool available to everyone that scans Wikipedia's read-api for pages that need the attention of members of a WikiProject. Wikipedia's API has a 500 entry limit on some api queries but Jon would like is webservice to be able to make the 5000 entry queries normally reserved for bots. Jon's webservice doesn't need access to the write api, nor does it need bot permissions. So it doesn't make sense to register an account for the webservice and make it login. So Jon registers an OAuth client on Wikipedia for his webservice. Jon makes a request to a sysop to have a "Rate limit reduction" permission applied to his OAuth client. After that is done Jon makes his webservice make a "Client Credentials Grant" to Wikipedia using the credentials of the OAuth client he registered. After doing so his webservice has not been logged in as any specific user and is still an anon but it now has the advantage of being able to make 5000 entry queries from Wikipedia's read api.

Other Comments

• Comment: OAuth is extremely useful to the OAuth 'Service Providers' in tracking user's internet use, and is already exploited by (at least) FB as a form of webbeacon. Every token negotiation involves a connection to the authority. - Amgine (talk) 14:03, 24 May 2012 (UTC)

Very important that we are clear about the implications of authorizing a Client 216.38.130.162 22:36, 1 June 2012 (UTC)

update paths

I'd like to add one thing to that. There should be a way for an 'app' to update the required user rights. The reason is that tools often evolve and gain more capabilities while they grow and will thus at regular times will need more permissions. You also want to avoid that 'overly' broad set of permissions is being requested because developers 'expect' to use them 'soon'. Having a good way integrated into the system to make this possible seems like an obvious requirement.

Apps define the scope (required user rights) when they request an access token, not when it is registered. The scope is tied to the authorization returned to the app. When an app needs new permissions it sends the user back to the authorization endpoint with a different scope and the user clicks allow again to re-authorize the app. This is the desired way to do things, since apps should not be able to get more permissions to do things without the user saying that it's okay with them for the app to do that.

The only special case we might want to take into account would be looking at the client_id, checking for a prior authorization, and modifying the auth UI to show the user specifically what 'new' permissions the app is asking for. Daniel Friesen (Dantman) (talk) 06:42, 14 July 2012 (UTC)

Summary

User Story	OAuth Implications	Wiki Rights Used
1. Labs testing for editing	Might be a better use of OpenID?	Authentication
2. Uploading media to Commons from untrusted 3rd party website	Confidential Client Typical Web-Server Flow / Authorization-Code Grant	upload rights
3. Uploading media to Commons from desktop application	Public Client; Device flow, or cut-and-paste Auth-Code	Upload, reupload, metadata editing rights
4. Web-based editing assistance tool	Confidential or Public Client; Web Server or User-Agent (Implicit) Flow, depending on implementation; CORS support may be necessary for Implicit flow.	Rights: power-edit tools vandalism fighting tools editors integrated with citation managers
5. Editing Wikidata through Wikipedia	Might be covered by CentralAuth? Web Server or User-Agent	Editing Articles
6. Huggle 3x	Public Client (Desktop App) cut-and-paste Auth-Code	Mangement / rollback
7. Huggle web	Confidential Client Web Server Flow, or could use User-Agent	Mangement / rollback
8. Third Party Mobile Apps article editing	Public Client device flow	Article Editing Rights
9. Third Party Mobile Apps watchlist addition	Public Client device flow	Watchlist Editing Rights
10. Bot editing specfic namespaces	Public Client (likely) device flow, or cut-and-paste Auth-Code No access to embedded browser	Editing Articles
11. Third party WikiProject social network/online community platform	Confidential Client Authorization Code Grant, with long refresh token	Editing user talk pages
12. Third-party moderation tool	Public client User-Agent Flow	Management rights
13. Game-like interfaces to do large-scale maintenance operations	Public or Private Server or User-Agent Flow (depending on implementation)	Edit rights
16. Supporting anonymous read-only clients with rate-limit reductions	Confidential client Client Credentials Grant	'apihighlimits' user right available to anons with a confidential oauth grant

Requirements

Based on these user stories, it seems like we can make these statements about the project:

1. MediaWiki should act as both an "authorization server" for access, and a "resource server" for MediaWiki content.
   1. As part of this project, MediaWiki does not need to support using OAuth as a client, to access resources from other OAuth-protected services.
2. MediaWiki should allow Users to grant only specific rights to an application, which are a subset of the rights they have on the MediaWiki instance
   1. The desired set of rights seem to mappable to the existing user rights: Manual:User rights
3. MediaWiki Users should be able to revoke an application's rights at any time
   1. The User needs to be able to access a list of applications with granted rights somewhere on the MediaWiki instance
   2. MediaWiki might want to provide a way for an App to know it has been revoked
4. MediaWiki should support an "Implicit Grant" or "User-Agent Flow", because several use cases are for mobile, desktop, and javascript applications.
   1. This requires an application registration process (along with the corresponding pages in MediaWiki), to register a approved redirect url (or very limited url pattern)
   2. Because of this requirement, it does not seem necessary at this time to support Unregistered Clients
5. 3 of the use cases would benefit from a "device flow", or a special redirect URI that allows the user to cut and paste the authorization token into the client.
6. The client authorization process needs to clearly remind users of the privacy implications of using a third-party app
   1. The app will know the MediaWiki user's identity
   2. The MediaWiki instance will know when the User uses the app
7. 1 of these use cases would benefit from the OAuth 2 "4.4. Client Credentials Grant" and the ability for right such as apihighlimits to be granted to anons using an OAuth grant.