Questions reg. the implementation of vaccination certificates

[watmm]

I realise this is still a work in progress, but I have questions.

@d4rken In 6733-vaccination-polling you say "Depending on what vaccination data the user has added to the CWA"

Can you elaborate on this for people not involved with the development. It sounds like you're saying that the data revealed by scanning the QR code upon vaccination validation can be limited by the user, is this correct, and if so, what are the minimal amounts of data contained within and revealed by such validation?

At the point of verification, what information is revealed, and is it just verified visually, or recorded? Thanks.

Ideally just a list of data stored locally, data stored remotely (central server), data stored remotely (verification site).

If the answer to these questions are unanswerable right now / moving targets, that would also be interesting to know.

---

Internal Tracking ID: EXPOSUREAPP-7352

---

Related to topic: Check signature of certificates Internal Tracking ID: EXPOSUREAPP-8010

[Ein-Tim]

@watmm

I propose to change the title to something like "Questions reg. the implementation of vaccination certificates".

[watmm]

I'm more interested in the content of the replies than the title. I just picked this as it's probably more likely to attract attention. As you wish.

[thomasaugsten]

The mentioned function in the PR is deprecated. You can scan your paper vaccination certificate to transfer it with all field and information into the CWA. You can show the QR code to a person with a proof app. This proof app check if the signature of your vaccination certificate. is valid. The signature is a certificate chain and the proof app check the validity of the certificate chain. No need to send data to a server the validation can happen on the proof device.

Here you can find the official DGC definition of the EU for a vaccination certificate https://github.com/ehn-digital-green-development/ehn-dgc-schema/blob/main/DGC.Types.schema.json

[watmm]

Hi Thomas,

Thanks for that. Would like to bring these technical guidelines to your attention https://ec.europa.eu/health/sites/default/files/ehealth/docs/digital-green-certificates_v4_en.pdf

6.3.1 Frontend The verifier app frontend provides functionality to scan and verify DGCs. It scans the base45- encoded QR code, extracts the COSE signature, and decodes CBOR back to JSON (see also 6.2.1). It then verifies the signature with the keys provided by the verifier app’s backend. The app uses only open-source libraries; all DGCs scanned or processed are ephemeral and will not be stored.

I would like to highlight the fact that these are just guidelines and explore the possibility that they are actually stored at the verification point.

In that case, can you say what data is made visible to the verifier?

[thomasaugsten]

There is no need to store the data a the verification point the signature check is on the fly possible without persisting data. Recommended is to show only the name to the verifier to check the certificate with an ID card. But the proof/verifier app has access to all field of the JSON.

[watmm]

That's unfortunate. Do you know of any way the public can be assured that nothing is stored? I don't understand why the verification process isn't a one time event that occurs when you scan your certificate QR and is only visually examined from then on.

[watmm]

Lets take SCHUFA as an example. Businesses interact with this all the time without being made aware of it's inner workings. The only thing that is displayed to them is essentially a thumbs up or thumbs down. Surely this is possible here too?

[thomasaugsten]

It is not possible to make it as an one time event because you can manipulate any data on your phone. There is no central database of all EU vaccination certificate to realize a centralized verification and in any way you have to send an unique id to the server and verify this unique id belongs to the user.

[watmm]

I know you're not a lawyer, but...

This amendment requires member states who wish to use "digital green certificates" for uses beyond member state borders, to first enact local legislation to do so.

https://www.europarl.europa.eu/sed/doc/news/flash/25465/P9_AMC(2021)0104(012-013)_EN.docx

Does this not fall under the category of a "digital green certificate"?

I'm less concerned about a central server than i am about a growing collection of personally identifiable location data.

And yes, i know how phones work :) but i'm specifically talking about government access.

[jucktnich]

I understand, that the codes can't be created on the phone due to obvious security reasons, but what's about creating multiple codes, one only with full name and one with all data.

[thomasaugsten]

I have no understanding about this amendment. I don't see a different between a central server where you request with location data a status and the theoretically collection of personal location data

All information like name and status needs to be signed as one by an authority to make a validation with the person ID card possible

[watmm]

The amendment is about stopping it being used EU wide for purposes beyond border control.

I wasn't aware location data was required to authenticate with the central server, that's even worse.

So you're saying at every restaurant/bar/etc I need to trust that the verifier does not store the data it has full access to, and the central server receives my coordinates for some reason?

[thomasaugsten]

It is not required but you can see easily see the IP of the check request and you have no control what information are saved on the central server. But there is no central server because of this kind of problems.

Exactly but this is not an issue of the verifier app because the restaurant can also save manually your data without verifier app and the official app is not storing data.

[watmm]

Ah well an IP doesn't connect a person to a place in time. That's fine. It's a lot better than say, a list of nearby bluetooth devices, or GPS coordinates.

The verifier remains my area of concern precisely for the reason you say that. First of all, we're being asked to accept that its code follows the policy document above, correct? Are verifiers open source? Second, as you point out, a shop could implement their own. Which might do more than what is strictly policy. No?

