The use cases covered in the spec are not imaginary - rather very realistic.
At WSO2 we have integrated OAuth 2.0 support in to WSO2 Identity Server and WSO2 API Manager. Currently we do support all four grant types defined in the core specification. Also - we have very strong customer use cases for SAML2 grant types as well - which we have already started implementing.
If you look at the core specification - there are two key roles involved.
Resource Owner : An entity capable of granting access to a protected resource. When the resource owner is a person, it is referred to as an end- user.
Client : An application making protected resource requests on behalf of the resource owner and with its authorization. The term client does not imply any particular implementation characteristics (e.g. whether the application executes on a server, a desktop, or other devices).
Now if you look at the complete OAuth flow - you will notice that - all are initiated by the Client. This has ignored the use cases where the Resource Owner has to initiate the flow. Let me give a more concrete example.
I am a user of an online photo sharing site. There can be multiple Clients like Facebook applications, Twitter applications registered with it. Now I want to pick some client applications from the list and give them the access to my photos under different scopes. Validation of the trust/legitimacy of the registered applications can be carried out in other means.
That is just an example from social networking point of view. But there are more concrete enterprise use cases as well.
Let's take an access delegation use case.
I am an employee of Foo.com. I'll be going on vacation for two weeks - now I want to delegate some of my access rights to Peter only for that time. Conceptually OAuth fits nicely here. But - this is a use case which is initiated by the Resource Owner - which does not addressed in the OAuth specification.