Principles, Scenarios and Suitability
Facial access systems must distinguish verification of a claimed identity from identification by searching a database. Biometric data is sensitive and cannot be replaced like a password. Assess less intrusive alternatives; do not infer ethnicity, health, emotion or other sensitive traits.
Verification asks whether an image matches the claimed person's record; identification asks whom it resembles across the database. Data scope and risk differ. A template represents features used for comparison but still needs protection because it relates to a person. High similarity does not prove identity, and converting data into templates does not remove sensitivity. Cards or staff checks may fulfil the purpose less intrusively.
A threshold determines a match. Stricter criteria reduce wrong acceptance but increase rejection of entitled people. Assess both at the same threshold, with a fair manual route when the system fails. Presentation checks are another task tied to a threat model, the specified risks. Do not claim ordinary cameras establish liveness or real-person presence in every situation.
Scroll the diagram horizontally to inspect all details.
Illustrative Design Scenario
Educational scenario: compare card-based checks with facial verification in an authorised environment. People whose matches fail have a staff-assisted alternative rather than being denied important rights or accused of impersonation on one score.
Suppose an authorised person fails matching because of lighting or angle. Staff should use the approved alternative, not allow unlimited retries or accuse them of being someone else. More light may help images but must suit the location and users. Non-biometric alternatives must preserve access rights under the rules, not penalise people whose matching fails.
Before proposing use, compare necessity with cards and staff procedures, assessing retention, deletion and revocation. Test with authorised data separate from real databases; do not connect other databases without a purpose. Any future facial function must be described as a study, not an installed or already compliant system.
Inputs and Prerequisites
Assess necessity, processing basis, notices, template retention and deletion rights. Use authorised test datasets and keep test databases separate from live operational records.
Define one-to-one comparison versus database search and who may enrol people. Data needs provenance and a limited purpose. Do not collect images elsewhere merely to enlarge the database without authorisation.
Results should mean match, no match or unreadable, with staff review available. Do not display trustworthiness, health or emotion scores. Event records should minimise biometric information and limit retention according to their role.
Trial and Integration Workflow
- 1Consider non-biometric alternatives first and define a limited purpose.
- 2Test verification with presentation-attack checks appropriate to the threat model.
- 3Provide human fallback and test revocation and data deletion procedures.
Evaluation and Acceptance Criteria
Evaluate false matches and false non-matches at the same threshold with uncertainty intervals. Check lighting, angles and devices without drawing conclusions about sensitive traits. Criteria must cover both admitting the wrong person and rejecting an authorised person.
A false match accepts a pair that should differ; a false non-match rejects a pair that should match. Report test counts and conditions. Few example pairs or public-dataset results cannot establish suitability for the actual location.
Have responsible parties test revocation, deletion and appeals in a test system. Acceptance requires someone accountable for personal rights, not merely a door opening once after a match response.
Scroll the diagram horizontally to inspect all details.
Failure Cases and Limitations
Similarity does not prove identity, and image checks do not establish liveness against every attack. Templates still carry personal-data risks. No customer deployment is confirmed here, and important access decisions need a human review route.
A leaked face cannot be changed like a password. Consider necessity and minimisation from the outset. Encryption helps in some respects but does not resolve excessive access permissions or inappropriate purposes.
Identity guidance is a design framework, not legal certification or product-readiness assurance. Limit use and provide reviewers. Do not expand access verification into personal tracking or inference of sensitive traits.
Practical Checklist
- Is necessity demonstrated against alternatives that avoid biometrics?
- Are human assistance and a way to challenge results available?
- Have revocation and template deletion actually been tested?