Quite simply, the weak point is the exposure of the data that is none of their business.

[watmm]

I don't understand why more people are not contributing towards the discussion that this is either not good enough or that we can do better.

[watmm]

Lets try this again...

Do you know of any way the public can be assured that nothing is stored? e.g. Are there CWA-side requirements placed on verifier apps?

[ndegendogo]

@watmm as far as I understand, this verifyer app is specified by BMG as part of the CoVPass project, but neither specified nor implemented by cwa project. If this is true, then this project might be the wrong place for the discussion on the verifier app

[watmm]

Thanks for that, however if the CWA is releasing all json fields then it is responsible.

[Ein-Tim]

@watmm Are you aware of https://github.com/ehn-digital-green-development & https://github.com/eu-digital-green-certificates?

I don't see why CWA has a special responsibility here, every app which implements the digital vaccination certificate would have this problem if I get you right. So maybe it'd be better to place this issue in a repository of one of the above mentioned GitHub projects? Especially https://github.com/ehn-digital-green-development/hcert-spec/issues seems to be a good place for this question.

Edit: See also https://github.com/Digitaler-Impfnachweis for the GH repos of the German app. Edit 2: But I really hadn't any time yet to dive into digital vaccination certificates theme so could easily be that I mix things up/understand something wrong (:

[watmm]

Thanks for the links Tim. It's late, so will take a proper look tomorrow. Is this project a requirement for all apps of this kind?

[Ein-Tim]

@watmm

Is this project a requirement for all apps of this kind?

I assume if you want to be compatible with this project then you have to match their requirements. But as said, I haven't had time yet to dive into the digital vaccination certificates theme, so this is only an assumption.

[ndegendogo]

@Ein-Tim thanks for the links - but, actually, I am lost, and don't understand much ...

[Ein-Tim]

@ndegendogo

Your not alone! It's really hard to keep an overview over all the different implementations & even harder to understand it... I'm lost too 😅

[MikeMcC399]

@Ein-Tim Also thanks from me for the links. https://github.com/Digitaler-Impfnachweis leads also to https://digitaler-impfnachweis-app.de/ for the CovPass-App and it's interesting to see in the https://digitaler-impfnachweis-app.de/impressum/ that RKI is responsible, same as for CWA.

[ndegendogo]

RKI is responsible

@MikeMcC399 actually no big surprise. In our federal structure, the ministry of health (BMG) is the top national instance for health-related issues. And RKI is one of their departments.

[watmm]

Ya'll can follow this in the two "Privacy concerns" links above.

[Ein-Tim]

@watmm You might want to take a look at https://github.com/ehn-digital-green-development/hcert-spec/discussions/85

[watmm]

Here we go again, as to date nothing has been answered from any of these sources, including the 79 MEPs I contacted that voted for the very restrictions i'm asking about.

1. Where can i find the code for the frontend(s)?
2. What are the requirements for future compatible frontends?
3. Are they just legal requirements or in some way forced by design?

I don't know how to be clearer so maybe an anecdote would help. Say i want to write my own frontend, what do i have to comply with?

Can i write anything i want until public pressure (lol) requests an independent security audit?

Edit: To clarify, by "frontend" i mean verifier.

[watmm]

https://www.berlin.de/sen/gpg/service/presse/2021/pressemitteilung.1094512.php

Ganz wichtig: Alle Nachweise für Reisen oder Teilnahme an Veranstaltungen oder Verzicht auf Testerfordernisse können von Geimpften auch durch ihren nichtdigitalen Impfpass erbracht werden.

So, the yellow vaccination booklet?

That's fine then. Provided it works like that in practise.

[ndegendogo]

@watmm I did not follow up on the latest specs, so my understanding might be wrong, incomplete or outdated. This said, a few thoughts from my side on the topic:

The yellow vaccination booklet has a few big drawbacks, but also a few big good points:

• it is easier to forge than a solution with a digital signature
• it is paper, and will wear out fast if you carry it with you and use it all the time
• it will expose a lot of medical data that is not needed for use cases like entry to a shop or event, so it violates the principles of 'Datensparsamkeit'
• on the other side, it will be checked with a manual procedure, which makes it less probable that a rogue verifier app retains your data
• as far as I understand the specs for European interoperability from enHealth, they require a unique ID on each digital vaccination certificate. Although this ID is not bound directly to personal or medical data via a central database, it could be used for tracking by rogue verifier apps. The yellow booklet simply does not have such a unique ID.
• also the enHealth did not specify any requirements on verifier apps to prove their authenticity (like a mutual authentication before a wallet app exposes the QR code). This is unfortunate, because now as a user you just have to trust the verifier app ... but this cannot be fixed by cwa, it needs to be addressed in the specs on European level
• finally, it would be possible without breaking the interoperability requirements, that the issuer gives me two signed QR codes with different amount of data, for the two use cases 'medical' and 'travel'. But I have not heard of any plans to implement it like this. And, again, this is out of scope of cwa, they can only take the QR codes that they get from the issuer