<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">Hi Nat<div><br></div><div>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 <a href="https://openid.net/specs/openid-financial-api-part-2-1_0.html#id-token-as-detached-signature">https://openid.net/specs/openid-financial-api-part-2-1_0.html#id-token-as-detached-signature</a></div><div><br><div>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.</div><div><br></div><div>Thanks</div><div><br></div><div>Joseph</div><div><br></div><div><br></div><div><br><blockquote type="cite"><div>On 23 Jul 2023, at 23:32, Nat Sakimura via Openid-specs-fapi <openid-specs-fapi@lists.openid.net> wrote:</div><br class="Apple-interchange-newline"><div><div dir="ltr">Hi<div><br></div><div>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. </div><div><br></div><div>I quote: </div><div><a href="https://openid.bitbucket.io/fapi/fapi-2_0-attacker-model.html#section-2.2" class="gmail-section-number gmail-selfRef" style="font-size:18px;font-family:"Noto Sans",Arial,Helvetica,sans-serif;text-decoration-line:none;padding-right:0.5em;color:rgb(34,34,34)">2.2. </a><a href="https://openid.bitbucket.io/fapi/fapi-2_0-attacker-model.html#name-authentication" class="gmail-section-name gmail-selfRef" style="font-size:18px;font-family:"Noto Sans",Arial,Helvetica,sans-serif;text-decoration-line:none;color:rgb(34,34,34)">Authentication</a><br></div><div><div id="gmail-authentication" style="margin:0px;font-family:"Noto Sans",Arial,Helvetica,sans-serif;font-size:14px"><p id="gmail-section-2.2-1" style="padding:0px;margin:0px 0px 1em">The FAPI 2.0 Security Profile aims to ensure that <strong>no attacker is able to log in at a client under the identity of another user.</strong><a href="https://openid.bitbucket.io/fapi/fapi-2_0-attacker-model.html#section-2.2-1" class="gmail-pilcrow" style="text-decoration-line:none;color:rgb(102,102,102)"></a></p><p id="gmail-section-2.2-2" style="padding:0px;margin:0px 0px 1em">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.<a href="https://openid.bitbucket.io/fapi/fapi-2_0-attacker-model.html#section-2.2-2" class="gmail-pilcrow" style="text-decoration-line:none;color:rgb(102,102,102)"></a></p></div><div id="gmail-session-integrity" style="margin:0px;font-family:"Noto Sans",Arial,Helvetica,sans-serif;font-size:14px">The case in question is as follows. <br>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? <br>A similar situation occurs when users A and B share a browser, and the authorisation server is maintaining a long-run session. <br>Best regards, <br>Nat Sakimura</div></div></div>
_______________________________________________<br>Openid-specs-fapi mailing list<br>Openid-specs-fapi@lists.openid.net<br>https://lists.openid.net/mailman/listinfo/openid-specs-fapi<br></div></blockquote></div><br></div></body></html>