The post involves discussion on  APIs to remove all user/me resource qualifiers from the API config routes. If the OAuth implentation doesn't restrict a client from using the notion of a superuser who can access other user profiles based on /user/id that would mean the protocol is flexible.
Meanwhile, this post also talks about adding custom validation via ActionFilterAttributes
For performance, should we be skipping token validation on all input parameters.
This is important because it lowers security in favor of performance and the tradeoff may have implications not just to the customer.
That said even for the critical code path, security has to be applied to the both the endpoints administration as well as token granting endpoints.
The token granting mechanisms also need to make sure the following are correct.
1) the tokens are not rotated or reused again.
2) the tokens hash is generated using the current timestamp.
3) the tokens hash should not be based on userId and clientId.
Should the tokens be encrypted, then they could use userId, clientId so that they can be decrypted.
The third post will talk about client registrations separately since they are currently tied to the proxy and is not in immediate scope.