is the SVC meant to only represent a single vaccination event? Or can an SVC be produced for more than one vaccination event as is often done today with paper records? I could not find any language around this cardinality question.

Does the existence of the SVC for a subject in itself evidence of (COVID-19) vaccination? Or is there an expectation that the certificate is nothing more than an immutable and verifiable document intended to carry evidence of vaccinations for COVID-19 and that it is up to the verifier to assess that the SVC does indeed contain the required vaccine(s) to determine acceptance? This is not stated and it has material impact to how a verifier might verify and how an issuer might issue.

Is there an expectation that issuers will only 'write' onto the SVC COVID-19 vaccinations? if so, what prescribes that scope of those vaccines where we are in an age where a new vaccine could be created and an existing one could be removed. i would propose that instead of saying 'proof' that it says 'certifies' that the stated vaccine(s) have been administered to the subject.

Who are the 'traditional' verifiers? The concern with COVID-19 credentials is that we are contemplating a net new set of verifiers - not your traditional verifiers. They may not accept a paper based visual inspection and the WHO cannot dictate the zeal of the new verifier. There is substantive ramifications for fraud with the legacy paper-only model that isn't waht the new verifier community wants to accept - hence why we are looking to do this in the first place. This paragraph should set a better context by letting us know the new verifier and the new levels of proof they want. This document doesn't define these new actors.

it's difficult to look at this diagram without comparing it to a model using W3C DID and a ledger. The verifiers are going to know to interconnect to the local/regional PHA then it asserts that the UVCI is still valid (presuming that it could be voided or cancelled, revoked) and that call requires a call to a centralized (within the jurisdiction) PHA service, potentially processing millions of SVC verifications a day, and punting the international ones to a foreign PHA when it's not resolved locally. So the PKI repo only distributes PKI but does not distribute the revocation or validity of the UVCI? This architecture is daunting and the coordination required to create this PHA network is huge. Does the architecture contemplate a network of PHAs within a single country, or what the term Int PHA just meant to convey not the local PHA? Is there a discovery protocol contemplated for resolving to the PHA?

Again, who are the verifiers? Do they understand ICD-11? I agree we should codify the data so machine computation can occur without risk of error, but that is a requirement of the verifier, not the issuer. Issuers will issue what they know and likely leave the mapping of their code system to the verifiers code system as an exercise of the verifier. In Canada, we will likely offer the vaccine identity as a standard DIN and if that isn't satisfactory for the verifier then they can map the DIN to their code system of favour. It should not be the responsibility of the issuer to provide a myriad of code systems codes for the unanticipated verifier. ICD-11 is likely feasible for most but in Canada it's not our native code for drugs/vaccines. The WHO might do well to offer a codification mapping service that verifiers can reach and relieve this burden from the issuer.

Which is it? Barcode or 2D (aka QR Code). This is material to know whether this analog twin is meant to hold data or just a reference to the data? Not recommending putting the data into the 2D code, but rather point to the data.

The github link provided is broken. Is this supposed to be part of the review? I do not need the usefulness of structuring the data as HL7 FHIR, simple JSON would suffice, or define a simple model inspired by HL7 FHIR. Again, the target audience of verifiers may largely be non-health care entities. Introducing them to the semantics of HL7 FHIR is superfluous and meta-data heavy.

Why is this paragraph even here? All this is not in scope nor is it material knowledge to comprehend how one might offer a SVC to a holder.

Do you have an example of these open standards? Do you consider Canada's DIN code to be proprietary for the purposes of vaccine identification? It's a national coding requirement for drugs and vaccinations in Canada, so I would not consider a DIN to be proprietary. But please elaborate on the ramifications.. again we are postulating that verifiers - those non health care entities will need to understand the codes of health concepts. An ICD-11 code is as alien to an airline as a Canadian DIN code is, so what is the point of standards here? I'd favour human readable over codification, and allow jurisdictions to use their own codifications regardless whether the WHO deems them proprietary. the PHA is responsible for making available the proofs to the holder for the subject. They are not responsible for the comprehension of said proof by the myriad verifiers beyond human readable content.

PII is not just about the subject. You've asked for PII about the health worker, and I am making the case that the general verifier would have not way of knowing the authenticity of that PII, so as per your minimization, exclude it.

Why even touch on this potential rabbit hole? I can't even grasp what this is trying to imply. SMS addresses equity challenges? How so? You've piqued my interest in this tangent. Is there some reference to works you could add here?

