Agenda:

https://github.com/biometricITC/cPP-biometrics/wiki/iTC-Meeting-Agenda-2021-01-28

Call started at 10:00 am EST

Attendees

• Brian Wood
• Greg Ott
• Naruki Kai
• Clare Olin
• Jon Rolf

Record of Decisions

• None at this time

Action Items

• Brian will review some of the older pull requests and then merge https://github.com/biometricITC/Administration/pull/24

Minutes

The call started with a quick review of the Task List. There were no updates. It was noted that the first fingerprint review period would end next week and so would be the first topic of the next call. No comments had yet been received.

The call then started with a review of the CMFA pull requests. Brian mentioned that Naruki had made a large pull request that filled out the document well and that he thought this should be accepted as the next version of the document after a review of the previous comments on earlier versions (and making sure those comments were sufficiently included in the update). Everyone agreed this was acceptable given the changes.

A quick review was then made on the pull requests about the use case and definition edits. Brian said he would review that these were covered in #24 and then once edited (if needed) he would close these PRs and delete the branches.

The call then moved to the open issues around CMFA. The first topic was about signal verification. Brian opened the discussion by pointing out that the question was whether signal verification was required for CMFA or not, comparing it to the optional PAD for the biometrics. It was agreed that this is probably needed, but the concern Naruki raised is about how much testing can be done (based on the amount of time needed). The group agreed that signal verification is needed, but there are still questions about exactly how to handle the testing for it, based on the type and number of sensors.

The next topic as CMFA FAR/FRR. Brian reviewed the question and pointed out that the question is how to provide quality/performance metric similar to a FAR/FRR number. The GitHub discussion raised questions about the fusion of two biometric scores, but wasn't as clear about other sensors. It was pointed out that most other sensors should be fairly binary (a yes/no answer about the sensor), though this isn't always the case. Brian also pointed out that the CMFA as a whole is what we would want a metric of though, not the individual components, so how could such a score be determined based on all the information collected, not just the biometrics? The group decided to mark this for future review as an optional requirement.

The last CMFA topic reviewed was about CMFA and initial authentication. The question is whether a CMFA TOE should be available and running when the device starts or if it should launch after the initial authentication (with an expected score of 100 because of password entry) and then maintain the state after that.

It was pointed out that having the TOE take over later could lead to issues in race conditions, though it was thought that this probably wouldn't be an issue since the password entry should allow access under any conditions (though it was pointed out that maybe this wouldn't be the case in all deployments). Since the point of CMFA is to maintain a score about the user identity, this could be used to block access except under certain circumstances, or possibly restrict access to some apps until conditions are met. This may be useful for future requirements.

Claire asked if the TOE should always be running since someone using MFA for the initial login should score higher than just a password, and wouldn't that be useful (but maybe not known in the case where the TOE isn't available until after the login. It was agreed then that the TOE must be designed such that it runs during all authentication events, including the initial device authentication (i.e. after a reboot).

The next call will be on February 11.

The call ended at 11:02am EST.