Security experts at RSA suggest adding guidance on the use of OAuth and openID

1. Since both OAuth and OpenID Connect (OIDC) define a broad framework, they offer a number of options in the based specification. Also there are new extensions and additions to these specs (especially for OAuth) that would add additional security or interoperability features. Therefore, when these standards are used in other specifications (such as in your case OData using OAuth), it is important to define a profile for the base spec (i.e. defining an Aoth Profile for OData) for two reasons:
a. To define a concrete use of the base standard by eliminating the many options and clarifying the use model for the sake of interoperability
b. To adopt the unique combination of attributes, options, and extensions defined for the base standards that meet the needs of the consuming spec (i.e. OData)
2. Some examples of what profile can tidy up regarding the base standard, OAuth in this case, are:
a. Is Dynamic client registration required?
b. Is Discovery service required to be supported by Authorization Service?
c. Handling of Token revocation
d. Is the recent RFC for mitigating interception of Authz code required (PKCE [RFC 7636](https://datatracker.ietf.org/doc/rfc7636/))
e. OAuth Token format (e.g. JSON format - [RFC 7519](https://datatracker.ietf.org/doc/rfc7519/))
f. Is Introspection service required for resource server being able to query the Authorization server for metadata about the token ([RFC 7662](https://datatracker.ietf.org/doc/rfc7662/))
g. Concrete or range-recommendation on token lifetimes
h. Is it required for better security to mandate Proof of Possession (POP) ([RFC 7800](https://www.rfc-editor.org/rfc/pdfrfc/rfc7800.txt.pdf)) instead of the Bearer token?
3. A similar (but simpler) profile can be defined for OData use of OIDC
4. A good set of sample profiles you can examine for more clarification on above suggestions are the OAuth and OIDC profiles defined for use of OAuth in Healthcare ([HEART profiles](http://openid.net/wg/heart/)):
a. [HEART OAuth Profile](http://openid.bitbucket.org/HEART/openid-heart-oauth2.html#rfc.section.3.2.2))
b. [HEART OIDC Profile](http://openid.bitbucket.org/HEART/openid-heart-oidc.html))
5. A good place for getting a broad view on all extensions and additions to OAuth core spec is the IETF DataTracker for OAuth that lists the approved RFCs as well as ongoing draft specifications:
a. https://datatracker.ietf.org/wg/oauth/documents/
Hope this helps as opposed to just add confusion and complexity

In your particular case, depending on the use cases for OData, you may decide some of the above are unnecessary. But even then, if not a formal profile, perhaps a set of implementers guidelines should address the areas of the OAuth spec that are ambiguous or too broad.