<div dir="ltr">I created <a href="https://bitbucket.org/openid/fapi/issues/619/authentication-property-of-fapi-20">https://bitbucket.org/openid/fapi/issues/619/authentication-property-of-fapi-20</a> to track this. </div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 2 Aug 2023 at 21:32, Nat Sakimura <nat@nat.consulting> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Right. It probably needs to be addressed either with a stable identifier in the functional API or at the authentication protocol level. <div><br></div><div>BTW, the ephemeral sub is intended not to allow this kind of session correlation. So, the security goal may be: </div><div><br></div><div>1) When session correlations are sought, then responses from a different account shall be detected. </div><div>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. </div><div><br></div><div>Thoughts? </div><div><br></div><div>Nat Sakimura</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 24 Jul 2023 at 17:24, Joseph Heenan <<a href="mailto:joseph@authlete.com" target="_blank">joseph@authlete.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>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" target="_blank">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 <<a href="mailto:openid-specs-fapi@lists.openid.net" target="_blank">openid-specs-fapi@lists.openid.net</a>> wrote:</div><br><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" 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)" target="_blank">2.2. </a><a href="https://openid.bitbucket.io/fapi/fapi-2_0-attacker-model.html#name-authentication" style="font-size:18px;font-family:"Noto Sans",Arial,Helvetica,sans-serif;text-decoration-line:none;color:rgb(34,34,34)" target="_blank">Authentication</a><br></div><div><div id="m_-2539565853336534367m_7894509325665419535gmail-authentication" style="margin:0px;font-family:"Noto Sans",Arial,Helvetica,sans-serif;font-size:14px"><p id="m_-2539565853336534367m_7894509325665419535gmail-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" style="text-decoration-line:none;color:rgb(102,102,102)" target="_blank"></a></p><p id="m_-2539565853336534367m_7894509325665419535gmail-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" style="text-decoration-line:none;color:rgb(102,102,102)" target="_blank"></a></p></div><div id="m_-2539565853336534367m_7894509325665419535gmail-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><a href="mailto:Openid-specs-fapi@lists.openid.net" target="_blank">Openid-specs-fapi@lists.openid.net</a><br><a href="https://lists.openid.net/mailman/listinfo/openid-specs-fapi" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-fapi</a><br></div></blockquote></div><br></div></div></blockquote></div>
</blockquote></div>