ehn-dcc-development / eu-dcc-schema Goto Github PK

Hello all,

We are going to generate also a PDF representation of the DGC. We have many non-digital citizens, which we hope to reach with such representations. Anybody has experiences to share with respect to the look and feel of paper DGCs?

Are there any European specifications or directives concerning the look and feel of the digital green card, for the PDF and paper version? Will there be specifics concerning the format, pixels, design,... Or does every issuer just have to make sure that the required fields are present and is the layout the responsibility of the issuer?

Thanks in advance,

Peter

It seems the relationship between this repo and https://github.com/ehn-digital-green-development/hcert-schema needs clarification. More specifically, it needs to be justified where the schemas are not compatible.

eHN vaccination interop guidelines - Annex 2.

1. Option 1?
2. Option 2?
3. Option 3?

The UVCI is described as an identifer and its usage is stated in both the vaccine entry, test entry and recovery entry. However, in Annex 2, Option 2 the following is stated:

This single field serves as the unique identifier of the vaccination in the national vaccination registry of the corresponding country. It is the Member states’ responsibility to come up with the mechanism for generating and indexing the forementioned single unique vaccination identifiers.

I have a hard time seeing how the (national) vaccination registry should hold any identifiers in relation to an episode of obtained recovery.

Bottomline: The UVCI is by Annex 2 bound to the use of vaccine, but it is also used in the context of test and recovery

Hello again,

I just started validating with the new DGC Schema version 1.0.1 in parallel with the older version 1.0.0

Some of my test JSON data files now have "ver": "1.0.0", others "ver": "1.0.1".

I use the Ajv validator but I'm sure other tools will show a similar behaviour:

As the schema $id of version 1.0.0 and version 1.0.1 are identical, Ajv complains when I'm trying to load the second schema in the same instance with ajv.addSchema(schema2-N, 'semver') or ajv.compile(schema2-N).

This makes it impossible to use the same Ajv instance for all DGC Schema versions.
From an implementer's perspective this is quite impractical and resource inefficient (even when instance caching is used).

Ajv has wonderful mechanisms for managing multiple schemas and versions:

https://ajv.js.org/guide/managing-schemas.html

However, they seem to rely on different schema $id values.

As I understood it's generally a good idea with JSON Schema to include the semver (-> schemaver) in the $id.

Some further external links for interested people:

http://docs.mediachain.io/publishing/schema-recommendations

http://docs.snowplowanalytics.com/docs/pipeline-components-and-applications/iglu/common-architecture/schemaver/

Miguel

e.g. https://github.com/ehn-digital-green-development/ehn-dgc-schema/blob/main/examples/test-rat.json

I suggest that we use JSON schema 2020-12. If people need to use earlier versions for code generation, they can filter and downgrade, but the normative version should be a non-draft-version IMHO.

Annex 2 in the eHN Vacc Interop spec specifies that the UCVI should have a checksum suffix according to the Luhn mod N-algorithm.

However, for interoperability, we need to be clear of the order of the allowed character set (A-Z 0-9 and '/', '#' and ':'). Each character needs to have code-point, and the spec isn't clear here. Should we read the following text:

Charset: Only uppercase US-ASCII alpha numerical characters (‘A’ to ‘Z’, ‘0’ to ’9’) are allowed; with additional special characters for separation from RFC39865, namely {'/','#',':'};

and understand that the order should be: ABCDEF....XYZ0123456789/#:

Or should use Ascii-ordering?

Hello all,

Don't know if this is the right place... but... I have some questions w.r.t. the European DGC GW:

• What will be the process for delivering our public keys to the European gateway?
• Is there a swagger available of that API?
• Can someone provide me with the specific endpoints and the process of getting connected?
• How can we determine which public key to use (from all available public keys of one country) when validating a scanned QR code?
  Thanks,

Peter

#38 (comment)

closes #38

Please rename DGC.Core.Types.schema..json to DGC.Core.Types.schema.json

Pending resolution by the EC for its permanent place.

