UVCI is in three places

[martin-lindstrom]

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.

[dirkx]

Given that you get multi-short actions and some countries may have separate evidence identifiers - I am fine leaving them were they are.

Or have them optional everywere and make a note that a top level one is allowed in lieu of the ones lower down were appropriate.

[martin-lindstrom]

I am fine with whatever. Having a programmer background I couldn't help pointing it out ...

[chris2286266]

As the DGCI (which the UVCI is called now) is relevant for e.g. "revoking" a DGC (no matter with which content) it would be more logical, if it resides under the root.

Additionally if it is in the (e.g. vaccination) group, and two vaccinations are in the DGC they could have different DGCIs which is simply wrong (as it must be unique),

[chris2286266]

Additionally it could be discussed, to move the "is" (issuer) to the root level, imho there can only be one distinct issuer per certificate, namely the authority, which generates the json file ...

[gabywh]

Discussion with the Semantic SG, was chosen to add UVCI in the description text. This was prompted by my question: What is the format of the certificate identifier for test and recovery certificates? I was told at the time they would be of the same format as UVCI, but that is something I need to follow up on with Semantic SG.

Thus:

1. each of the certificate identifiers are separate: one for vacc, one for test, one for recovery
2. raises the question of whether you need a certificate identifier for the whole package -> I don't think so, there is no medical equivalent. If you are doing verification, you will want to verify each section (if present) in and of itself
3. I think modifying the description to say "format: UVCI" instead of just "UVCI" would be a lot clearer - agree with you there

[gabywh]

As the DGCI (which the UVCI is called now) is relevant for e.g. "revoking" a DGC (no matter with which content) it would be more logical, if it resides under the root.

You would revoke a vaccination certificate, or a test certificate or a recovery certificate. Different, separate discussion on the mechanism for revocation but the idea summary is essentially to have an "allow" list of known good, if it isn't on there, it isn't valid -> but as I said, this is a different discussion for a different place

[chris2286266]

Agreed!

FYI: Concerning the format: in the "old" schema it was defined like this: Country Code plus arbitrary string (consisting of characterset 0..9,A..Z), max. length 50. E.g. ATOZQWGY3IOJUXGYTBOVWWC3TO

[dirkx]

