Are there any plans to support self-documenting oauth service providers?

I realize that what we are dealing with right now is simply a 1.0 Core spec, but it seems to me that some self-documentation features bundled in every OAuth service provider (or as a strongly-suggested extension) would open up some interesting possibilities.

For example, section 4.2 boils down to "To get your site working with an OAuth provider, you'll need to dig through their documentation that is good, bad, or non-existent". This seems like a flaw, given the emphasis placed on documentation in 9 out of 10 web applications. Of course, no API works without documentation. That said, you could leave less responsibility to the Service Provider by some simple machine readable cues to the structure of a service provider.

Take for example including links in the service root of an API that point to the appropriate urls needed to support OAuth. rel="oauth/request_token", rel="oauth/authorization", rel="oauth/access_token", and perhaps even rel="oauth/consumer_key_provider". Even just doing something so simple like this would allow for some discoverablity.

At that point, you have the basis for pairings to be built upon OAuth that are closer to being spontaneous while maintaing flexibility for the service providers. Standards built upon OAuth would have less overhead. Imagine something like an "OpenPhotoExchange", a standard that allows people to transfer all of their photos between competing photo sites, built upon OAuth. Sort of a "balance transfer" for photo sites. Currently, such a system would require every consumer to visit each service provider they wanted to support to get the required urls, which is a lot of effort given how many photo sites their are. Creating the mesh of applications to have something like an OpenPhotoExchange would require too much effort for participants above and beyond actually implementing the standard, IMO. Even just the simple links described above would reduce a potential participant's effort to basically navigating to the provided consumer key generator and logging the key into their system.

Tools could be built around these cues, allowing client libraries to adapt automatically to changes in API infrastructure. Service providers could use DNS to segment their consumers.

I'm kind of rambling at this point, but IMO such an extension to would make OAuth a much better substrate on which to grow.