User should be re-authenticate his FV

[sirpy]

Whitelisting expires after authenticationPeriod set in the identity smart contract
on the client side he will be automaticallysent to do FV once he claims and his auth has expired
the server should handle two cases

1. user FV record was already deleted by cron
2. user FV still exists

if user record marked as isVerified it means user is doing FV for second+ time in that case:

• if enrollment exists then do /match-3d between incomming and current enrollment, if no match or livesness fail return error no match/liveness failed
• if enrollment doesnt exists then enroll facemap
• perform FV search -> if > 1 records matches at score 10 return duplicate error
• if enrollment doesnt exists add to search index
• if no issues then if re "authenticate" or "whitelist" user in smart contract

[serdiukov-o-nordwhale]

@sirpy @omerzam
On the last call we discussed what to do if auth period was passed and used was un-verified but enrollment isn't removed yet. How to prevent it to be removed a) during and b) after re-verification.

The pt. b) is solved by #288 because after success FV we're removing any disposal tasks related to that enrollment id and creating the new one with the Date.now as createdAt (so it'll we executed in a 2 weeks)

About issue a). We have a 'locking' feature in the DelayedTask model. So we could 'lock' a task for identifier we enrolling during FV flow running and then unlock it:

1. remove isVerified check, do FV always in verificationAPI
2. make _unlockRunningTasks public, rename it to unlockDelayedTasks, make tasksSucceeded param optional (default null).
   if tasksSucceeded isn't a boolean, set updated tasks status to Pending:

await taskModel.updateMany(
        { status: Running, _id: { $in: tasksIdentifiers } },
        { status: isBoolean(tasksSucceeded) ? (tasksSucceeded ? Complete : Failed) : Pending, lockId: null }
      )

3. before start FV call

const tasks = await fetchTasksForProcessing(DISPOSE_ENROLLMENTS_TASK, { 'subject.enrollmentIdentifier': enrollmentIdentifier }`

4. if FV fails call

if (!isEmpty(tasks)) {
  await unlockRunningTasks(map(tasks, '_id'))
}

The better place to implement it is EnrollmentSession (onEnrollmentStart / onENrollmentFailed method)
No need to unlock task on success as the old task will be removed and re-added in that case

[sirpy]

@serdiukov-o-nordwhale why not just remove all subject.enrollmentIdentifier and at the end of the process if enrolmment exists or successful we restore the delete task.

task with executeAt 'account-delete' is ok to completely remove.

[serdiukov-o-nordwhale]

why not just remove all subject.enrollmentIdentifier and at the end of the process if enrolmment exists or successful we restore the delete task.

it's already done as i described above. we need also to make sure enrollment won't be removed during re-verification

[serdiukov-o-nordwhale]

updated v9 PR with the re-verification flow: 2e6f547

now i'm adjusting the tests

for the case the match wasn't successfull (e.g. another person tries to enroll his face) i propose do not show the retry screen. i return isEnrolled: false for that case so the error screen will be shown immediately client-side. We could also to add a new flag isMatched and show the separate screen (Sorry it's seems you're trying to verify not own account) for that case

[serdiukov-o-nordwhale]

added isNotMatch status

[serdiukov-o-nordwhale]

updated PR: #293

[iLystopad]

@sirpy The error screen with the "Your face doesn't match the snapshot from the previous verification" message is displayed after trying to pass the face verification by another person.

Checked on the QA 1.24.1-6
Device: Desktop / Windows 10 / Google Chrome 89.0.4389.90

Attachment: https://www.screencast.com/t/wtbXBTb2Mr