Should the schema be typed with value sets for changing information, ie vaccine?
According to Article 5 in the regulation 2021/0068 it should be possible to provide a vaccination certificate containing vaccine that has been authorised by a competent authority of a Member State (MS). That will demand a new version of the schema when ONE MS authorize a new vaccine. But the other MS may only accept it in validation. But to be able to read the data all MS needs to update the validation when one MS authorize a new vaccine. Therefore its more safe to not use value sets in schema. Better to have them accessable in one place so that verifiers can use them instead. And more cost effective also.

CBOR can represent a time stamp both as an int and as a string. However, the schema states that timestamps should be strings:

       "sc": {
          "description": "Date/Time of Sample Collection",
          "type": "string",
          "format": "date-time"
        },
        "dr": {
          "description": "Date/Time of Test Result",
          "type": "string",
          "format": "date-time"
        },

For the sake of interoperability and to smoothen the differences between JSON and CBOR I think that we need to have a writing (in the wiki or somewhere else) that clarifies this. My suggestion is to be clear that date-time fields should be CBOR encoded using the string representation. Otherwise we'll introduce completely unnecessary interop-problems when going from CBOR to JSON and back.

Also, see eu-digital-green-certificates/dgc-testdata#30.

Dear DGC Schema Team,

During my JSON validation experiments I've found a little inconsistency:

In the following JSON Schema:

https://github.com/ehn-digital-green-development/ehn-dgc-schema/blob/main/DGC.ValueSets.schema.json

test-results.json is referenced:

    "test-result": {
      "description": "EU eHealthNetwork: Value Sets for Digital Green Certificates. version 1.0, 2021-04-16, section 2.9",
      "type": "string",
      "valueset-uri": "valuesets/test-results.json"
    },

However the file is called test-result.json

https://github.com/ehn-digital-green-development/ehn-dgc-schema/blob/main/valuesets/test-result.json

So I would propose either renaming the file or updating the reference.

Miguel

Hi

probably is not the right place to ask this but I hope to get some confirmation about this.