I don't understand this statement? A verifier wishes to verify a proof and they need to interact with their local national PHA to do so? Is that what this says? How does that work if the SVC contains only a URI to the verifiable data set and not the payload as data? Or has this been the working assumption all along that the 2D barcode contain the data? And then, f so, how does that align to the principle of privacy and data protections?

Canada will most likely codify the vaccine using their standard DIN numbers. PHAs will follow suit. It's worth directing this to the verifier stakeholders to understand the code systems used throughout the world for them to know what is a COVID vaccine.

Do not recommend collecting this element. The proof of vaccine is NOT an identity (document) as stated in this draft, so why collect non-clinical gender as part of the person's identity? Remove Sex.

Do not agree with this data element. The issuer is PHA, not the health worker. The health worker need not be involved in any attestation of this proof, nor should they offer their PI as part of this proof. This data element is untenable in many jurisdictions and in particular during mass immz events. This is a naive assertion. How is a verifier to evaluate the authenticity of this data element? Short answer they can't.. so why collect it and make is mandatory for paper form? Paper is simply a different medium of the digital proof so why bother? This data element has no value.

Batch is more often referred to in health care as the Lot number, if we mean the same thing here? If so recommend the term Lot number over Batch Number. In fact you would refer to it as lot number in HL7 FHIR as suggested as the model.

Verification is limited to whether it was signed? What about revocation? What about assignment of vaccine records in error that are later reconciled and the outcome of which is assignment of a vaccine proof to the correct subject whilst revoking the assignment to the original subject? This does not seem contemplated here.

By the PHA.. this won't fly. the PHA would have little interest in offering a privacy enhanced version. Rather, with SSI it would be best to allow the user the efficacy to produce their own selective disclosure. Do not agree this is the responsibility of the PHA.

Out of scope, no relevant to the core topic of proof of vaccination and makes gross assumptions of work flows.

I cannot agree that this data element is useful. Who is the verifier and how would they know to evaluate the accuracy of this information? What about the health worker's right to privacy? This information is superfluous and zero utility for a proof to be share globally. Delete it.

'not an identity... document?' what links the identity document to the SVC? You have person name and dob.. and identity number in the data set. I.e. 3 points to link. No mention of a crypto link between subject and vaccine proof?

Format perhaps, but to suggest out of scope is content is a bit perplexing. You have a data set and you have a set of privacy principles. It would seem that the content could be inferred by those two aspects of this paper. I.e. privacy might mean the QR itself does not contain the data or if it does is protected some way.. a little deeper insight into the intent of the QR would be useful.

I said it earlier , the continuity of care is an altruistic goal, a goal being solved within some jurisdictions in spite of SVC. I'd rather this document stay laser focused on proof of vaccination as its only goal.

Does this flexibility include the use/adoption of W3C DID-spec and a ledger such as Sovrin? Can we also add to this flexiblity the means to offer SSI and selective disclosure? Do we have to use the PKI repo when its not relevant when adopting that tech?

This principle again enforces why you would not encode the data into the QR as has been suggested using various compression algorithms to fit into the 7k size.

I cannot endorse the use of HL7 FHIR to represent the core data. Most vaccine cards today have about 4 fields.. What, who, when and why (disease), and due date for next booster. Wrapping that in FHIR is META-heavy for no value. The verifiers are largely outside of the medical profession and would have little interest in needing to unpack FHIR's meta heavy syntax. A simple JSON structure with jursidicatonal control over codification is all that is required. The only code would be drug (vaccine) and perhaps disease (ICD?) Nothing more. ISO for dates, etc. Use of FHIR is overkill and doesn't align to the target audience of the vaccine proof .

Some of the proposed data elements are not universally feasible nor is the intended use clear for some of the fields. From a need to know basis the WHO proposed data goes beyond what is possible or practical. More comments on the specifics later. I would offer that the WHO describe the minimum data set for usefulness from the vantage point of the key stakeholder - the verifier.

Not agreeing this needs to be in scope. It's a bit altruistic and not material to the generation and management of a proof of vaccination.

This principle alone would be violated if the data were to exist on its own in the QR code, especially in the paper based form.

Scope creep? Could this paper stay focussed on the concept of proof of vaccination? This comes up time again as the paper discusses the IHE architecture that (presumably) leads to the generation of the actual proof.