The format is a bit more involved (https://ec.europa.eu/health/sites/health/files/ehealth/docs/vaccination-proof_interoperability-guidelines_en.pdf) the plain string is:

01:AT:ABCDXYZ0123789
01:AT:ABCDX/YZ0123789
01:AT:ABCDX/YZ0123/732ABC89

So 01:([A-Z]{2,}):([A-Z0-9]{1,}:?[A-Z0-9]{1,}:?[A-Z0-9]{1,} and in earlier documents we suggested to make it a valid IRI / URI by prefixing it with 'urn:uvci:' when used in a digital format - and allow the simplification to

AT:ABCDXYZ0123789 or AT:AB/CDXYZ0123789 or AT:AB/CDXY/FG12EEZ0123789

or even without the country name. With the suggestion to add '#' as a checkum for print as per the EU document.

[gabywh]

format: there was another version proposed with eHealthNetwork which had something like (IIRC):

[2 digit version number][country code - *mostly* two letters!][some unique ident]

One of the difficult parts is non-2-letter country codes (rare, but can happen) - so we should also include some kind of "end of header" marker. Discussion within SemanticSG. I will follow-up (today or tomorrow) on whether they now have a concrete, final defintion for the format and update this ticket as soon as I know more

[thinkberg]

Can we have a final decision here please?

[gabywh]

Can we have a final decision here please?

see above:

https://github.com/ehn-digital-green-development/ehn-dgc-schema/issues/15#issuecomment-826688855 "each of the certificate identifiers are separate: one for vacc, one for test, one for recovery"

Only thing left is actual format of the certificate identifier, that's not a decision to be made here, we follow SemanticSG on this

[kruzikh]

My understanding is that format of all certificate identifiers should be the same. The format was proposed in the Trust framework document (originally build only for vaccination certificates, however I don't see any reason for a different format for the remaining two) and agreed by the eHN. Anyhow, it is a meter of a technical specification, not a semantic one. The only requirement is that each certificate should have a unique id.

[gabywh]

My understanding is that format of all certificate identifiers should be the same. The format was proposed in the Trust framework document (originally build only for vaccination certificates, however I don't see any reason for a different format for the remaining two)

ok, thanks, settled:

• 3 different cert ids
• all of format UVCI, and
• all unique.

and agreed by the eHN. Anyhow, it is a meter of a technical specification, not a semantic one.

If we have fields with meaningful information in there, then semantics are attached - but it's fine: UVCI format already spec'ed and we can re-use

The only requirement is that each certificate should have a unique id.

Indeed as per the proposed EU regs. So let's keep it simple and just choose a new GUID each time. Sorry, couldn't resist that one - joke! ;) We stay with UVCI format, as above.

[kruzikh]

:-)

[martin-lindstrom]

Not concerning the format but the original question: I don't understand. Suppose that I have a DGC with two vaccination entries. In these cases I have to duplicate the ID and add it to both entries. Because the entries belong to the same green certificate. This doesn't make sense.

Or am I missing something?

[gabywh]

Was just updating the docs to answer questions like this, compiling an FAQ which I think would be helpful for everyone. Anyway, specifically:

Suppose that I have a DGC with two vaccination entries

1st answer: current proposed legislation does not allow for this: only the last is stored, as per https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:52021PC0130 there should only be the last one stored, so cardinality for each of the entries in the DGC schema is 0..1 (thus 0 or 1 vacc, 0 or 1 test, 0 or 1 recovery)

2nd answer: each vaccination event will have its own certificate id, as as per the Annex in https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:52021PC0130 so - no collision and no replication

3rd answer: you may have noticed that the DGC schema presented here allows for multiple of all entries (in essence: array of ). This is because I have tried to design the DGC schema (1) in such a way that if regulations require (or allow) more than one entry per type, then there is no fundamental schema structure change, and (2) that the current regulation-conform implementation of only one entry can just be considered as an array of one element.

So this 3rd answer touches once again on this whole mandatory / not-mandatory issue and regulations. The current schema allows us to conform to EU regulation, so that's the main criteria. It also allows for extension if / when needed (again, that Open-Closed Principle of "open for extension, closed for modification) - the 'O' in SOLID. The absolute final say on what is valid for (i) the EU and (ii) a given member state can be applied in the "business rules" part of the processing (presentation I haven't yet given to eHN, so can't share it here, at least for now)

[martin-lindstrom]

OK, thanks Gaby.

[gabywh]

One other: the eHN Vacc Interop doc in Annex 2 specifes UVCI format, but unfortunately suggests three options (@kruzikh : 2 of which are "with semantics" ;) and doesn't state which of the three options is preferred / recommended / mandated.

It does, however, state:

The different options presented below are available to Member States and other parties and can co-exist among different Member States. Member States can even deploy different option in different version of the UVCI schema. The UVCI should clearly allow distinguishing which option is applied in a given Member State

Only I do not see any field explicitly stating which option (the nearest is a version field, which isn't the same thing). Option 1 ("Option 1 - identifier with semantics") would be my choice, but that's my opinion rather than an approved formal statement from eHN. I'll follow up internally to see if I can get clarification.

[jschlyter]

IMHO, if the ID would refer to the entire DGC, it should be located in the root. The ID of a specific vaccination/test/recovery item would be placed in the entry itself. As the UVCI applies to the entire DGC, it should be placed in the root.

If we at a later point would be allowed to store multiple vaccination/test/recovery entries, it makes even more sense to put the UVCI in root in order to minimize duplicated data on each entry (since the UVCI is for the entire DGC anyway).

[gabywh]

As the UVCI applies to the entire DGC

No, it most definitely does NOT. Please see above.

[sondaica]

@gabywh Regarding the answer about that only the last vaccination (only one) should be in the certificate. It´s not clearly stated in the regulation that it should be that way what we can see. It states that the date should be for the last dose. But since we have vaccination information in the certificate and we have people that has been vaccinated with two different vaccines what should then be presented in the certificate? If it is a maximum of one dose in the certificate then it should state that all the other vaccine fields as the last dose also. This would also lead to interesting validation if countries not approve certificate with a specified vaccine that is not approved in the validating country but in the issuing country. As we have intepreted the regulation it is up to the validating country to decide what is ok as long as the own citizen is treated in the same way as other MS citizen. How can the validation then be done if the issuing country has used one approved and one not approved vaccine for the validating country?

[jschlyter]

As the UVCI applies to the entire DGC

No, it most definitely does NOT. Please see above.

If the UVCI does not apply to the entire DGC we could - in theory - have a DGC with two vaccinations, each with a different UVCI. I'm fine with that as well.

Also, when the DGC is reissued I assume the UVCI is stable across DGCs?

[kruzikh]

Good point @gabywh regarding the UVCI. There is currently no possibility (as far as I know) how to express which option has been used. At the other hand, the only requirement is that UVCI must be globally unique for each certificate. Saying that, it is not necessary to understand its semantic content. Internal structure of the certificate is just a method how to ensure its uniqueness. All other information is included inside the certificate itself. Option 1 (which was proposed before the other two type of the certificates appeared), is applicable only to the vaccination certificate while the other two can be used for any type of certificate.

I see following options:

1. leave it as it is, despite the fact that we are not exactly inline with the eHN guidelines - but it will not pose operational problem
2. include UVCI option into the certificate schema version (element ver = 1.0.1 - for UVCI option one, 1.0.2 - for UVCI option one, etc.)
3. add one more attribute into the schema, e.g. opt = {1,2,3}
4. add option code into UVCI - would need approval by eHN

I would vote for option 1 or (if necessary) for option 3. Other options are either complicated or not elegant.

[kruzikh]

I agree that it would be elegant to allow information about all doses in one certificate. And I was pushing for that, however, final decision was that vaccination certificate will include information about last dose only (regulation does not explicitly specify this but this interpretation prevailed). It was also agreed that each QR code will include only one certificate.

[sondaica]

@kruzikh For the citizens and the validators one certificate with all the vaccinations in one QR code is much easier and more user friendly than the fact that you need to show two different codes to the boarder police to be able to show that both doses are with a vaccin that are approved in the validating MS.

[martin-lindstrom]

@sondaica But if you have a certificate for your second dose - will anyone be interested in your first dose?

[sondaica]

@martin-lindstrom Yes, you might be. Since one MS might not approve a certain vaccine, or that you might need to be fully vaccinated to enter a country. As I have understood there is a differens in the immunization percentage and it differs quite much between different vaccines. So 1 dose of one vaccine with low immunization percentage and dose 2 with another vaccine don´t end up with the same immunization percentage of two dozes of the second vaccine. So if you aren´t interested in the vaccine that you have been vaccinated with then the information regarding vaccine might not be there at all. Then we only need dose number in the certificate but the vaccine information is there due to the fact that it differ between validators.

[gabywh]

1. EU regs clear: only last vacc cert. That can be debated (and it was!) but that is how the proposed EU regs now stand.
2. Vacc Type:
   1. Within EU, vacc type should already be from a list agreed amongst member states so no real business need for it (although detecting forgeries may be a good use case here)
   2. 3rd countries
      1. To the EU zone: the vacc type must be on an approved list for entry to the EU (as above)
      2. From the EU zone: the vacc type must be available for checking by country of destination to see if it is on their approved list (been the same for as long as vaccine checks have been in place for entry to certain countries, so nothing new here in fact)

[jschlyter]

I suggest we close this issue so we can move forward. Multiple vaccinations, tests and recoveries are allowed at a later point we'll need to set the UVCI on all of them or change the schema to a new major version.

[gabywh]

Schema works as-is for all cases. The business rules used for generation of the QR code will be the final determiner of exactly what goes into the DGC Schema container. Thus business rules need to be in accordance with EU legislation, DGC JSON schema must be able to support those rules.