Many of the use cases discussed on the OAuth list brought up the need for some form of discovery - the ability of Consumers to interact with an OAuth Service Provider without the need of a human to read documentation and write code. While OAuth sets the stage, it does not directly support interoperability.

In order to achieve full discovery the following components are needed:

• Protocol for Consumer registration - ability to establish a Consumer Key and Consumer Secret via API calls. Even if a Service Provider uses a single Consumer Key with an empty secret, that information has to be passed to the Consumer. There can be many different protocols but at least one generic is needed.
• Machine readable OAuth documentation format - an XRDS (or similar) document which can describe the OAuth endpoints and other properties of a Service Provider, such as which Consumer registration protocol it supports, what signature methods, etc. It is the machine readable version of the Documentation and Registration section.
• A way to communicate which extensions the Service Provider supports, and a way to direct the Consumer to the machine readable document from the OAuth 1.0 framework. One idea is to include special HTML tags (as used in OpenID HTML and Yadis discovery) in the human-readable Authorization Endpoint URL page that will point to the "XRDS" file. Since OAuth supports the use of the Authorization header, and the realm is defined as MAY be the endpoint, this works well.