Tests for the client validation changes include the following
1) specify one client based token grant and access by another client
2) specify token grant to one client and revoke by same client and reuse of a revoked token by the same client
3) specify token grant to one client and revoke by a different client
4) specify token grant to one client, revoke by a different client, and reuse by the original client
5) specify low privileged token grant to one client, specify high privileged token grant to same client, use of both tokens by the same client
6) specify low privileged token grant to one client, access low privileged token by another client
7) specify user privileged token grant to one client, specify token grant by same user to another client, clients exchange token
8) specify user privileged token grant to one client, specify token grant by different user to same client, client swaps token
9) specify user privileged token grant to one client, specify client to request several tokens until a large number.
10) specify user privileged token grant to multiple clients until a large number of clients reached
11) specify user privileged token grant and revoke to same client a large number of times

Delegated tokens or bearer tokens
The RFC makes special provisions for bearer tokens. Bearer tokens can originate from any source to access any resource protected by these tokens. Therefore they should be stored and transmitted with care.
For example, these tokens can be sent in the following ways:

1) When the access token is sent in the authorization header in the http request, a predefined syntax is used which takes the form "Bearer 1*SP b64token" where b64token is base64.
As an aside a base64 string consists only one occurrence of any given Alpha or digit and / or one occurrence of -, ., _, ~, +, /, = special characters.
2) The bearer token could be sent in the request body with the "access_token" using "application/x-www-form-urlencoded"
3) The URI query parameter could also include the "access_token=" however it should be sent over TLS, along with specifying "Cache-Control" header with the private option.
Since URIs are logged, this method is vulnerable and is discouraged by the RFC. It documents current usage but goes so much as saying it "SHOULD NOT" be used and it goes against a reserved keyword.

If the request is authenticated, it could be responded with error messages such as invalid_request, invalid_token, and insufficient_scope as opposed to not divulging any error information to unauthenticated requests.
Threats can be mitigated if the
1) tokens are tamperproof
2) tokens are scoped
3) tokens are sent over TLS
4) TLS Certificate chains are validated
5) tokens expire in reasonable time
6) token exchange should not be vulnerable to eavesdropper
7) Client verifies the identity of the resource server ( this is known as securing the ends of the channel)
8) tokens are not stored in cookies or passed as page URLs