Wiki

Clone wiki

fapi / FAPI_Meeting_Notes_2023-11-02_Pacific

FAPI WG Agenda & Meeting Notes (2023-11-02)

Date & Time: 2023-11-02 00:00 UTC Location: https://zoom.us/j/97456084642?pwd=bTRFVzk4ZmlRK1M3bEprRlN5c3JFZz09

The meeting was called to order at 00:00 UTC.

1.   Roll Call (Anoop)

  • Attendees: Nat, Dima, Anoop, Mark, Bjorn
  • Regrets:

4.   Stuttgart – Security analysis findings

(Link to the FAPI2 WP2 analysis (DCR/ CIBA /FAPI2 Message Signing): http://dx.doi.org/10.18419/opus-13698) Pages 10 & 11 paper

  1. Signing requirements for CIBA authentication requests
  2. Unsolicited login hints and repudiation considerations to minimise the chance of cross-device phishing attacks
  3. Malicious client attacks / MITM - should a human readable identifier/message be paired with a nonce/verifier like PKCE?
  4. Linking of resource request and resource response

Mark comments/consideration:

  • Reducing the chances for that cross device fishing. Particularly given social engineering attacks are on the rise, and I think, from a to give it flavor or context.
  • From an Australian perspective, we permit one time passcode issued via SMS and email at the moment that is highly susceptible to phishing attacks where a malicious user can gain the trust of the honest user and say, and go guide them through a flow then injecting the otp into their malicious flow, so that they can then gain access to the the resources themselves. I guess this is not.
  • It's exactly the same in that Whilst we can have stronger authentication controls, it still allows a malicious user to gain the trust of the honest user and then initiated on their side. Because of that decoupling of consumption and authentication.
  • It's up to a particular ecosystems, rules, and requirements to implement or control and noting, for example, in the Uk they permit login hints to be passed by the third party, Tpps or whether or not that should be a security property in FAPI CIBA where it constrains the CIBA spec and prohibits a logging him being shared other than something like an id token which has previously been issued by the authorization server.
  • So the the Stuttgart report was saying that the CIBA, the only the constraint or the assumptions that they had to put for this FAPI version of CIBA was the binding between the consumption device and authentication device, that is the or the the issue of the cure code need to be authenticated in some way or another by the authentication device.
  • Ticket is there and Mark/Bjorn will add comments. https://bitbucket.org/openid/fapi/issues/609/ciba-make-clear-limitation-of-binding

5.   Next Call

Next call will be an Pacific Call. Next Pacific call will be in two weeks (11-16-2023 @ 5pm PST) UTC - 11-17-2023 1:00 AM.

Updated