yivi app sends attribute that was not selected about irmamobile HOT 9 CLOSED

Oh that sounds ugly. That would be a subtle one. We'll dive into this.

from irmamobile.

Let me know if you need more information. I kept my Yivi app in this state to help you reproduce the issue. You know how to contact me directly :)

from irmamobile.

It would be practical for us to know:

1. Which session were you trying (only disclosing pbdf.sidn-pbdf.email.email, or something more complicated)?
2. Did you already have an unexpired attribute, or did you obtain it using the 'Reobtain' button?
3. After you selected the unexpired attribute, did the final overview screen actually show this unexpired attrbute? Or did it still show the expired attribute?

from irmamobile.

Sure!

1. only disclosing email: { "@context": "https://irma.app/ld/request/disclosure/v2", "disclose": [[["pbdf.sidn-pbdf.email.email"]]] }
2. Did not click re-obtain because it is an unused email address nowadays, so don't want to renew it. And there is no GUI interface to delete an expired attribute if you don't want it anymore.
3. The final overview screen showed a different email address (the unexpired one). But the site I revealed to did not accept my attribute. I did not understand until I looked at the logs that clearly showed: it was another attribute (the different mail address), and this one was expired (so rejected).

I can not reproduce the issue, so it might be a race condition in loading the data inside the app, or something like that. Or it might be different in the new version as my app auto updated last night (as shown by the overview in Google Play Store).

from irmamobile.

Hey @bvgastel, thank you for reporting this issue. I am currently investigating it with Ivar. So far, I'm not really sure how it could have happened, and I'm not able to reproduce it. If I'm understanding correctly, this only happened once? Or was it reproducible before the update? Nevertheless, we will keep an eye on it.

Regarding the other issue, the problem with deleting revoked/expired credentials has been fixed in #169, and it should be included in the new release.

from irmamobile.

No problem! I was very frustrated for about 2 days (not full time ;) because a new IRMA/Yivi connector I was making did not work. Only after properly checking the actually disclosed attribute, I realized the GUI did show something else. So I replicated it 20-30 times or so over 2 days.

I never 'reboot' the app, so it might be that the Yivi app had a data race internally. What I remember is: I had 3 expired mail attributes, I renewed 2 of them. But not the first one (see original post). So it might be something with the renewal code, as that code path was activated for different attributes.

Hope this info helps. And thanks for fixing the other issue in #169.

from irmamobile.

I'm still unsure about how this issue could have happened. I attempted the following steps (on 7.3.0):

1. Issued three credentials of the same type.
2. Revoked all three (assuming it would work the same as expired credentials, which are difficult to test/mock).
3. Renewed the last two credentials, resulting in five total credentials with three revoked.
4. Started a disclosure session.
5. The first non-revoked credential is selected.
6. Finished the disclosure session.
7. Logged the disclosureChoices in the RespondPermissionEvent that was dispatched on the IrmaRepo.
8. The log matched the first non-revoked credential.

Based on my observations, I have a few guesses about the issue:

• It may be a rare race/timing issue.
• It may only occur with expired credentials, not revoked ones.
• The problem could be at a deeper level, possibly in the IrmaRepo or irmago

from irmamobile.

Yeah, these are the frustrating and hard to reproduce bug reports. As I can also not reproduce anymore (might be because my app updated/restarted), I would:

• maybe add some extra check in the app that the credential that is being transmitted is the one that that is selected (depending on the code structure, reporting, etc this can be useful if there is time between);
• after that: close this issue, and wait.

from irmamobile.

I tried building such a check, but I'm not sure this is even possible with the way things are set up right now. I could build a check to ensure that the credential is not expired/revoked, but that would not cover all cases, so I'm hesitant to do that. I'm kind of hitting a wall with this issue, so I guess we have to close it for now. We will keep this on our radar, however.

If you happen to encounter this problem again while working on your connector, please try to collect as much data as possible (such as screenshots or logs). Feel free to contact me directly or reopen this issue. I'm sorry for the inconvenience

from irmamobile.