Re: [saag] Interest COVID-19 'passport' standardization?

[Dirk-Willem van Gulik <[e-mail]>]

On 30 Jul 2021, at 22:57, Carsten Bormann <[e-mail]> wrote:
> On 2021-07-30, at 22:40, Harry Halpin <[e-mail]> wrote:
>> 
>> While I support your sentiments (in fact, I warned against the persistence and abuse of COVID-19 related infrastructure as soon as the pandemic hit [1]) and do note that the COVID-19 passports have already happened in most countries, particularly in the EU. If they were built with open source and open international standards, with actual privacy and security, then it would be harm minimization. 
> 
> There are some components in the EU DGC that we might want to extract and properly specify.


First - a word of caution - these standards were developed as the pandemic evolved - and are very narrowly tailored to a very specific compromise w.r.t to time, scope and what was legally possible quick enough.

Secondly be also aware that the EU DCC has a very specific and narrow use case - cross border travel; and is used in a setting where a traveler is generally also required to carry a passport or similar. As they are crossing borders. 

With that caveat - privacy impact is minimised in that setting - but by design it still reveals identity and some medical details to the verifier[1]. As that is core to that use case.

Conversely domestic implementations (like the one in the Netherlands) that are designed for use in the private sector (e.g. by a bouncer in the bar) are designed against different use cases. 

And, taking NL as an example again, may use selective disclosure, ZKP and other techniques to frustrate or prevent surveilance or tracking (i.e. not being able to recognise a person as they move around and see scanners at different bars).[2]

Most of this is quite akin to verifiable credentials - or borrows heavily from it. 

However both the EU and domestic approach allows for fully off-line use (i.e dynamically generated Qrs and verifiers with a static trust list). With absolutely no need to verify something ‘on line’ — not even something like an OCSP-ish revocation at Qr level. This is to minimise surveillance. 

Both approaches have been heavily optimised for size - as Qr are challenging in the field if they contain more than 1200 8-bit byte equivalent or so.

Standards can be found at https://github.com/ehn-dcc-development

If you are curious - most countries opensource their code (also to help with trust in society) - and joint European effort (by something called the eHealthNetwork) base implementations are also open source[3].

With kind regards,

Dw.
— 
Dirk-Willem van Gulik (currently helping the Ministry of Public Health in the Netherlands out as their CTO).


1: For the technology see: https://ec.europa.eu/health/ehealth/key_documents_en#anchor0 and specially https://ec.europa.eu/health/sites/default/files/ehealth/docs/digital-green-certificates_v3_en.pdf.  

In short; it is an Qr code that can verified fully offline (both for scanner and citizen) that consists of a JSON payload, CBOR packaged, COSE signed, zlib-defalte compressed and base45 transport protected with the prefix ‘hc1’.

The JSON payload consists of the persons name and DoB and a medical block - that contains things like the vaccination used, the date, manufacturer and medically/responsibly entity. It does not have things like a passport or citizen number; the name and DoB is all that ties it to some other identity document.

The signature is verified against a trustlist of public keys; the latter is much alike to the ICAO masterlist commonly used for passports; a per country CA signing shorter lived digital signing certificates (ECC is mostly used).

Use this tool to decode your own: https://github.com/ehn-dcc-development/ehn-sign-verify-python-trivial

2: e.g for the Netherlands (https://github.com/minvws/nl-covid19-coronacheck-app-coordination) this is Idemix ZKP based approach; with a Qr code that changes every few minutes - with identity binding limited to just a few initials of the persons last or first name and the day/month of birth (the exact mix coded depends on the prevalence).

3:  Joint standard development: https://github.com/ehn-dcc-development, code NLhttps://github.com/minvws code eHealth Network collaboration: https://github.com/eu-digital-green-certificates