iTC Meeting Minutes 2019 08 22 - biometricITC/cPP-biometrics GitHub Wiki

Agenda:

https://github.com/biometricITC/cPP-biometrics/wiki/iTC-Meeting-Agenda-2019-08-22

Call started at 10am EDT

Attendees

  • Brian Wood
  • Naruki Kai
  • Fiona Pattinson
  • Stephen Mueller

Record of Decisions

  • None on this call

Action Items

  • Naruki will edit the ESR based on option 2 as specified in Issue #186 which will then be sent to the broader group for review
  • Brian Wood will write a PAD methodology related to face biometrics between 2D and 3D

Minutes

The call started with a quick review of the task list (no changes).

The main topic of the call was a discussion about the AVA_VAN proposals included in Issue #186 and how we should approach the issue regarding the upcoming CCDB meetings. The three proposed options were discussed, and everyone generally agreed that option #3 was not likely to work within since it would run afoul of the CCRA (even if it makes BSI happy). There was a debate about using option 1, but the concern there is that it could potentially preclude the use of fingerprints at all since it is likely that no fingerprint sensor could pass the AVA_VAN testing.

There was a thought about whether we could use the sensor and how it is plugged into the device for the AVA_VAN focus instead of PAD, but it wasn't clear this would really get anything. It still didn't solve the issue of what to do about PAD, though the thinking was that this could possibly get to something closer to what BSI would want (where AVA_VAN could cover the components and how they are protected, and PAD would be optional and hence that AVA_VAN would be optional). This could work, moving the PP-Module back to a cPP, but would still require the ESR change of option #2 most likely.

The group decided overall that option #2 seemed to be the most likely path to a successful (and useful) solution. Based on a recommendation from NIAP, the ESR will be modified as we think it needs to be, and it will then be sent to the entire mailing list with a request for comments (along with our justification as to why we are doing this). While not an official ballot, it will be sent as one with a survey to gather the data and responses from members in advance of the CCDB meetings. The plan is to send this out next week (last week of August).

Brian then quickly reviewed the proposed PowerPoint for the ICCC session. He asked for comments and planned to make some edits to talk about the contents of the PP-Module (as opposed to just an overview of the group status since the presentation is a little lite right now). He planned to leave a slide blank as a placeholder for anything learned about the AVA_VAN from the CCDB meetings before the ICCC.

Brian then quickly showed the proposed changes to the CC Portal status. He will send this to NIAP to update after the call.

The final topic of the call was a discussion about 2D and 3D face testing. The question posed is whether there should be 2 separate toolboxes for face, one for each variation, of if these are one, but the applicability changes based on the specifics of the device. The related question is should there be overlap, where some 3D tests are run on 2D sensors and some 2D tests are run on 3D sensors.

Naruki pointed out that at EAL1 the evaluator technically doesn't know anything about the biometric, but Brian said that whether it is 2D-based or 3D-based would be stated by the vendor clearly, and we could go from that. Brian pointed out that his concern is trying to minimize duplicate tests for both, and so seeing this as one toolbox where the lab is instructed on which tests to run based on the type would make maintenance easier. Brian explained that his thinking is that the face should be treated as a spectrum of tests, going from the very basic 2D ones to the complex 3D ones. When a vendor specifies 2D or 3D, the set of tests would be chosen based on that selection. For example, if there were 10 classes of tests, where 1-6 are 2D-based and 7-10 are 3D based, a 2D sensor would have to have test classes 1-7 run, while a 3D sensor would have to have test classes 6-10 run (maybe 5-10, that could be determined). This way some basic (but less costly) 3D tests would still be done on a 2D sensor while the highest quality 2D tests would be run on the 3D sensor (since those would seem most likely to cause a failure).

Brian agreed to write this up for next week for review.

The next call will be in 2 weeks at the normal time.

The call ended at 11:05am EDT.