In part 1 we don't have authorization request and response signing and therefore as we note in the security considerations "request tampering and parameter injection are possible".
However we do require the AS to return the scopes granted from the token endpoint. We currently don't require the Client to do anything with those returned scopes.
I suggest we add a requirement for the Client to check the returned scope as this can give extra protection to this profile. For example if a "man in the browser" replaced the
scope value in the authorization request, the Client would still be able to detect this when retrieving the access token.
This isn't a problem for part 2