1. OpenID Foundation Avatar OpenID Foundation
  2. WGs
  3. fapi
  4. Issues

CIBA - which modes to support

Issue #199 resolved
Dave Tonge created an issue

The new CIBA Core draft specifies 3 different modes:

  • poll - the RP polls the token endpoint
  • ping - the OP notifies the RP at it's notification endpoint when to get the tokens
  • push - the OP delivers the tokens directly to the RP's notification endpoint

My proposal for the FAPI profile is that OPs:

1. shall not support CIBA push mode;
2. shall support CIBA poll mode;
3. may support CIBA ping mode;

The rationale for this is:

  • Push mode has quite different security characteristics. Because it is quite different from all other OAuth profiles there is a greater chance of error. It is also potentially harder to implement sender-constrained tokens in push mode.
  • Poll mode is the closest to standard OAuth profiles and I think in the interests of interoperability it should be required for the FAPI CIBA profile
  • Ping mode brings the benefits of Push mode, but with the security of Poll mode. However I don't think we can mandate its implementation, hence I suggest we say may.

Comments (20)

  3. Ralph Bragg

    Luke Popplewell - note that this recommendation above would be in direct contradiction of the proposal currently for the CDR. Is there a reason why polling is banned?

    4.2. Client-Initiated Backchannel Authentication (CIBA)

    Client Initiated Backchannel Authentication (CIBA) enables a Data Recipient (Client) to initiate the authentication of an end-user at a Data Holder (OpenID Provider) by means of detached or out-band mechanisms [FAPI-CIBA].

    Authorisation server rules for [FAPI-CIBA] are covered under section 5.2.2 of the FAPI CIBA profile.

    Login hints MUST not reveal Personal Information (PI) about the consumer or end-user.

    Client rules for [FAPI-CIBA] are outlined under section 5.2.3 of the FAPI CIBA profile.

    The polling mode for clients SHALL NOT be supported.

  4. Luke Popplewell

    There was an issue with polling mode and Pairwise Identifiers from memory - sector uri usage couldn't be proven as there was no redirect uri or notification end point uri with polling. It is probably not an issue with the request object being used - I think I was directly referencing MODRNA CIBA a few weeks ago and not FAPI CIBA. I would prefer not to use notification as that's one less endpoint to worry about.

  5. Joseph Heenan

    I'm debating with myself over this part:

    Ping mode brings the benefits of Push mode, but with the security of Poll mode. However I don't think we can mandate its implementation, hence I suggest we say may.

    I think ping mode should have a big benefit in terms of UX (ie. how fast the authorisation process is performed). As one of the goals of CIBA is to try and ensure the low friction authentication flows (I can't recall the exact phrase currently, hopefully that's close enough) that RTS requires I wonder if we should address that point somehow.

    One possible way to address it would be to add a clause something along the lines of:

    "shall not reject or return 'slow_down' to clients that are polling at an interval of 100ms or longer (except in exceptional circumstances where unexpected and unprecedented server load is present), this requirement shall not apply if CIBA ping mode is supported"

    i.e. I think it's important that the user can essentially instantly proceed as soon as they have completed their part of the CIBA process, and I don't believe the server being allowed to insist on 5 second or longer polling intervals is conducive to that.

  6. Dave Tonge reporter

    @lukepopp so the use of pairwise identifiers with poll mode requires the RP to have a jwks_uri (and to demonstrate ownership of a key listed there). It looks like you have jwks_uri has a mandatory field, so I believe you could support poll mode. However as you allow PKI mutual tls client auth (which doesn't use the jwks_uri), you would probably need to require that the CIBA request is sent as a signed authentication request. I'll open an issue for this, as we may want to require that for the FAPI profile anyway

  7. Dave Tonge reporter

    @josephheenan we should discuss this. I like your suggestion, but 100ms is probably too short.

  8. Luke Popplewell

    @dgtonge we have an issue open to remove mtls client auth but one major bank wants to keep it. In older versions of our profile I had a section about signed auth requests for CIBA being mandatory and was hoping FAPI CIBA would be consistent with FAPI RW in this regard.

    As an aside, are you planning to follow MODRNA rules on amr/acr? This is probably not the right place for this question so feel free to point me in the right direction to pose this q.

  9. Dave Tonge reporter

    @lukepopp thx for pointing me to the issue.

    I've opened this issue: https://bitbucket.org/openid/fapi/issues/200/ciba-signed-authentication-request re whether we should require a signed auth request. Because its a backchannel call there isn't the same need as with redirect flows.

    Re: acr I've opened this issue: https://bitbucket.org/openid/fapi/issues/201/ciba-acr-amr-alignment. Please put your concerns / ideas / suggestions / questions there, thanks.

  10. Joseph Heenan

    but 100ms is probably too short.

    It was my opening lowball offer :-) I'd tend to agree. "essentially instant to the user" is the goal and I'm not sure exactly what the exact value needs to be. I'm pretty sure it is hard to define anything over 2 seconds as "essentially instant".

  11. Dave Tonge reporter

    So my concern about this requirement is that its not really a security requirement, but more of a ux requirement. As such I'm not sure we can justify adding it to the FAPI profile?

  12. Joseph Heenan

    I agree it's not a security requirement so you might be right.

    I'm not sure it's entirely a UX point, and I think part of what we end up trying to do as a working group is about ensuring protocols are deployed in a way that they work well for the RP & OP. In Europe PSD2 perhaps encourages good UX, but I think if we can providing suggestions around how to provide a good UX with FAPI-CIBA would make sense and are likely to have quite a lot of weight, particularly as it's a completely new model.

    Would you be happy having some guide of 'implementation guidance' or similar section in FAPI-CIBA?

  13. Dave Tonge reporter

    I do think implementation guidance would be useful. Do you think that should be a section in the CIBA profile or a new doc? I think we could add some implementation guidance for Parts 1 and 2 as well.

  14. Ralph Bragg

    Open Banking publishes the Customer Experience Guidelines, this really should be accomanied by a technical implementation guidelines/guidance as well. For my vote this this is a seperate document as it will change relatively rapidly during the initial iterations of it.

  15. Joseph Heenan

    The argument for having it in the same document as the profile would be that it is more visible and is more likely to be read.

    However I think for the reason's Ralph mentions it should probably be a separate document, but I think to aid visibility the CIBA profile should both mention & link to the new document.

  16. Brian Campbell

    it should probably be a separate document, but I think to aid visibility the CIBA profile should both mention & link to the new document.

    agree

  20. Dave Tonge reporter

    Closing as there were no objections to the proposal. Other issues have been raised concerning the discussion in this issue.

  21. Log in to comment
Assignee
Type
bug
Priority
major
Status
resolved
Component
CIBA
Milestone
–
Votes
1
Watchers
1
Jira: the preferred issue tracker for Bitbucket. Join the team!