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

[Nat Sakimura]

I created
https://bitbucket.org/openid/fapi/issues/619/authentication-property-of-fapi-20
to track this.

On Wed, 2 Aug 2023 at 21:32, Nat Sakimura <nat at nat.consulting> wrote:

> 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/20230808/1f16a362/attachment.html>