@dirkx has indicate that partial matching for names and date of birth might be needed. Perhaps we can use:

• pfn (partial first name)
• pgn (partial given name)
• pdob (partial date of birth), an object with separate y/m/d (integers) properties

It is clear, that the "vac" element has to contain an array for more than one vaccination.

But what about the test and recovery elements?

A test result is valid for a couple of days at maximum and the next test superseeds the last one. So why should more than one (e.g. old) test results be stored in a hCert?

Recovery: Contains "Date of first positive test result". As there can only be one "first", storing more than one recovery statement in a hCert is senslessless imho.

Can we discuss/decide this in this github group? Or shall we ask e.g. Stefanie from the Semantic Subgroup?

To simplify for verifiers, it would be nice if we can define gender as an enum. What values are permitted?

I have a number of comments on the cert-element (certificate metadata):

• is - rename so that it isn't confused with the CWT issuer (iss) that represents the issuing country. And move up to be an optional element directly under the root.
• id - should be placed directly under the root (and be required)
• vf (validFrom), vu (validUntil) and co (issuing country) - Remove. This information is already available in the CWT and there is not reason to duplicate this info.
• vr - Rename to version and place directly under the root. You can't hide a version attribute deep down if a parser should check this.
• ty (schema type) - Don't understand this. Need to be explained more.

Comments?

While testing and viewing this schema using my available tools, I discovered that none of them supported the latest schema version 2020-12, used here.

Looking at the current support status: https://json-schema.org/implementations.html

It seems that most (including) my current tool Oxygen, supports up to version draft-7 (http://json-schema.org/draft-07/schema)

The only thing that makes the current schema not compatible with draft-7 is the use of the "example" keyword.

Given the current status, wouldn't it be wise to use draft-7 schema instead in order to allow a wider array of tools?
The examples could easily be moved into the descriptive text, even though that is not as nice.

Hi,
from our experience and also a lot of opinions from colleagues the property "name" should be split into "givenName" and "familyName". All known (travel-) documents (passports, id-cards ...) work this way. The information in the cerificate is also needed to be checked against a travel document.

If a reference to e.g. HL7 is needed, 2.24.2.12 HumanName can be used, viz. https://www.hl7.org/fhir/datatypes.html#humanname

e.g.

       "properties": {
            "gn": {
                "title": "Given name",
                "description": "The given name/s of the person addressed in the certificate",
                "type": "string",
                "example": "Tolvan"
            },
            "fn": {
                "title": "Family name",
                "description": "The family name/s of the person addressed in the certificate",
                "type": "string",
                "example": "Tolvansson"
            },

Thanks

This is a machine readable certificate that is encoded in UTF-8 anyway. It adds to the size and is probably done automatic anyway and can easily be done on a verifier side.

Can a Swedish citizen acquire a health certificate from the Netherlands? If so, do also need to include the nationality of the subject in the schema?

I suspect that many of us will generate source code from the JSON schema. In places where a date and time is represented the is expressed as follows in the JSON schema:

                "dts": {
                    "title": "Date and time sample",
                    "description": "Date and time when the sample for the test was collected",
                    "type": "string",
                    "format": "date-time",
                    "example": "2021-02-20T12:34:56+00:00"
                },

For Java users many will probably want to use FasterXML:s Java Jackson-CBOR extension and in those cases a date-time
will be encoded as a CBOR string (tag: 9), but it should really be tag 0 (string representation) or 1 (epoch-based).

You could argue that FasterXML has a bug and that it should understand that a java.time.Instant should be represented using either tag 0 or 1, but I just wanted to raise the concern about possible interoperability issues concerning dates if the parsing side isn't liberal enough to accept any of the tags 0, 1 and 9 where a date-time is expected to be found.

The schema should clarify if the ISO 3166 country codes are in format alpha-2, alpha-3 or numeric? The current examples mentions "xxx" which indicates alpha-3.

An implementation detail, but if you generate code from the JSON schema the class names are taken from the "title" (anyway for the jsonschema2pojo-maven-plugin maven plugin).

The main class will be named, DGCDigitalGreenCertificate since the title is "DGC - Digital Green Certificate". A bit superfluous.

Suggestion. Change title to "Digital Green Certificate" and use DGC in the comment.

The currently defined certificate metadata includes fields like

• Issuer
• Identifier
• valid from
• valid until
• Issuing authority country
• Schema version

Maybe it would be a good idea, to also include a "Certificate-Type" (e.g. vac, tst, rec), so that a verifying application can determine, if the "correct" certificate (for the current usecase) was presented, without having to check the correctness of the schema and/or the signature upfront.

Maybe this or a similar mechanism could also be used to distinguish between different "privacy-levels" of a certificate e.g. medical, border-control, private (hotel, restaurant ...).

And if something like smartphone-wallets are used, they could then (more easy) display the certificate's type & privacy-level, so that the user can choose the certificate he wants to present?

The schema examples shouldn't contain anything but the example. All references MUST be in the description.

In https://github.com/ehn-digital-green-development/hcert-schema/blob/cb-name/eu_hcert_v1_schema.yaml I noted "optional", when a data field is not mentioned in the appendix of the regulation.

What shall happen to data fields, which are not in the appendix, but in the result of the Semantics workgroup? (e.g. person identifier, gender ...)? (Or which have obviously been forgotten in the appendix?)

I'm not a JSON schema guy but when I generate Java code from the schema some types maps to Object. So:

• vac/seq should be "integer"
• vac/tot should be "integer"
• vac/lot should be "string" (or?)
• vac/dat only specifies format, but no type (add "string").
• vac/adm has "format=string". Should be "type=string".

For tst the "type" is missing and format is used instead. Change.

• rec/dat is missing type.
• rec/cou specifies format instead of type.

but it doesn't exist. It should be gnt.

And that raises a question. Do I have to supply transliterated strings also in the cases where the transliterated name would be the same as the one in gn or fn.

Should we bring the schema now to Version 1.0 and tell Martin Mitev about?

Who should do this? I's suggest @dirkx

Regards,
Chris