Concerns about the cert schema element

[martin-lindstrom]

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?

[jschlyter]

vr can be simply v in the root. Other than that I agree with @martin-lindstrom on all points.

[fredriklj]

+1, agree on all points.

[chris-baumann-at]

I can agree with version/v & id.

the validFrom and validUntil is NOT for the signing certificate but for the health data: e.g. for a recovery the validFrom would be the time of "medically detecting" the recovery and the validUntil some time maximum 180 days later (e.g as stated in the Regulation). Similar for test result, which is (medically) valid for e.g maximum 5 days.

type: the idea was, that applications can detect the type of the document without parsing/analysing the whole doc. and to allow subtypes for enhanced privacy e.g. a "vac-priv" type with reduced medical data only valid for e.g. entering restaurants ... but maybe this topic is too complex for now? so maybe remove the type for now ...

tell me your thoughts and i will be happy to change the schema and file a PR.

[jschlyter]

• vf is basically rec.dat or tst.dts. And vu is some overall expiry. I would consider adding this expiry data to each entry in tst and rec, basically expiring the validity of such a record. Once/if multiple dis are supported (which may be required if/when a string of COVID is classified as a new disease) this is even more important.

• The ty is not needed, as parsing the date is easy and quick, I suggest we remove it.

• v and id in the root makes sense.

[martin-lindstrom]

vu and vf are the same as issued-at (iat) and expires (exp) of the CWT. Those does not have anything to do with the signing certificate. They tell when the DGC was issued and for how long the DGC is valid. There is really no reason to include any other time stamps describing validity. It really doesn't make sense to issue a DGC valid for 60 days and in the payload try to state that the validity is shorter.

My suggestion is to remove the cert-element and move relevant parts (version, id) up one level. And for type maybe we could consider defining later on, if needed.

[chris-baumann-at]

Thanks for clarifying, i did not honor the CWT enough. I will make the changes and issue e PR asap.

[mariewallace]

Is there a plan to put human readable labels in the schema? For example; "BioNTech Manufacturing GmbH" instead of "EU/1/20/1528". Also, have you any plans for adding multi-lingual support to make ease of using credentials across language barriers?

[chris2286266]

No "long strings" in the data itself, because of the size. But the value sets are public so the apps can display human readable strings instead of the codes. Same should work for multi language.

[mariewallace]

The only issue with that is that it's then no longer verifiable. If there is no way of guaranteeing that the field being displayed in the app is identical to the field in the credential (that is tamperproof due to signing), it invalidates everything. And also, these don't need to be stored in the credential payload, but in the credential schema.

[mariewallace]

We've been exploring ways that a trusted meta-data service could be used to anchor mappings so they can be trusted. For both labels and values.

[dirkx]

We do have the maintained list at https://covid-19-diagnostics.jrc.ec.europa.eu/devices?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 which is the basis for tthis - and the translations of the identfiers to all the languages maintained. That is for test.

And for vacines we have https://ec.europa.eu/health/documents/community-register/html/ as the managed list.