Fix randomblind attribute names in credential request

[leonbotros]

A sloppy mistake by me: The names included in the credential request for verifying that the client and server have identical random blind attributes identifiers were off by one due to the fact that function that returns the indices was including the metadata attribute. Verification was still correct as both the client and the server had this bug, but it shows the wrong id in the logs.

Servers that have this patch cannot do randomblind issuance with apps that do not have this version of irmago yet and vice versa as verification will mismatch.

[ivard]

Are we talking about the logs of the IRMA server or about the logs in the IRMA app?

And how is it possible that it currently works then if the wrong indices are used for the random blind attributes? That's still a bit unclear to me.

[sietseringers]

Servers that have this patch cannot do randomblind issuance with apps that do not have this version of irmago yet and vice versa as verification will mismatch.

Then, is it necessary to roll this out with a backwards compatibility layer to prevent breakage of server users using this?

[leonbotros]

@ivard it's atleast in the logs of the irma server, since it logs the credential request. It's not logged in the app afaik. The indices were never wrong, it's the translation from index to attribute identifier.

@sietseringers that would probably be best.
I have to note that it's currently not used in pbdf credentials, but only in demo credentials, but it could break a pilot if either a user or a server decides to upgrade. If we decide to not do this in a backwards compatible way I could help our partners through fixing this problem once it drops in a production app. That way we have less legacy code.

If I'm not mistaken randomblind was introduced before chained sessions in 2.7, but after 2.6 (revocation).
We did not introduce a new protocol version for randomblind issuance.
Currently, the client will cancel the session if a mismatch occurs after comparing the names sent by the server to it's own configuration. A way to fix this is in a completely backwards compatible way is by introducing a new protocol version.
Both the server/client then use either the wrong names (incase the old version is used) or the right names in case the new version is used.
I could implement this, but should we do this in 2.8 (currently reserved for session-binding/shoulder-surf) or 2.9?

[sietseringers]

If it is at all possible to do this without such an upgrade path by guiding partners using this in demo, then I would prefer that. Those that use this in pilot/demo, do they have real app users trying their demo, or is it just a bunch of developers playing with demo's?

[leonbotros]

It's real (probably production) app users. I've asked how far along they are with their pilots and they've said they will be done within 2 weeks. After then it's safe for this to land in a production app (not that this happens this fast, but still).

For the next experiments, I'll help them with the right versions.

I'll notify here when this PR becomes relevant again.

[leonbotros]

I've given this some more thought and came to the conclusion that we cannot solve this nicely (without users who get stuck during issuance) without some legacy code, since we cannot force users to upgrade their app/irmago version.

On the other hand it is easier to help new issuers (there are currently none in the pbdf scheme) of randomblind attributes to upgrade to a version of the server works with all apps, by basically sending the attribute identifiers that the app expects (dependant on protocol negotiation, to check if the app has the fix or not).