iTC Meeting Notes 2019 03 14 - biometricITC/cPP-biometrics GitHub Wiki

Agenda:

https://github.com/biometricITC/cPP-biometrics/wiki/iTC-Meeting-Agenda-2019-03-14

Call started at 12pm EDT

Attendees:

  • Brian Wood
  • Naruki Kai
  • Nils Tekampe
  • Fiona Patterson
  • Stephanie Motre
  • Marcus Streets

Record of Decisions:

  • Pull requests 155 and 154 were quickly reviewed and merged into the larger item 151
  • By majority decision, pull request 151 was approved
    • Nils Tekampe objected to the acceptance of this iteration due to the inclusion of AVA_VAN.1

Action Items:

  • A note will be sent out to the entire iTC community as well as explicitly to the supporting schemes (and via Nils to BSI) about the current late draft cPP-module asking for review (Brian will send out the initial notice)
  • Stephanie will upload the rest of her face toolbox
  • Nils will send out a meeting invite for the next call on March 28, 2019 at 11am EDT (assuming no conflicting calls)

After a quick overview of the new toolbox repository edits, the iTC reviewed the first two PRs for the document updates Naruki provided a few weeks ago. Brian had made some edits to the documents which had already been approved for merge. They were quickly reviewed and then merged.

The primary discussion focused on the direction necessary to move forward regarding the inclusion (or not) of AVA_VAN.1 in the cPP.

Nils started by mentioning he had met with BSI since the last call and specifically spoke with them about the inclusion of AVA_VAN in the cPP. Their opinion is that no biometrics on the market today can pass an evaluation with AVA_VAN included, so they see it as a blocking factor. Either it is included and nothing can pass, or it isn't included so products can pass.

Stephanie then asked about the biometric evaluations being done by BSI, and Nils said there were a few, including voice modalities, but none are for mobile. Stephanie then pointed out that the biometric does not exist on its own but is part of a device with broader protections/settings, such as a restriction to the number of attempts that can be made. These limits also limit what can be done in an attack by limiting the ability to continue attacking.

This led to several discussions about the scope of AVA_VAN.1 as it is included in the MDFPP (or straight from CC Part 3) and whether the cPP could be accepted via mutual recognition without AVA_VAN (either from a Base-PP or directly included). The general determination of this discussion is that mutual recognition is a political decision by the CCDB, and that this specific topic has not yet come up (to the knowledge of anyone on the call).

The group in general feels that the AVA_VAN as currently described should be sufficient for in market products to meet the requirements. To try to move forward, Nils suggested moving the cPP-module back to a cPP which would allow for some additional flexibility in defining assumptions and threats (it may bring up other issues with Exact Conformance), but may be more amenable to BSI.

Brian proposed a two step process to accept the current set of documents and then to immediately move the cPP-module back to a cPP to follow this proposal and to then present this to BSI for comment. The group rejected this and suggested keeping the cPP-module since it is really targeted to embedded components, not stand-alone, and so being a Module makes it easier to combine with other PPs.

After some more discussion, the group decided on the following (with the goal being to have something that is "published" by the end of March):

  • Accept the current documents from Naruki with the PRs from Brian
  • Send this version of the document out to the entire iTC for review with a note about the inclusion of AVA_VAN and the concerns there-in
  • This version will be presented explicitly to BSI and the other supporting schemes for review
  • Naruki will work with Nils on reaching out to the correct PoCs in BSI to further discuss this directly

The goal is to have a cPP-module that is approved most likely by the end of the CCUF/CCDB meetings since it isn't yet clear that approval from schemes may occur before that based on this Proposed draft.

The call ended at 1:05pm EDT.