It would be incredibly useful to have, for example, some health records issued via IRMA that you can essentially prove to your employer that you are safe and healthy to work without actually telling them what your white blood cell count is, which is weird.

For example, when I started working here, I was actually required to take a physical examination at a doctor and share that health information with my employer. Which actually, for me, was quite shocking. This is very strange for me.

Most of the thought I’ve been putting into this has been around vaccine passports. I have had some experiences in my time in Taiwan over the last year or two that I think this could be useful.

Thanks so much for listening and asking good questions.

Then of course, for specific use cases, people would need to be building websites or apps for issuance or verification. That’s all I presented. I have a few bonus slides if there’s any technical stuff about the protocol itself or the cryptography. Aside from that, that’s the main part of ...

On the software side, either a smartphone app that is forked from IRMA or a pull request incorporating IRMA to an existing app. All of the server and front-end and back-end functionality already exists by the Privacy by Design people. They have libraries already written in Go as part of ...

You would then, as you mentioned actually, likely want additional IRMA servers just for verifications. This can just be general purpose IRMA servers or even locally run ones in certain venues. There would need to be a key-share server that users register with when they first install the app that ...

This is a quick summary of what would be the requirements on infrastructure and software if Taiwan was interested in using IRMA for this. For issuing, you would need both the IRMA server that has issuing permissions for vaccine records and you would need a website that can authenticate people ...

Shall I continue?

I believe that it would work. Yes.

Your question, I believe, is if I basically just cloned the hard drive of my phone, can it just boot up IRMA and the protocol?

The secret key is basically a Shamir secret share so neither the key-share server nor the device ever sees the full key.

If I were to transfer my credential to another phone and that person somehow was able to reconstruct the full secret key from the key-share server, the verification would still fail because the secret keys of each credential aren’t the same.

Every time a verification session happens, for example if I have to prove that I am over 18 and I’m vaccinated, I’m actually showing attributes of different credentials, but they share that secret key as its first attribute. I’m also proving that this secret key is the same in both ...

This secret key is split between the user’s device and a key share server. This is an always-online key-share server. Basically this secret key is fixed to the device. It’s common across all of a person’s credentials.

It shouldn’t be possible for me to take a credential on my phone and put it on the phone of somebody else. The way that IRMA solves this problem is that every credential actually contains a secret key of the user as its first attribute.

Every session looks different even if it’s the same information which is what prevents tracking. One piece of information that we haven’t mentioned yet, which actually I think relates to your question about online availability is the issue of non-transferability.

You’re protecting the privacy of these unrevealed attributes. Also as we mentioned, the signatures on the credentials are blinded and the unrevealed attributes have zero-knowledge proofs of knowledge which are randomized.

The verifier knows that the credential is valid if the verification succeeds. As we mentioned a bunch of times, the verifiers only learn the attributes that are revealed.

I just wanted to then go over the security properties that this guarantees. These credentials are cryptographically signed. In fact, they are cryptographic signatures.

I don’t know if you have time for me to show that or if you’re interested. I’ll leave it to you if I show you or if we skip.

If that succeeds, or even if it doesn’t succeed, the result of that is then shared with the venue, the verifier. I had a second demo to show you what happens if the attributes are insufficient. If you’re not boosted, for example.

When that permission is granted, at that point the IRMA session is actually conducted where all of the cryptography takes place and the attributes are shared with the IRMA server.

The IRMA server responds giving it that session. Then the app is then asking permission to reveal the necessary attributes.

The QR code is basically just a session token plus a unique URI to that session. What I’ve done actually is everything that the user sees is in blue, and everything that’s hidden from the user is in green. At this point, the user scans the QR code which causes ...

At the very beginning, the venue tablet or my demo website is communicating with the IRMA server requesting a new session which is then given to the front end of the tablet along with the QR code.

The demo that I gave a moment ago, I just wanted to give a quick explanation of what was happening behind the scenes.

We’re getting into a lot of information that actually I have later and I’m a bit worried I’ll forget to say something important.

Maybe one other detail that might be worth sharing. It might be good for me to continue the slides.

That actually is possible. The only problem that might happen is – Credentials can be updated, the attributes of a credential can be updated if necessary – if the local federated IRMA server at the bar is air gapped in a sense, and it’s not getting these updates, you might ...

As soon as you do the same proof or reveal the same proof, then you can immediately say, “Jonathan was at this place and at this place.” Those would be the two balance…

These proofs are constantly randomized. That randomization is what makes it possible to not be tracked between different verification sessions.

As Tanja said, the cryptographic reason is that the way that this is all working is using zero-knowledge proofs to prove that credentials are authentic even though you’re not reviewing the information about those credentials.

There is both a technical reason and a security reason why both need to be online. The technical reason is that the prover and the verifier are not communicating directly. They’re both communicating through an IRMA server. They both need to have connectivity to the server. That’s the technical reason.

If I can elaborate just quickly.

That’s a good analogy, indeed.

You can get your ID credential from the city of Nijmegen and then use that if there’s some IRMA server or service operating outside of Nijmegen that wants to check your ID.

I believe that because of where they’re located, they focused most of their lobbying on the city of Nijmegen. Nijmegen, every municipality in the Netherlands can issue an ID credential that is nationally verifiable.

One of the things that needs to happen for IRMA to function is that issuing bodies like the Taiwan CDC or some municipality need to agree to have their credentials issued from an IRMA server into the app.

Sure. Yes. That is a bit confusing. The University that the Privacy by Design people are working at is in Nijmegen. They have done quite a lot of lobbying with the Nijmegen municipal government to issue credentials for IRMA.

I don’t know exactly what you’re referring to. Let me look.

Exactly. Well said.

I don’t think this was maybe indeed their top use case. I’m not entirely certain if they tried to do a pull request into the existing CoronaMelder app though. As Tanja said, for various reasons, the priority for that hasn’t been privacy to the extent that we all feel privacy ...

That, I do not know. I believe they did not. This might have more to do with the fact that the current IRMA app, the use case for it was a broad-based attribute-based credential app, allowing you to prove that you live in a town to get access to the ...

That is true.

Exactly.

Actually, the roadblock they encountered had more to do with the Apple and Google Play stores, not allowing IRMA to be used for anything related to COVID. There is a policy that only developers associated with governments can store and process health information related to COVID.

Those are good points. I haven’t considered this particular angle of why that was used in the Netherlands over IRMA. What I do know, because I spoke with the developers of IRMA, is that they were investigating using IRMA for vaccine passports.

As soon as anything happens, the bouncer can then have another session happen immediately afterward.

Yes. I have a slide at the end that talks a little bit more about the existing libraries that are available for IRMA. What you can essentially do is modify the frontend to be constantly generating new sessions. Anytime you get any type of results, you get a new session ...