Modes supported

[Bjorn Hjelm]

The original CIBA specification defined two modes, polling and notification. The CIBA Core defined three modes, poll, ping and push. Should the MODRNA CIBA Profile support the poll and push (renamed notification mode in CIBA Core) in the original CIBA specification or all three modes defined in the CIBA Core?

[Pablo Guijarro]

I think that answering some other questions first might help. What are the key benefits of the new ping mode in general (and for MNOs in particular)? I am not really sure about them… Then, is there a well identified use case that would benefit from them? Is there any MNO supporting that mode or willing to offer it?

[Dave Tonge]

So I think that the Modrna profile should support all 3.

The MNO’s requested that we keep PUSH mode, because in some deployment situations latency is too high to support the separate round trip to the token endpoint.

In FAPI we just went with POLL (because the security semantics are the same as standard OAuth 2 flows) and PING because it keeps pretty much the same security semantics when it comes to tokens, but means that the client doesn’t need to keep polling the AS.

In FAPI we dropped push, because we felt that it introduced a different security model quite different to the rest of the OAuth 2 ecosystem.

‌

‌

[Joseph Heenan]

The other reason for that FAPI not having push is that,as the token endpoint isn’t used, it’s not compatible with certificate bound access tokens ( https://tools.ietf.org/html/rfc8705 ) - see https://bitbucket.org/openid/mobile/issues/173/push-token-delivery-sender-constrained

It’s probably also incompatible with other proof of possession methods, like DPoP, that also expect tokens to only be issued from the token endpoint.

‌

‌

[Dave Tonge]

We discussed this on the call, and agreed the following:

• Add back in ping mode
• Add a description on how to do sender constrained tokens with push
• Change security consideration re push mode, to be less strong, but to include some wording on sender constraining tokens

‌

[Pablo Guijarro]

As for the second bullet, do we really need to do it? That is not exactly what I understood (though I might have missed it).

I mean, according to your explanation, the raison d'être of the ping mode is to provide the asynchronous experience of the push mode with the enhanced security options of the poll mode (as they both perform standard OAuth 2 token calls). And the price you pay is slightly increased complexity and worst performance due to the extra call and round trip. Different options for different use cases or SPs' needs.

If we manage to define or describe a way for the push mode to be equivalent in terms of security to the poll and ping modes, what would be the point of choosing ping over push (apart from having a more similar scheme to the standard OAuth 2 flows)?

Just in case you can spare the effort.

[Joseph Heenan]

I mean, according to your explanation, the raison d'être of the ping mode is to provide the asynchronous experience of the push mode with the enhanced security options of the poll mode (as they both perform standard OAuth 2 token calls). And the price you pay is slightly increased complexity and worst performance due to the extra call and round trip. Different options for different use cases or SPs' needs.

I think the worry was people would pick push mode for performance reasons, deploy an ecosystem, then feel unable to move to ping/poll when they realised they needed better security. It seemed to me potentially unnecessary to force people to make the security vs performance tradeoff.

If we manage to define or describe a way for the push mode to be equivalent in terms of security to the poll and ping modes, what would be the point of choosing ping over push (apart from having a more similar scheme to the standard OAuth 2 flows)?

I think you’re right, that may be the main benefit to ping.

There may also be a benefit to ping if using long lived CIBA requests (e.g. ones that might take hours to be authorised, meaning the keys used for sender constraining may have changed since the initial call to the backchannel authentication endpoint was made). I’ve not fully thought through if that’s a big concern though.

[Pablo Guijarro]

Alright, thanks, understood.

The behaviour wrt sender constrained tokens in the case of long lived CIBA requests would certainly be a difference between the two modes, yep. Not sure if that would be a common case though, not even a good practice, at least here in MODRNA.

[Dave Tonge]

https://bitbucket.org/openid/mobile/pull-requests/3

[Dave Tonge]

We discussed moving some of the proposed text to the core profile

[Bjorn Hjelm]

Reverting the issue back to the MODRNA CIBA Profile and created a new companion issue (#198) for the CIBA Core specification.

[Dave Tonge]

I suggest that the PR https://bitbucket.org/openid/mobile/pull-requests/3 is closed. As this can now be covered by the core spec: https://bitbucket.org/openid/mobile/pull-requests/12/add-clause-about-sender-constraining-push

[Dave Tonge]

PR merged