Requests for Comment/OAuth policy

OAuth is a tool for granting an application/website access to the API in your name, with limited permissions of course (it can only use permissions you actually have on your account, though). Additionally, in MediaWiki, it can also be used as a way to identify users.

This RfC attempts to establish a policy for non-owner only consumers, meaning, OAuth consumers that can be used by people other than their creator. Currently, we have no such thing, meaning it is pretty much up to whoever wants to do these, which in practice is no-one as the potential reviewer has no idea what to look for. OrangeStar (talk) 19:31, 4 May 2023 (UTC)

Proposal 1: Handling of OAuth consumer reviews
Site reliability engineers in the MediaWiki team are in charge of OAuth consumer reviews. OrangeStar (talk) 19:31, 4 May 2023 (UTC)

Support

 * 1)  This is the current status quo. While Wikimedia has a dedicated group in charge of these, I figured we don't need such a thing here. Anyone wanting to volunteer in this may be interested in joining SRE. OrangeStar (talk) 19:31, 4 May 2023 (UTC)
 * 2)  Per OrangeStar. --DeeM28 (talk) 16:20, 5 May 2023 (UTC)
 * 3)  I support and find it appropriate.  Hey Türkiye  Message? 19:34, 5 May 2023 (UTC)
 * 4)  Redmin Contributions CentralAuth (talk) 14:49, 9 May 2023 (UTC)

Proposal 2: Consumer permissions
Consumers must strive to only request the least amount of permissions required to perform their function. OrangeStar (talk) 19:31, 4 May 2023 (UTC)

Support

 * 1)  This is just good security hygiene. For example, it doesn't make sense for a consumer like the one used to verify users in Discord to request stuff like access to CheckUser and Oversight permissions, or for a mass-edit tool to request access to the DataDump permissions. OrangeStar (talk) 19:31, 4 May 2023 (UTC)
 * 2)  Per OrangeStar - common sense. --DeeM28 (talk) 16:20, 5 May 2023 (UTC)
 * 3)  I support and find it appropriate.  Hey Türkiye  Message? 19:34, 5 May 2023 (UTC)
 * 4)  Per OrangeStar. Redmin Contributions CentralAuth (talk) 14:49, 9 May 2023 (UTC)

Proposal 3: Consumer scope
The consumer must be for a tool directly related to Miraheze. Usage of the consumer for non-Miraheze purposes is forbidden and is grounds for its revocation. OrangeStar (talk) 19:31, 4 May 2023 (UTC)

Support

 * 1)  No fun allowed. This is for stuff like trying to use the consumer as a SSO system (which you can do technically), which has nothing to do with either Miraheze or a Miraheze wiki. OrangeStar (talk) 19:31, 4 May 2023 (UTC)
 * 2)  It would not make sense for this to not be the case. --DeeM28 (talk) 16:20, 5 May 2023 (UTC)
 * 3)  I support and find it appropriate.  Hey Türkiye  Message? 19:34, 5 May 2023 (UTC)
 * 4)  per OrangeStar. Redmin Contributions CentralAuth (talk) 14:49, 9 May 2023 (UTC)

Comments

 * 1)  I am afraid I have very little knowledge in the field of IT so before being able to vote for any of these more technical proposals could you provide a concrete example of what an "Oauth consumer" looks like? I am not able to picture a concrete/practical example of one so it is difficult for me to be able to express an opinion either way without understanding this process.--DeeM28 (talk) 14:50, 5 May 2023 (UTC)
 * I should have expected that, oops. I'll try to explain the buzzwords:
 * An OAuth consumer is a third-party application or website looking to either use the MediaWiki API in your name or rely on Miraheze to authenticate you (like for example Phabricator, TSPortal, or Wiki-Bot on Discord). An example of a recently-approved one is Special:OAuthListConsumers/view/f7d7b6d85767eb1b443f283b63d46d5b. The process of using them involves your browser being redirected around to ensure you authorize this action (best example is to try to login to Phabricator, to see it in action). "Applicable grants" is the name given to the pack of permissions these consumers are requesting, and "Applicable project" is the wiki the consumer should work on, most commonly all. mediawiki.org has a help page for OAuth directed to users. OrangeStar (talk) 15:18, 5 May 2023 (UTC)
 * Thank you for this helpful explanation! --DeeM28 (talk) 16:20, 5 May 2023 (UTC)

Proposal 4: Free software only
The consumer must be free software, that is, software that grants the users the freedom to run, copy, distribute, study, change and improve (aka software available under any of the major open source/free software licenses). OrangeStar (talk) 20:10, 4 May 2023 (UTC)

Support

 * 1)  This will probably be the more controversial section, but I'd like to say I fully support this. Having the source code available will make reviews easier, as the reviewer will be able to see if best practices in terms of security are being followed, and is also keeping with the spirit of Miraheze, being 100% open source (we aren't currently due to the CAPTCHA, but I like to think we are trying). OrangeStar (talk) 20:10, 4 May 2023 (UTC)

Abstain

 * 1)  I prefer to remain neutral for now, my opinion may change when our officials vote for this section, but for now I am neutral.  Hey Türkiye  Message? 19:34, 5 May 2023 (UTC)

Oppose

 * 1)  I would support this as long as there would be a possibility for a limited exception to this. I support such a role but do not think it should be fully absolute without exceptions in some circumstances if they may arise. --DeeM28 (talk) 16:20, 5 May 2023 (UTC)
 * 2)  Reviewers need to review the source code but they can do so even if the code is not released under a FOSS license. Redmin Contributions CentralAuth (talk) 14:49, 9 May 2023 (UTC)

Proposal 5: CSP-like reviews for consumers with email access
Identity verification consumers can request access to an account's email address. This proposal, if passed, requires that these consumers pass a CSP-like review, meaning a review where the consumer will have to fulfill the requirements at Tech:CSP Policy. Passing this review will then be necessary for approval, but will not be added to the actual Miraheze CSP. OrangeStar (talk) 21:19, 4 May 2023 (UTC)

Support

 * 1)  I think this is a good idea. OrangeStar (talk) 21:19, 4 May 2023 (UTC)
 * 2)  Redmin Contributions CentralAuth (talk) 14:49, 9 May 2023 (UTC)

Abstain

 * 1)  Due to my limited understanding I will refrain from voting here but I am not sure whether the CSP review process can be comparable to an OAuth consumer? --DeeM28 (talk) 16:20, 5 May 2023 (UTC)
 * 2)  I prefer to remain neutral for now, my opinion may change when our officials vote for this section, but for now I am neutral.  Hey Türkiye  Message? 19:34, 5 May 2023 (UTC)

Comments

 * 1)  I just wanted to note that in relation to SRE matters the effect on a proposal such as this one is a recommendation as the community can't formally set out internal rules for SRE to follow as that's a separate process. --Reception123 (talk) ( C ) 07:59, 5 May 2023 (UTC)