The DGC issuing and expiring date are not included in the DGC JSON schema.
I assume the reason behind this is to use the common payload values "Issuing Date of the DGC" and "Expiring Date of the DGC" (see https://ec.europa.eu/health/sites/health/files/ehealth/docs/digital-green-certificates_v3_en.pdf, page 8, table at paragraph 2.6.3)

I recently reviewed the paragraph 3.3.5 of this document:
https://ec.europa.eu/health/sites/default/files/ehealth/docs/digital-green-certificates_v1_en.pdf
Here the "Expiration time" seems to be related to the signature instead of the DGC expiration date.

The DGC validity period is important for the Verifier app, so I think we must agree about the meaning of those fields.

This is a valid DGC at the moment. It won't fit in the QR.

But as a verifier, I want to make sure I am supposed to expect massive payloads like the on below.

Also, what happens when payloads don't fit in the QR? Do issuers create many QRs? Do we merge them by name? Can we assume if the name + dob matches, it is the same person?

Or is there another digital way to transfer bigger credentials? Sending the HC1 in plain text?

{
 "ver": "1.0.0",
 "nam": {
   "fn": "d'Arsøns - van Halen",
   "gn": "François-Joan",
   "fnt": "DARSONS<VAN<HALEN",
   "gnt": "FRANCOIS<JOAN"
 },
 "dob": "2009-01-28",
 "t": [
   {
     "tg": "840539006",
     "tt": "LP217198-3",
     "tr": "260415000",
     "ma": "1232",
     "sc": "2021-04-13T14:20:00+00:00",
     "dr": "2021-04-13T14:40:01+00:00",
     "tc": "GGD Fryslân, L-Heliconweg",
     "co": "NL",
     "is": "Ministry of VWS",
     "ci": "urn:uvci:01:NL:GGD/81AAH16AZ"
   }, 
   {
     "tg": "840539006",
     "tt": "LP217198-3",
     "tr": "260415000",
     "ma": "1232",
     "sc": "2021-04-13T14:20:00+00:00",
     "dr": "2021-04-13T14:40:01+00:00",
     "tc": "GGD Fryslân, L-Heliconweg",
     "co": "NL",
     "is": "Ministry of VWS",
     "ci": "urn:uvci:01:NL:GGD/81AAH16AZ"
   }, 
   {
     "tg": "840539006",
     "tt": "LP217198-3",
     "tr": "260415000",
     "ma": "1232",
     "sc": "2021-04-13T14:20:00+00:00",
     "dr": "2021-04-13T14:40:01+00:00",
     "tc": "GGD Fryslân, L-Heliconweg",
     "co": "NL",
     "is": "Ministry of VWS",
     "ci": "urn:uvci:01:NL:GGD/81AAH16AZ"
   }
 ], 
 "r": [
   {
     "tg": "840539006",
     "fr": "2021-04-21",
     "df": "2021-05-01",
     "du": "2021-10-21",
     "co": "NL",
     "is": "Ministry of VWS",
     "ci": "urn:uvci:01:NL:LSP/REC/1289821"
   }
 ], 
 "v": [
   {
     "tg": "840539006",
     "vp": "1119349007",
     "mp": "EU/1/20/1528",
     "ma": "ORG-100030215",
     "dn": 2,
     "sd": 2,
     "dt": "2021-05-07",
     "co": "NL",
     "is": "Ministry of VWS",
     "ci": "urn:uvci:01:NL:PlA8UWS60Z4RZXVALl6GAZ"
   }, 
   {
     "tg": "840539006",
     "vp": "1119349007",
     "mp": "EU/1/20/1528",
     "ma": "ORG-100030215",
     "dn": 1,
     "sd": 2,
     "dt": "2021-04-15",
     "co": "NL",
     "is": "Ministry of VWS",
     "ci": "urn:uvci:01:NL:PlA8UWS60Z4RZXVALl6GAZ"
   }
 ]
}

According to the wiki the Luhn-Mod-N charset used during calculation is ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789#/:. This means that the # character whose only purpose is to be used as the delimiter for the UVCI and its checksum may end up as the checksum character, e.g.:

01:SE:EHM/123456789KOOZC6RM7VZ##

Is this really want we want? I think it is sensible to exclude the # character from the charset since it can not appear anywhere in the UVCI.

Hi,

why the regex check in the dob, which is already declared as format "date"?

https://github.com/ehn-digital-green-development/ehn-dgc-schema/blob/73178219592a1b351bf48a53012b6bcf0122c16c/DGC.schema.json#L31

Also, it does not allow 10 or 20 as a day.

Hi

as for the test entry I see the following fields:

    "nm": {
      "description": "NAA Test Name",
      "type": "string"
    },
    "ma": {
      "description": "RAT Test name and manufacturer",
      "$ref": "#/$defs/test-manf"
    }

The Annex reports this fields as following:

(e) test name (optional for NAAT test);
(f) test manufacturer (optional for NAAT test);

From my understanding, the NAA Test are always considered valid for generating a DGC.
So is the "nm" field really necessary?

According to https://www.icao.int/publications/Documents/9303_p3_cons_en.pdf it should be just one < charcater to divide two given names, or family names. In their examples, << are used to divide the family name from the given name.

What kind of data will you guys use to issue a recovery certificate?
We were thinking to only issue them for people who had a positive antibody test.
Should we consider to issue such certificates to people who had a positive PCR test (with a validity date N days after such a test)?
What are the other countries doing wrt those BIZ rules?

http://json-schema.org/specification-links.html#draft-7

I opened this PR because of it, but it doesn't seem like it will be accepted. On iOS, this schema isn't valid. kylef/JSONSchema.swift#121

Why was it dropped?

We need to define a stables identifier ($id) for the schema. Preferably, it should be possible to retrieve the (combined) schema using the URI used as $id.

Hello,

In LU, we face some issues regarding the definition of the JSON schema for the test DGC (PCR and Rapid Test).
The following points shall be discuss.

To summarize, as it is defined right now, the JSON schema for the test DGc has the following mandatory fields:

• tg --> disease targeted
• tt --> type of test
• sc --> date/time of the sample collection
• tr --> date/time of the test result
• tc --> testing center
• co --> country of test
• is --> certificate issuer
• ci --> UVCI

and the optional fields:

• nm --> test name
• ma --> RAT test name and manufacturer

For the two optional fields, the information is get from https://covid-19-diagnostics.jrc.ec.europa.eu/devices.

If we look at the examples within this repository (test-naa.json and test-rat.json), we observe the following:

1. for test-naa.json
   • "nm" field is present, and seems to contain the "Commercial Name" from https://covid-19-diagnostics.jrc.ec.europa.eu/devices
2. for test-rat.json
   • "ma" field is present, and contains the "ID Device" https://covid-19-diagnostics.jrc.ec.europa.eu/devices
   • a "dr" field is present, which seems to be a typo as it should be "tr", but this field is actually optional for rapid test

Thus, we have the following remarks:

1. In the PCR test DGC, the JSON schema contains the Commercial Name. In the Rapid Test DGC, the JSON schema contains the ID_Device. This is inconsistent, as in both types of test, the ID_Device points to the Commercial Name and the Manufacturer Name. To avoid redundancy and save some space within the QR Code, the ID_Device only should be used within the JSON schema, for both types of test.

2. The "tr" field for Rapid Test DGC is optional, not mandatory. This shall be changed within the specification of the JSON schema (in Luxembourg, we will not have this information given by the concerned parties).

Thanks in advance for clarifying this.

In the schema we've the following top level keys until now and propose we keep them unless there are really good reasons for changing them at this late hour.

• v (version)
• dgcid
• sub (subject, with names etc)
• vac
• tst
• rec

Hi all, not sure where to put this question.
I just wanted to bring this thread to your attention. Maybe this would be a better place to address some of it's questions therein.

corona-warn-app/cwa-documentation#615

Hi all

is the passport number or other citizen identifier not allowed anymore in the data schema?

Regards

See #45

Where do these change requests come from?
For the third time during the week, I am fundamentally reworking the api, due to these changes ....
What is the significance that at the moment the "sub" has completely disappeared from the scheme compared to the previous version?
https://github.com/ehn-digital-green-development/hcert-schema/eu_dgc_v1
Will it be added yet?

According to the latest adopted text in the regulation the minimum dataset shall include

date of vaccination, indicating the date of each dose received and of the latest dose received;

https://www.europarl.europa.eu/doceo/document/TA-9-2021-0145_EN.html

Do we allow the schema to be extended or is data per this schema locked to this, and only this.
If extensions are not allowed we should set additionalProperties to false.

What library do you use for valuesets validation. I am looking for python implementation if possible.
Thnx.

We probably need to drop the need to have both a GN and an FM; e.g. with an arab name; eg; this poet/physisisct you'd get:

"nam": {
"fnt": "ابو بكر محمد بن زكريا الرازي",
"_fn": "ABU<BAKR<MOHAMMED<IBN<ZAKARIA<AL<RAZI",
},

Then there is neither a given name or a first name. So this is what you see on a passport - no '<<' in sight. More examples in the ICAO spec or in https://www.icao.int/Meetings/AMC/MRTD-SEMINAR-2011-DOHA/Documents/6_Ellis.pdf.

As we cannot use the "full stop" convention in the _gn (as the full stop would be dropped) - I suggest dropping the required value and documenting primary name use for this field.

Hi

here at this link:

https://covid-19-diagnostics.jrc.ec.europa.eu/devices/2?manufacturer=&text_name=&marking=&rapid_diag=&format=&target_type=&field-1=HSC%20common%20list%20%28RAT%29&value-1=1&search_method=AND#form_content

there are the rapid antigen test EU approved.
I am wondering how we are going to manage the updates of this list vs the valuesets in test-manf.json file.

As for now there are 66 tests in the approved list compared to the 26 entry in the test-manf.json file.

It seems like the fully dressed example on https://github.com/ehn-digital-green-development/ehn-dgc-schema/blob/main/examples/contrived-all-options.json is missing the t.ma field

Why is the Signing Certificate in DGC.schema.json?

"dsc": {
  "description": "Document Signing Certificate: 8 bytes",
  "$ref": "https://ec.europa.eu/dgc/DGC.Types.schema.json#/$defs/dsc"
},

shouldn't it be the "Certificate Identifier"?

"certificate_id": {
  "description": "Certificate Identifier",
  "type": "string",
  "$comment": "SemanticSG: check spec for Cert ID: eHN Recovery pdf referred to Vacc UVCI for this field, so they _may_ all be in the same format as UVCI - or not?",
  "unique": true
}

Why should every cert include minimum one of each for:

• Vaccination Group
• Test Group
• Recovery Group

They differ, but which one is the one?

It is a standard case that for date of birth either the full date (YYYY-MM-DD) is known, or just an (often estimated) year (YYYY) (e.g. FHIR Patient.birthDate). It can also be the case, but less frequently occuring, that year and month only (YYYY-MM) are known.

The DGC schema must be able to support all cases as valid.

Applying the first part of Postel's law: the DGC schema should accept anything that at least has 4 consecutive decimal digits at the beginning, since we can then interpret this at the minimum as a year. In order to filter out a lot of noise with random values, we can reasonably limit the year range from 1900 to 2099, A simple regex suffices here.

Applying the second part of Postel's law: note as already mentioned elsewhere (https://github.com/ehn-digital-green-development/ehn-dgc-schema/blob/main/README.md, https://github.com/ehn-digital-green-development/ehn-dgc-schema/wiki/FAQ#issuance-of-qr) that it is the primary responsibility of the issuance business rules to generate clean data for submission to the DGC payload.

The current regex for dob is
"(19|20)\\d{2}-\\d{2}-\\d{2}"
and it now needs to be
"^(19|20)\\d{2}"

It seems, that ORG-100020693 is included twice in the list of vaccine-mah-manf: https://github.com/ehn-digital-green-development/ehn-dgc-schema/blob/main/DGC-all-schemas-combined.json#L343 and directly after that.

During this monday's meeting on DGC pilot testing there were some people at T-systems that claimed that the schema published in the EU-docs were the one to use. (Gaby's first draft of what we are working on). That won't work.

