Presumably the reason why a user would want to revoke some permissions during the initial authorisation is because the application is asking for more than the user expected. If the application was not asking for more than it needed but it's just that the user isn't aware of what the application really needs, then we've just let the user break the application's functionality right at the first step, which isn't good. On the other hand, if the application was actually asking for more than it needed, then the OAuth admins failed to vet the initial request from the consumer properly, which means the real problem was caused way before the user sees the authorisation request.

I'm open to being convinced for the need for this, but right now I'm not seeing the reason for this. I don't want to add in something that only patches up a problem caused elsewhere.

Some (read as "my") applications have too many features and normal users coming for some specific purpose never use all of them. However power users (read as "myself") use them so my application must request many permissions, because power users can't give that application more permissions than what it requests.

Maybe another resolution is to turn "Applicable grants:" into "Permissions requested by default", and allow granting permissions from user side, in addition to just revoking permissions.

This was actually the intended feature originally, but the UX team asked us to simplify the /authorize screen, including not doing this feature when we brought it up once. We could probably get away with adding an "Advanced" option that takes power users to an /authorize screen with more options though.

Liangent's particular use case is probably not the best use of this, however. In general, it would be best to design different versions of the bots for the major categories of different users, and each bot would have its own OAuth Consumer key.

Similar to Liangent's idea of allowing apps to add permissions, another feature that has been requested for a while is to make it possible for Consumers to upgrade the rights, and have a better UX for doing this. That's why we have the Consumer version number set by the app developer. The flow would probably look something like:

• The Consumer would send the user back to /authorize
• We see the user has already authorized a previous version of this Consumer
• We prompt the user that <app name> would like "more permisssion" (or something like that), showing them the added and removed grants
• User grants the new set of permissions, and we automatically revoke the old authorization

Made this more general. I think the best way forward is to allow applications to request any subset of the grants it has registered for. We already store right grants individually so that would not require changing the acceptance table, but the list of grants would somehow need to be included in the request, and the request should automatically succeed if a superset of those rights is already granted. That way the application could request the fundamental rights first, and additional rights in context once they are actually needed. That's the direction mobile apps are moving towards as well.

Leaving the selection of which individual grant to refuse to the user is a bad idea, since that would require the app to gracefully handle all failure scenarios arising from grant combinations that don't really make sense and make the application unable to perform its basic function; that kind of error-handling code would probably not get much attention.

That sounds sane to me

any update on this?

In T59505#5344353, @Viztor wrote:

any update on this?

OAuth is not resourced currently. Changes happen whenever someone has free time (and nothing more important to do with it).

In T59505#594438, @liangent wrote:

Some (read as "my") applications have too many features and normal users coming for some specific purpose never use all of them. However power users (read as "myself") use them so my application must request many permissions, because power users can't give that application more permissions than what it requests.

Maybe another resolution is to turn "Applicable grants:" into "Permissions requested by default", and allow granting permissions from user side, in addition to just revoking permissions.

Uhm. As workaround I would actually think about two OAuth consumers: one for the login button of normal users, and few privileges; and one for your login button, for administrators with all privileges and all bells and whistles checked.