[Openid-specs-fapi] Issue #619: Authentication property of FAPI 2.0 (openid/fapi)

[Nat]

New issue 619: Authentication property of FAPI 2.0
https://bitbucket.org/openid/fapi/issues/619/authentication-property-of-fapi-20

Nat Sakimura:

this is a continuation of the email discussion in the thread: 

‌

It is wrt the authentication property of FAPI 2.0 \(and FAPI 1.0 flows that does not use OpenID Connect\) described on the FAPI 2.0 attacker model. 

I quote: 

> [2.2. ](https://openid.bitbucket.io/fapi/fapi-2_0-attacker-model.html#section-2.2)[Authentication](https://openid.bitbucket.io/fapi/fapi-2_0-attacker-model.html#name-authentication)
>
> The FAPI 2.0 Security Profile aims to ensure that **no attacker is able to log in at a client under the identity of another user.**
>
> The ID token is the credential for authentication in OpenID Connect. This security goal therefore is fulfilled if no attacker can obtain and use an ID token identifying another user for login.

The case in question is as follows.   
User A has accounts A1 and A2 at the authorisation server/resource server. User A has an account C\_A1 at the client that stores historical transaction information from A1. When User A was prompted by the client to refresh the access to A1 when they logged in to the client, they got redirected to the authorisation server and, by mistake, used A2 to authorise. The new access token is bound to A2 instead of A1. By using it, C\_A1 gets the transaction information from A2 and connects them to the previously obtained data from A1. This is not correct behaviour. How is this mitigated in FAPI 2.0 and FAPI 1.0 with JARM?   
A similar situation occurs when users A and B share a browser, and the authorisation server is maintaining a long-run session. 

It probably needs to be addressed either with a stable identifier in the functional API or at the authentication protocol level. 

So, the security goal may be: 

1. When session correlations are sought, then responses from a different account shall be detected. 

1. When session correlations \(linking\) are to be avoided, then the receiver should not be able to identify whether the session belongs to the same user with a significantly greater probability than 1/2. 

‌