[Openid-specs-fapi] Issue #686: CIBA response parameters in PSD2 TPP use-cases (openid/fapi)

[Jacob Ideskog]

New issue 686: CIBA response parameters in PSD2 TPP use-cases
https://bitbucket.org/openid/fapi/issues/686/ciba-response-parameters-in-psd2-tpp-use

Jacob Ideskog:

There are big changes rolling out in the Swedish BankID system. These are meant to prevent certain phishing attacks that are more and more common. This affects existing TPP implementations out there that use CIBA with BankID to follow the decoupled flow in PSD2.

How it used to work.

TPP \(mobile apps\) use CIBA to obtain tokens. 

1. During the authorization/authentication request the TPP sends the user identifier to the OP
2. The OP starts an authentication session with BankID and obtains some session identifier it keeps
3. The TPP receives the auth\_req\_id from the OP and keeps it while opening the BankID app on the same device
4. The BankID app checks with BankID for ongoing sessions and finds one
5. The user authenticates and is redirected back to the calling app \(usually\)
6. The TPP app polls the token endpoint and once the bankid session is complete it receives the token

This is obviously very phishable as an authentication session can be created by anyone to trick the user

The update that is being rolled out prevents this \(a bit\) by not allowing authentication sessions to be opened without some sort of token communicated to the BankID App. There are two ways to send this token:

1. If on same device: Pass a start-token when opening the BankID app
2. If on different device, open the BankID app and read a QR code that contains the token

For the flow described for the TPPs in the beginning, which was a same device flow, we now have the following updates:

1. During the authorization/authentication request the TPP sends the user identifier to the OP
2. The OP starts an authentication session with BankID and obtains some session identifier it keeps **and a start-token**
3. The TPP receives the auth\_req\_id from the OP **but also needs the start-token to be able to start the BankID app**,
4. The BankID app checks with BankID for ongoing sessions **and presents the start-token**
5. The user authenticates and is redirected back to the calling app \(usually\)
6. The TPP app polls the token endpoint and once the bankid session is complete it receives the token

I think this pattern and similar patterns will surface in more regions as phishing is a growing problem. Other eID systems will likely stricten up their implementations if they can.

Current TPP implementations will not accept radical changes to their integrations \(like moving to a redirect flow\), so different solutions are emerging, all of them bending or breaking the standard to various degrees.

Note: In this BankID case the start-token is passed once, but it could of course be possible that it is short lived and new ones needs to be passed to the TPP.

The options I’ve seen so far are:

* Using a different endpoint that the client knows about to get these tokens
* Cramming the tokens in the error\_description
* Adding additional parameters to the token or authorization response

It would be helpful if the FAPI group could recommend an acceptable pattern when using CIBA and needing to communicate further information to the client about the authentication process.

Adding additional parameters in the response from the authorization call seems acceptable, since it states that the client should ignore parameters in the response that it doesn’t understand. However in the case of rotating tokens that does not suffice. 

Adding additional parameters in the token endpoint response should be allowed according to RFC 6749 as far as I can understand, and if so, should it be together with `authorization_pending` or with some other error response?

Happy to hear some inputs on this.

/Jacob