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

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)

Web-based editing assistance tool
(fill me in)

Comments/votes

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)

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)

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

User story: add yours here
Comments/votes