[Openid-specs-fapi] Authentication property of FAPI 2.0

[Nat Sakimura]

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

BTW, the ephemeral sub is intended not to allow this kind of session
correlation. So, the security goal may be:

1) When session correlations are sought, then responses from a different
account shall be detected.
2) 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.

Thoughts?

Nat Sakimura

On Mon, 24 Jul 2023 at 17:24, Joseph Heenan <joseph at authlete.com> wrote:

> Hi Nat
>
> It’s an interesting question and I’m not sure I have an answer, but the
> same question likely also arises for FAPI 1.0 with OpenID Connect when an
> ephemeral sub is used as per
> https://openid.net/specs/openid-financial-api-part-2-1_0.html#id-token-as-detached-signature
>
> At least in UK OpenBanking, I think an actual issue doesn’t arise as each
> of the user’s bank accounts has a unique stable id, so the fintech is able
> to see that the new access token is giving access to different underlying
> bank accounts than previously.
>
> Thanks
>
> Joseph
>
>
>
> On 23 Jul 2023, at 23:32, Nat Sakimura via Openid-specs-fapi <
> openid-specs-fapi at lists.openid.net> wrote:
>
> Hi
>
> I have a question about 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.*
> <https://openid.bitbucket.io/fapi/fapi-2_0-attacker-model.html#section-2.2-1>
>
> 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.
> <https://openid.bitbucket.io/fapi/fapi-2_0-attacker-model.html#section-2.2-2>
> 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.
> Best regards,
> Nat Sakimura
> _______________________________________________
> Openid-specs-fapi mailing list
> Openid-specs-fapi at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-fapi
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20230802/85a05210/attachment.html>