Current draft of OAuth 2.0 http://datatracker.ietf.org/doc/draft-ietf-oauth-v2/ does not seem to define a standard way of defining “scopes”. It is totally Authorization Server dependent. If it were to act as a distributed system, this has to be standardized.
Also, the scope may require dynamic input parameters. The current spec draft does not specify it either. In fact, scope is nothing but the input parameter for the access_token right now.
The better approach, IMHO, is to define a generic way of what has been requested, instead of just defining proprietary “scope” strings.
For example, instead of defining an Authorization Server specific scope string for “Contact/Home”, define it as a generic registered string, such as “og”, so that one can specify it as
etc. This is a much more granular way of giving permissions.
This has a side effect:
* The requests are longer
This is the rationale for having “request_url” for the flows.
One can put all the extension parameters in the “request_url”.