Add requirement for clients to verify scope value returned from the token endpoint

[Dave Tonge]

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

[Nat Sakimura]

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

[Nat Sakimura]

Need to check if it impacts Part 2.

[Dave Tonge]

Added requirement to part 1. Then check with WG if it makes sense to keep it or downgrade it in part 2.

[Dave Tonge]

So, I had a think about this and I’m not sure how to word it.

Should we say that the client should just check the scopes are what it expects?

Or should we be explicit and explain the attack - i.e. that through tampering the scope was switched, therefore the client should verify it has only received the scope it asked for.

[Dave Tonge]

We discussed this and decided that the there are valid use cases for the AS to return extra scopes, e.g.

1. The AS breaks out a “meta scope” to fine-grained scopes, so: “accounts.all” becomes “accounts.read” and “accounts.write”, or
2. The AS grants access to accounts held at multiple Resource Servers that need different scope representations

There are also valid use-cases for the AS returning less scopes than requested (e.g. when the user chooses so)

Because of this we will go with some fairly vague wording requiring that the client check the scope is what it expects.

However we discussed having some more prescriptive tests in the conformance suite which would expect the client to detect when unexpected scope was returned from the token endpoint.

[Dave Tonge]

https://bitbucket.org/openid/fapi/pull-requests/172/add-requirement-for-client-to-verify-scope