Currently, new Wikimedia accounts are not automatically placed into the mwoauthproposeconsumer group. How should we handle this? Do users have to be in this group on Meta specifically?

See: T142317: Creating an owner-only consumer should not require an autoconfirmed account/T213760: Rethink autoconfirmed requirement for OAuth

Are you sure this is right? I see on https://meta.wikimedia.org/wiki/Special:ListGroupRights that 'Users' (anyone with a registered account) has the mwoauthproposeconsumer right, there is no mwoauthproposeconsumer group.

As per this config in CentralAuth

	// Create some local accounts as soon as the global registration happens
	$wgCentralAuthAutoCreateWikis = [ 'loginwiki', 'metawiki' ];

Anyone creating a SUL account anywhere should be automatically created an account on meta, and therefore, they can create OAuth consumers etc

I note T213760: Rethink autoconfirmed requirement for OAuth was only recently resolved, so was this documented elsewhere against something that is now out of date?

Thanks, @Reedy! This is super helpful. I've updated the task with this info.

In T249781#6042049, @apaskulin wrote:

Thanks, @Reedy! This is super helpful. I've updated the task with this info.

Cool! Just when I had read the task and wanted to confirm I wasn't missing something obvious, or as seems to be the case, something that had already been resolved recently and just got overlooked :)

Aha, I just noticed the link to https://meta.wikimedia.org/wiki/Meta:Autoconfirmed_users (that you just removed) which shows that page is out of date. Will fix it

In T249781#6042052, @Reedy wrote:

Aha, I just noticed the link to https://meta.wikimedia.org/wiki/Meta:Autoconfirmed_users (that you just removed) which shows that page is out of date. Will fix it

https://meta.wikimedia.org/w/index.php?title=Meta%3AAutoconfirmed_users&type=revision&diff=19967976&oldid=19938041

Perfect! Thanks, @Reedy!

Per discussion outside this task, it is desirable for the API Portal to present a simplified set of Grant Type choices to developers registering OAuth clients. However, because OAuth clients created from the API Portal are indistinguishable in the database from clients created via the OAuth extension, it is necessary to map this simplified list to the full list presented at https://meta.wikimedia.org/wiki/Special:OAuthConsumerRegistration/propose

Clients are assigned grant types, which map to individual rights. The available grant types, and associated rights, are listed at https://meta.wikimedia.org/wiki/Special:ListGrants

For more info on how these are configured, see, see:
https://www.mediawiki.org/wiki/Manual:$wgGrantPermissionGroups
https://www.mediawiki.org/wiki/Manual:$wgGrantPermissions

And note that grant permission configuration is distinct from group permissions:
https://www.mediawiki.org/wiki/Manual:$wgGroupPermissions

Regarding grant types, assigned to clients, I found the following rights in use by existing endpoints:

Some of these rights are not requirements for the endpoint to provide data. For example, the PageHistoryCountHandler and PageHistoryHandler will still provide data even if the requesting OAuth client does not have any grant type beyond "basic". However, they will provide less data than the web interface for users that have expanded rights on their wiki account. This is because the effective rights seen by a handler are the minimal intersection of the OAuth client rights and the wiki user rights.

It is possible that returned data is affected by additional rights that I did not find. For example, if a handler calls function foo(), which calls function bar(), which calls function baz(), which checks for a right, my investigation would not have uncovered that.

It was proposed (outside this task) to offer two options when registering an OAuth client:

• Read
• Read/Write

If we offer only those two options, and we do not want to restrict users accessing wikis via OAuth clients to a smaller dataset than they see in the web interface, the mappings would be:

• Read: basic, highvolume, viewdeleted, oversight
• Read/Write: all the above, plus something that includes the "edit" right (createeditmovepage seems like a good choice, and allows for expansion to API endpoints that we're likely to create).

If we don't want all OAuth clients to be capable of more powerful grant types like "oversight", we could define additional choices (but still fewer than available on meta). Again, note that just because an OAuth client has a grant type allowing it to do something, that doesn't mean any user of that client can do that thing. The user must also have a wiki account with that right.

Thanks, @BPirkle! The rights you suggested sound good to me. @eprodromou and @CCicalese_WMF, how does this look to you?

Looks good to me. Thanks for the analysis, @BPirkle.

Approved by @eprodromou via Slack