Different behavior between IRMA app and IRMA browser when cancelling auth request

[stefanvermaas]

When an user cancels the disclosure of attributes through the app (tested on iOS), the session gets cancelled on the IRMA server.

# Cancel disclosure request by clicking on "No, rather not" in the Irma iOS app
INFO Session started action=disclosing session=...
INFO Session request (purged of attribute values): ...
INFO Session status updated prevStatus=INITIALIZED session=... status=CONNECTED
INFO Session status updated prevStatus=CONNECTED session=... status=CANCELLED
INFO Deleting session session=...

When an user cancels the disclosure of attributes through the web, the session never gets cancelled on the IRMA server. However, IrmaWeb is perceiving it as cancelled, and throws an exception.

# Cancel disclosure request by clicking on "cancel" provided by IrmaWeb
INFO Session started action=disclosing session=...
INFO Session request (purged of attribute values) ...
INFO Session status updated prevStatus=INITIALIZED session=... status=CONNECTED

I would expect both cancel actions to result in the same behavior. In this case; cancelling the disclosure request should cancel the IRMA session for both the web and mobile apps.

We're using irma-core, irma-web and irma-client.

[ivard]

Before answering, I first want to make sure I understand the issue right. Do I understand you right that your problem is the following:

1. User presses 'cancel' in the web browser
2. User sees cancellation in the web browser, cancellation is also communicated to irma server
3. IRMA app keeps showing the session like it has not been cancelled at all
4. If the user continues in his/her IRMA-app the user runs at some point into some ugly error that the session cannot be finished because it has been cancelled on the server already.

[stefanvermaas]

Sorry, for the late response. It got lost in my notifications.

Your scenario is not what I meant, but you're right. That's also what is happening. The scenario I we saw;

1. User presses "cancel" in the web browser
2. We see an exception raised by IrmaWeb (?) and redirect the user to an error page
3. Upon arrival, we fetch the session from our IRMA server, but the session returns as valid, because IrmaWeb didn't cancel the session with the IRMA server, but only raised.

There are two consequences here;

• The IRMA app still shows the in progress session (which is true, because it's still valid and in progress)
• The error rendering fails because the session is still valid and not cancelled

Off course, we can redirect people from the error page back to the sign in page whenever the session is still valid, but the problem is the session is not cancelled in the first place, while it should have been (the user clicks "cancel").

When the user clicks "cancel" during the process in the IRMA (iOS) app, the session is cancelled at the IRMA server, and the web interface responds as expected; it raises an error, we redirect them to the error page and show the user cancelled the request and should start again.

[ivard]

I can't reproduce this on the latest version of the packages. If I cancel, it is nicely communicated to the server and I see no error. Can you verify that you are on the most recent version of the packages. The most actual version is 0.3.2. I however made some changes in the versioning system today, so here you can read what equivalent versions are of 0.3.2.

If you are on the most recent version, can you please enable the option debugging: true in the irma-core options and send me the specific output that you get in your browser console when this error occurs? Then I can try to reconstruct your scenario.

[stefanvermaas]

Your comment triggered me to look into the network tab too. It turns out; our Content Security Policy prohibited the JavaScript to send a DELETE request to the IRMA server. This triggered an error being thrown by the JavaScript, and thus the user got redirected while the session wasn't canceled.

I believe we can change the uri through the state option of irma-web, right? I must have missed it while implementing it.

[ivard]

Indeed, you can change the URL using the state option of irma-client. Although it always keeps doing a DELETE, since the public API of the IRMA server expects this to be a DELETE. You can also disable the cancel request by doing state: {cancel: false}. Then the cancellation will not be communicated anymore of course, but it solves the error.

[stefanvermaas]

DELETE perfectly fine! Thanks for your help!