It would be good to group OAuth grants in terms of risk. This could be used to:
- Highlight risky grants in the consumer review interface, e.g. with a different color, to avoid OAuth admins accidentally granting risky requests without proper review.
- Group grants in the consumer proposal interface (T58022), to orient developers in terms of how much scrutiny they might expect, and to simplify the interface by hiding grants that are rarely needed.
- In the future, maybe approve non-risky proposals without review.
Grants could be grouped into the following categories:
- Not risky: permissions which most users have (so whatever a malicious actor could achieve with an app, could just as easily be achieved with spam accounts) - edit, move, upload, patrol, etc. This would include the grants basic, editpage, createeditmovepage, uploadfile, uploadeditmovefile, patrol, rollback, shortenurls, and the two OAuth-specific authentication-only grants (one of which also shares the user's email address, but that's common these days). Also viewmywatchlist and editmywatchlist as the watchlist isn't particularly sensitive information. Also privateinfo which sounds scare but in practice the only thing it's used for is email addresses and ReadingLists lists. Also highvolume which can be used for vandalism, but an app with access to many users could edit at high volumes anyway, even if it does not have permission to edit at high volume with a single user, so adding this permission doesn't really increase risk.
- Vandalism risk: permissions which typically require admin or similar access, and can be used to cause havoc but not for anything truly damaging - deletion, blocking, page protection, editing protected pages. This would include the grants editprotected, editinterface, blockusers, viewdeleted, delete, protect, mergehistory, globalblock, createlocalaccount.
- Security or privacy risk: permissions that require higher-than-admin access, and can do serious damage - JS editing, checkuser, oversight. This would include the grants import, editmycssjs, editsiteconfig, viewrestrictedlogs, oversight, checkuser. Also setglobalaccountstatus (account locking) because it can be used to hamper a security response by locking out all other accounts with the same permission. Also editmyoptions because it is hard to predict what the options will include (e.g. for Wikitech at one point it included SSH keys). Also sendemail because it can be used for social engineering (after T266969: Should emails sent via OAuth be identified as such? is fixed, this could go back to not risky). Also createaccount because it includes the tboverride-account and override-antispoof rights which can be used for social engineering.
- Internal: permissions that are too risky to hand out to anyone and are only used in Wikimedia production infrastructure. This would include the grants oauthmanageownclient and oath.
Implementation would be similar to $wgGrantPermissionGroups: a core configuration key which maps grants to groups (except the set of groups would not be extensible here), and an extension.json key for adding custom grants.