Core - 2.3.3.8. Access Token - ATs should be different.

[Nat Sakimura]

Current text states:

If an Access Token is returned from both the Authorization Endpoint and 
from the Token Endpoint, which is the case with the response_type values 
code token and code id_token token, their values MAY be the same or in 
some cases, they might be different.

In my comments back in October 22, I have pointed out that they should be different and provided the following text. The WG also have agreed that they should be different as the security property is different. Therefore, I propose to adopt the text provided on Oct. 22, which is:

If an Access Token is returned from both the Authorization Endpoint and from 
the Token Endpoint, which is the case with the response_type values code token 
and code id_token token, it is RECOMMENDED that their values be different. 
The access token returned from Authorization Endpoint is more vulnerable to 
various attacks so that it has less trust than that returned from the Token Endpoint. 
Thus, the Server MAY give lesser scope and/or shorter lifetime for the 
Access Token that is returned from the Authorization Endpoint.

[Michael Jones]

I have two problems with the proposed text. First, and foremost, if we recommend that the two access tokens be different, we're making simple things complicated, which is the opposite of our design philosophy. I would expect that a normal implementation would return an access token that's appropriate for the front channel on the front channel and then return the same access token on the back channel. If it's safe enough for the front channel, it's also safe on the back channel. That's keeping simple things simple.

Returning different tokens is an advanced case, which I'll note that we have no syntax for governing. The scopes and "claims" logic just talk about the access token, not multiple access tokens, nor do we want to introduce new syntax to differentiate between them now. We shouldn't be recommending advanced behavior that is incompletely specified.

Secondly, the second sentence should actually be part of the security considerations - not the normative text about this case. It would be fine to include this as part of a general treatment about the security differences between tokens returned on the front channel and on the back channel. If you want to propose specific security considerations text along those lines, I'd welcome that. But this doesn't belong here.

Therefore, I believe that this proposal should be rejected, and possibly proposed by a new proposal for additional security considerations text.

[Michael Jones]

I should have said "... and possibly replaced by a new proposal for additional security considerations text".

[Michael Jones]

We will say that the differences may be due to the different security characteristics of the two endpoints. We will also say that the lifetimes and resource access granted may be different. We will say "MAY" about both cases and remove "in some cases".

[Michael Jones]

Fixed #907 - Clarified conditions under which Hybrid Flow Access Tokens might be different.

→ <<cset 9bef4a0a5e52>>