The Digital Agency issued a request for public comments on vaccine passports, so I submitted a response. The following is a copy, preserved here for the record.

Thank you for compiling a concise specification in such a short time.
(For Overseas Travel)

  • For overseas travel, ICAO rules are expected to become globally accepted, so I support their adoption.
  • For acquisition, OCR reading is assumed, but in practice the passport IC chip can also be read relatively easily. This also permits signature verification and acquisition of the facial photograph as data. I believe this is actually convenient for both users and verifiers.

(For Domestic Use)

  • I was favorably impressed that the domestic version is also Smart Health Card (SHC)-based, showing consideration for international standards.
  • However, several points concerned me, as described below.
  • Unlike the overseas version, whose keys can be obtained from ICAO, the domestic description did not explain where to obtain the key used to verify the SHC or how to confirm the issuer’s legitimacy. For the U.S. SHC, I assume this is separately specified as a trust framework. This document, as the specification for implementation in Japan, therefore also needs to clarify this point. I hope that anyone will be able to obtain the signer list and keys.
  • SHC uses Verifiable Credentials (VCs), but does not define a Verifiable Presentation. It therefore cannot provide selective disclosure of attributes, often cited as a benefit of VCs. Consequently, all information contained in the two-dimensional barcode is always given to the store. Full disclosure for overseas travel poses fewer problems because use at border control is assumed. For domestic use, however, information would be presented to an unspecified and potentially large number of recipients, which is undesirable.
  • Furthermore, because there is no information such as a facial photograph linking the information to the physical person, a vaccination certificate can be lent to someone else. The resulting options appear to be either 1) expecting it to function as social pressure on unvaccinated people while overlooking its inability to prove vaccination at actual stores, or 2) ensuring effectiveness by simultaneously requiring photo identification. European countries apparently use one or the other approach. The latter naturally creates a larger problem of excessive disclosure.
  • This excessive attribute disclosure problem is common to both the U.S. SHC and Europe’s Digital Green Certificate (DGC). Presumably, each was designed as a lowest-common-denominator standard in light of diverse regional circumstances—or more specifically, on the assumption of paper.
  • In Japan, however, because a My Number Card is mandatory, a more effective solution could be provided to the target population. A facial photograph, which is information printed on the card, could be extracted from the IC chip and stored with the vaccination information under a signature, thereby linking vaccination information to physical-person information.
  • The information would be encoded and delivered to recipients such as stores according to the situation. When both presenter and recipient have network connectivity, a Self-Issued OpenID Provider (SIOP) approach being considered by ISO/IEC JTC 1/SC 17 and the U.S. DHS could be used (method 1). When only the recipient has network connectivity, an NFC or QR code could convey a one-time access code and the location where the information is stored, from which it could then be retrieved (method 2). When neither party has network connectivity, there is no alternative, so a fallback that abandons facial-photo verification could be provided (method 3). With these methods, in most cases it should suffice to provide only {facial photograph, vaccine name, vaccine validity start date, issuer, issue date, issuer signature}.
  • This would avoid providing names, dates of birth, and lot numbers that could become supercookies when combined with them. Providing a facial photograph should have little privacy impact because the person is physically present. Authentication of the verification client and a list of legitimate clients would nevertheless be necessary.

(Vaccination Information Acquisition API)

  • A vaccination voucher number and date of birth are certainly convenient, but depending on the implementation, this appears to require users to enter a potentially sensitive date of birth into a reservation site. There is no authentication at all in this arrangement, so what is the security target? Depending on the circumstances, the objective might be achieved using the voucher number alone.
  • If this assumes the certificate with a two-dimensional code described above, more reliable information provision should be possible by using something like method 1 above.

(Overall) I was impressed by the great concision of these materials, but the following points remain unclear.

  • List of stakeholders (health authorities, the individual, stores, etc.)
  • Stakeholder concerns
  • Security objectives (detect presentation by someone other than the individual, verify the issuer, detect tampering, etc.)
  • Privacy assessment (for example, whether additional information is provided that can be used to distinguish individuals on grounds other than whether they are within the vaccine validity period, beyond what was originally provided for the service)

If these matters had been described, I believe I could have offered more appropriate comments. I would be grateful if they could also be compiled when the final version is issued.

Related posts