CIBA new notification only mode

[Brian Campbell]

Add a CIBA notification mode that does not directly deliver the token(s) but rather informs the client that they can go and fetch the token(s).

This normalizes the means of the client obtaining tokens in all cases to it making a request to the token endpoint, which is a well established pattern. And keeping token delivery at the token endpoint simplifies things in situations where tokens are bound to client keys (like with MTLS and Token Binding for example). I can't say that it's really that much more secure. But I can say that it's not introducing a completely new mechanism of token delivery for which the security properties likely aren't as well understood and haven't been evaluated at by as many people.

Some list discussion on the topic: http://lists.openid.net/pipermail/openid-specs-mobile-profile/Week-of-Mon-20180702/001191.html

Was also discussed on the July 10th 2018 MODRNA WG call: http://lists.openid.net/pipermail/openid-specs-mobile-profile/Week-of-Mon-20180709/001202.html

[Dave Tonge]

I agree with Brian on this. As discussed at the meeting it seems that deployments with high latency was the reason that the CIBA notification mode delivers the tokens directly. However this constraint doesn't apply in many of the proposed deployments of CIBA.

The token binding / sender-constrained toknes issue is quite real, while its possible to implement token binding when the tokens are delivered to the notification endpoint it would require a fair amount of custom code for any implementer. Whereas always retrieving the token from the token endpoint is much simpler.

While there was discussion of this on the call, I can't remember any concrete actions. My suggestion would be:

1. The core CIBA spec is changed and simplified so that the notification mode doesn't contain the token
2. A MODRNA specific profile is created that describes the current notification mode

By removing token delivery in the core spec we could also remove client_notification_token and quite a lot of the wording around the notification endpoint. This will make the spec easier to read and to implement.

[Ralph Bragg]

The Open Banking security teams would prefer this change as well. The security concerns with posting the token have been raised by a number of the CMA9 and we have adopted a "notification only" pattern for resource changes as well rather than attempting to post the whole resource update direct to the TPP.

Something has changed, come and get it is the OB UK pattern.

[Dave Tonge]

We discussed this in the FAP F2F today and there was support for this change

[John Bradley]

On the Modrna call there was a desire to also keep the original notification flow with pushing the token in in the spec as an option

[Brian Campbell]

On the 8/21 Modrna call there was general(ish) consensus that the core CIBA should define three modes (polling at token endpoint, notification with pick up at token endpoint, direct token delivery on notification). And that the switch should not be a runtime parameter but a registration/configuration thing per client id. AS/OP metadata can indicate supported modes. And profiles could impose restrictions or requirements on supported modes as needed.

[Dave Tonge]

I've made a start on this for anyone who is interested: https://bitbucket.org/dgtonge/mobile/pull-requests/1/simole-notification-mode/diff or here https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?Submit=Submit&format=ascii&mode=html&type=ascii&url=https://bitbucket.org/dgtonge/mobile/raw/c0f9f2f0ae4504a20dac662db899476adf045133/draft-mobile-client-initiated-backchannel-authentication.xml

I'm nearly ready to make a pull request back to the main repo.

We discussed getting this complete before we split the draft into 2.

[Brian Campbell]

https://bitbucket.org/openid/mobile/pull-requests/15/introduce-a-third-mode-for-getting-the/diff has proposed changes for this

[Gonzalo Fernández]

Reading this thread it seems that there are tow potential reasons to implement this change in the spec ...

1. Security: As per Ralph comments it seems that there are some concerns posting the token and this flow to notify first and them get the token is preferred by Banks. I don’t know exactly what are these concerns but I see that using this mode Mutual TLS is possible and you can maybe give the maximum of security you can. Regarding token binding, I don’t know what do you reckon, but as per Google position it seems there is no many possibilities to be a reality.

2. Simplicity: I can agree with the rational that implementing this flow is simpler if considering to remove the callback delivery flow and only the polling mode and this new callback notification mode are the possible modes. If we consider to use both flows at the same time (Polling and Callback Notification), it seems to make sense, however we have not found any use case where the same app uses both flows. Additionally the callback delivery flow is a well-known flow that is used in authorization-code flow in the device initiated, so I don't believe it can create confussion to use this flow. In detriment of this flow however, this additional interaction increase the latency to get the token, that obviously can be avoided using Callback Delivery if latency was a MUST.

In short, I don’t see any problem to add this new flow to the CIBA core, however I have a doubt reading the Dave’s proposal https://bitbucket.org/dgtonge/mobile/pull-requests/1/simole-notification-mode/diff or here https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?Submit=Submit&format=ascii&mode=html&type=ascii&url=https://bitbucket.org/dgtonge/mobile/raw/c0f9f2f0ae4504a20dac662db899476adf045133/draft-mobile-client-initiated-backchannel-authentication.xml….

I think that it would be necessary to specify in section 11 “Token Error Response” that the “autorization_pending” and “slow_down” errors would only be applied to the Polling Mode when there is no client_notification_mode because it is supposed that the notification should only be sent when authentication is ended (accepted or rejected). Moreover, I think that this “auth_req_id” obtained with the notification should be removed or expired from the OP once it has been requested.

Another approach we could consider (I don’t know if you already did) would be to send a different notification when the authentication does not succeed in order to avoid unnecessaries requests.

[Brian Campbell]

Issue #80 raises the question of if a Client configured to receive the ping/callback notification can also poll the token endpoint. In such a case the "authorization_pending" and "slow_down" error codes would still be applicable. In the call today there was agreement about #80 that the 2 modes should be treated the same - essentially a client in "ping" mode can also "poll".

[Dave Tonge]

Resolved with this PR: https://bitbucket.org/openid/mobile/pull-requests/15/introduce-a-third-mode-for-getting-the/diff