Closed chris2286266 closed 3 years ago
jschlyter
commented
3 years ago Note that the hcert can contain both vac, tst and rec at the same time. You can be vaccinated and tested (this may become even more important if mutations are not covered by all types of vaccin).
chris2286266
commented
3 years ago Hi, is that so?
If someone is vaccinated, this is valid/relevant for e.g. 6-12-24 month (or how long the vaccination is defined as "safe", e.g. because of mutations). If someone is tested, the validity of the test is something like 48/72 hours or maybe one week - depending on the usecase and/or the country. Same for "recovered" - there is a certain period, after which the "recovered" status is invalid, e.g. 180 days.
So is it really senseful, to put the data for up to 3 complete different usecases (with complete different validity dates) into one document (=hcert)?
Maybe we need some medical/virological expertise to answer this questions?
Cheers, Chris
dirkx
commented
3 years ago Best to discuss this with @gcangioli and @gabywh - as they are expert on this. I suspect that this metadata is for the certificate(DGC) itself - and does not pertain to the X.509 or the subsections.
gabywh
commented
3 years ago In general: use of vacc cert is already well-established for travel and medical use cases, has been in place for a long time already. Secondary re-purposing for travel e.g. within EU as a preventative means of trying to stop covid-19 spreading sits on top of that.
Data: i. yes/no for private venue and travel -> provide a conclusion statement and no facts (type of vacc is sth that is needed for certain cross-border scenarios, but this need not be revealed directly to person checking for a yes/no validity) ii. medical -> to provide an abbreviated statement of medical facts and no conclusions, thus the complete opposite of (i)
From this, I can see there is a clear argument for splitting medical from private venue / travel in terms of generating documents. What we have right now in NL in prototype is actually 3 separate QR docs, one per use case as above. Pros and cons for both options (all in one doc, one doc per use case). That said, things to get unclear again when you consider that a vaccination certificate in and of itself can be used for the travel case (particularly non-EU) - as is currently the paper-based case (e.g. yellow booklet).
Combining different validity dates into one doc: if your goal is overall to present a yes/no conclusion, then no reason why differing validity dates for different kinds of proof cannot be combined in one document and one algorithm. A couple of examples:
| Test negative | In Recovery | Vaccination Valid | Yes/No |
|---|---|---|---|
| No | No | No | No |
| No | No | Yes | No |
| Yes | No | No | Yes |
| No | Yes | Yes | Yes |
and all the combinations thereof.
What is important here is the status of each of the fields at the time of verfication.
gabywh
commented
3 years ago 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?
Yes, is what we currently have in the NL prototype version
chris2286266
commented
3 years ago ok, thanks for your input.
The currently defined certificate metadata includes fields like
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?