UserInfo should be TokenInfo

[tomreay]

During the implementation of #30 it was decided that the user info endpoint should become a token info endpoint.

Questions:

1. Is it intended that this be the endpoint described here
2. How will auth be handled for this endpoint? Should it require a bearer token with a token_info scope?

3. How many of the optional response fields should be supported? I think all.

[adhesivee]

I have introduced the userInfo endpoint, because with RFC6749 there is no standard way of doing this. But still wanted to provide an endpoint that some basic user information is visible. I have seen RFC7662, but haven't taken the time to really dive into it.

To answer your questions:

1. It is not intended to be like RFC7662 altough I do think it could be a good option to implement
2. If not using RFC7662, then it should use bearer token and scopes should be decided by the implementation (default no scopes). But I am not sure yet how to provide this in a clear way. Perhaps something as passing CallRouter to the userInfoCallback and create an extension method for CallRouter, like respondInvalidSopces or missingScopes which responds in the correct way of oauth2. This gives the implementor more flexibility if they want to deny on scopes or something else.
3. With optional response fields are you referring to this. If so, then yes all