⚓ T103587 Improve OAuth application approval workflow

	Subject	Repo	Branch	Lines +/-
	Link to user's global accounts in consumer proposal log	mediawiki/extensions/OAuth	master	+56 -2
	Show links in OAuth management form	mediawiki/extensions/OAuth	master	+0 -1

Status	Subtype	Assigned	Task
Open		None	T103587 Improve OAuth application approval workflow
Open		None	T62380 OAuth developers should be able to change what grants their application asks for instead of having to submit a new application
Open	Feature	None	T65712 OAuth: Developers should be able to revoke their own tool's approval
Open		None	T60937 Add "under development" stage before "proposed" stage for OAuth consumers
Duplicate		None	T96157 Add a separate queue for approval, and a button to submit consumers to it
Open		None	T59631 OAuth developers should be able to change some of the parameters they registered an application with instead of having to submit a new application
Resolved		Anomie	T87395 Make "bot" or "personal use" apps a better experience
Resolved		• jcrespo	T121335 Create oauth_registered_consumer.oarc_owner_only column on metawiki
Open		Tgr	T67750 Low-risk OAuth consumers should be automatically approved
Resolved		Tgr	T290790 Group OAuth grants by riskiness
Resolved		Tgr	T350173 Automatic approval of OAuth apps should be clear from Special:Log
Open	Feature	None	T59590 Application cannot be managed by multiple users
Resolved		Tgr	T109163 Remove queue name from OAuth consumer management URL
Duplicate		None	T116681 OAuth consumer registration success message should include instructions on how to ask for review
Open		None	T147611 Allow users to opt in to in-development OAuth consumers
Open		None	T154777 Discussion area for each OAuth consumer proposal
Open		None	T109156 Investigate converting OAuth to use ContentHandler
Open		None	T159789 Include information about OAuth app review process and criteria into the interface
Resolved		Tgr	T159788 Establish OAuth app policy for Wikimedia wikis
Open		None	T350554 Make it easier in the OAuth consumer review form to assess whether an app / developer is trusted

Tgr created this task.Jun 23 2015, 7:31 PM

Tgr raised the priority of this task from to Needs Triage.

Tgr updated the task description. (Show Details)

Tgr added a project: MediaWiki-extensions-OAuth.

Tgr subscribed.

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJun 23 2015, 7:31 PM

Tgr added subtasks: T62380: OAuth developers should be able to change what grants their application asks for instead of having to submit a new application, T65712: OAuth: Developers should be able to revoke their own tool's approval, T60937: Add "under development" stage before "proposed" stage for OAuth consumers, T96157: Add a separate queue for approval, and a button to submit consumers to it, T59631: OAuth developers should be able to change some of the parameters they registered an application with instead of having to submit a new application, T87395: Make "bot" or "personal use" apps a better experience.Jun 23 2015, 7:40 PM

Tgr added subtasks: T67750: Low-risk OAuth consumers should be automatically approved, T59590: Application cannot be managed by multiple users.Jun 23 2015, 7:52 PM

Tgr added a project: Epic.Jun 23 2015, 7:54 PM

Tgr triaged this task as Medium priority.Jun 29 2015, 7:08 PM

Tgr set Security to None.

Ricordisamoa subscribed.Jun 29 2015, 8:50 PM

Tgr added a subtask: T109163: Remove queue name from OAuth consumer management URL.Aug 15 2015, 1:17 AM

Tgr added a subtask: T116681: OAuth consumer registration success message should include instructions on how to ask for review.Oct 26 2015, 10:34 PM

Ricordisamoa awarded a token.Oct 28 2015, 6:39 AM

Anomie closed subtask T87395: Make "bot" or "personal use" apps a better experience as Resolved.Dec 28 2015, 11:08 PM

Luke081515 closed subtask T67750: Low-risk OAuth consumers should be automatically approved as Declined.Feb 2 2016, 12:23 AM

Luke081515 reopened subtask T67750: Low-risk OAuth consumers should be automatically approved as Open.Feb 2 2016, 12:45 AM

tom29739 subscribed.Mar 17 2016, 9:30 PM

tom29739 awarded a token.Mar 28 2016, 11:10 AM

tom29739 added a parent task: T134004: Confirmation dialog for 'OAuth authenticate only (no api access)' right is not needed.Apr 29 2016, 8:52 PM

Tgr removed a parent task: T134004: Confirmation dialog for 'OAuth authenticate only (no api access)' right is not needed.Apr 29 2016, 11:25 PM

• dpatrick subscribed.Jul 6 2016, 12:55 AM

Tgr closed subtask T109163: Remove queue name from OAuth consumer management URL as Resolved.Jul 29 2016, 6:37 AM

After thinking about it a bit I think a better workflow would look something like this:

"under development": this is the initial state for new consumers. Invisible for everyone but the owner (and maybe OAuth admins); works for the owner but does not work for anyone else (like the "proposed" state currently). All properties are freely editable. (This means dealing with the case when grants are edited and the owner already did the authorization; but since it's only for testing at this point, it should be fine to just delete the authorization.) The owner can move it to "proposed" state (which sends a notification to OAuth admins).
"proposed": visible to everyone but only works for the owner. Cannot be edited anymore (to avoid race attacks). OAuth admins can move it back to under development (to ask for description changes etc) or "approved" or "rejected" state.
"approved": visible and works for everyone, cannot be edited. Owner and admins can move to "disabled".
"disabled": visible for everyone, works for no one (or maybe the owner only, for debugging?). Cannot be edited. Admins can move to "approved" (maybe "rejected" too?).
"rejected": visible for everyone, works for no one, cannot be edited. Admins can move to "approved".
"expired": I think we can kill this state and the concept of proposal auto-expiration. Existing expired records would be turned into to "rejected".

"Cannot be edited" means most fields cannot be edited. Usage restrictions and the RSA key are always editable and the secret can always be regenerated. The owner is always the only one who can edit.

When disabling or rejecting, the consumer can also be suppressed if the user has the rights (this is same as the current behavior).

As currently, the owner would be notified of every state change unless they performed it themselves.

This would take care of T60937: Add "under development" stage before "proposed" stage for OAuth consumers, T65712: OAuth: Developers should be able to revoke their own tool's approval, and the most painful part of T59631: OAuth developers should be able to change some of the parameters they registered an application with instead of having to submit a new application, while avoiding the troubles associated with modifying a consumer which has already been authorized by some users.

Tgr mentioned this in T60937: Add "under development" stage before "proposed" stage for OAuth consumers.Sep 9 2016, 1:56 AM

Tgr mentioned this in T107230: OAuth sometimes stops providing tokens for a user, even though the app was not deauthorized.Sep 9 2016, 2:00 AM

Tgr added a subtask: T147611: Allow users to opt in to in-development OAuth consumers.Oct 7 2016, 12:37 AM

Tgr added a subtask: T154777: Discussion area for each OAuth consumer proposal.Jan 6 2017, 11:10 PM

Tgr mentioned this in T96154: OOUI-ify the management interfaces (special pages) for OAuth.Jan 30 2017, 9:42 PM

Tgr raised the priority of this task from Medium to High.Mar 7 2017, 3:57 AM

Tgr moved this task from Backlog to UI/UX on the MediaWiki-extensions-OAuth board.

Tgr added a subtask: T109156: Investigate converting OAuth to use ContentHandler.Mar 7 2017, 4:20 AM

Tgr added a subtask: T159789: Include information about OAuth app review process and criteria into the interface.May 15 2017, 10:13 AM