I also heard that in tommorrow's meeting the schema should be finalized. Are we ready our work to 1.0.0?

@gaby, I think that we should remove examples that are not correct according to the latest agreement: there will be just one dataset in a QR code.

I noticed there are pre-defined ValueSets for the test-manf field, but I don't seem to find a descriptor for those options anywhere. Am I missing something?

I know this is not standard for JSON on the web, but since the schemas have so many date and datetime fields more efficient DateTime representations can bring significant benefits to the QR code.

Ideally, you want to use a format that marks the scale (days, hours, minutes, seconds, milliseconds or ticks) and uses an integer number of that scale between the given time and an arbitrary epoch (1/1/1970). This lets it send things like date values in a minimal number of bytes.

Even a simple second scale for all dates to the epoch (1/1/1970) represents gains of ~10% on the size of the Covid Test QR.

A typical value-set looks like:

{
  "valueSetId": "disease-agent-targeted",
  "valueSetDate": "2021-04-27",
  "valueSetValues": {
    "840539006": {
      "display": "COVID-19",
      "lang": "en",
      "active": true,
      "version": "http://snomed.info/sct/900000000000207008/version/20210131",
      "system": "http://snomed.info/sct"
    }
  }
}

But for some of the value-sets, the valueSetId is included also in the value. For example:

{
  "valueSetId": "vaccines-covid-19-auth-holders",
  "valueSetDate": "2021-04-27",
  "valueSetValues": {
...
    "ORG-100030215": {
      "display": "Biontech Manufacturing GmbH",
      "lang": "en",
      "active": true,
      "system": "https://spor.ema.europa.eu/v1/organisations",
      "version": "",
      "valueSetId": "vaccines-covid-19-auth-holders"
    },

This is a bug, right?

Since all the elements we are representing in a DGC seem to have an UVCI I suggest that we move it up under the root.