3.2 Azure AI Face Service
Key Takeaways
- Azure AI Face provides detection, verification (1:1), identification (1:N against a PersonGroup), grouping, find-similar, and liveness detection.
- Pair detection_03 with recognition_04 for the highest accuracy; detection_03 also returns blur, mask, and head-pose attributes.
- Verification and identification are Limited Access features requiring an approved Microsoft intake form before they are enabled on a resource.
- A PersonGroup must be retrained after any face add/update/delete, and a detected faceId is valid for only 24 hours before it expires.
- Microsoft retired emotion, age, gender, smile, hair, and makeup attributes in 2022-2023; the exam tests that these are no longer returned.
Quick Answer: Azure AI Face does detection (find faces + attributes), verification (1:1 — are these two faces the same person?), identification (1:N — who is this against a PersonGroup?), find-similar, grouping, and liveness (live person vs. spoof). Verification and identification are Limited Access and need Microsoft approval; emotion/age/gender attributes are retired.
Face Detection
Detection returns a face rectangle, up to 27 facial landmarks, an optional faceId, and selected attributes. The detection and recognition models you choose drive accuracy.
Detection models
| Model | Strength | Notes |
|---|---|---|
| detection_01 | Legacy; supports the broadest set of attributes | Weaker on small/rotated faces |
| detection_02 | Better on small, side, and blurry faces | No attributes |
| detection_03 | Highest accuracy; returns blur, mask, head-pose | Recommended for production |
Recognition models
| Model | Use |
|---|---|
| recognition_03 | Good general recognition |
| recognition_04 | Highest accuracy; better with masks — use for verification/identification |
from azure.ai.vision.face import FaceClient
from azure.ai.vision.face.models import (FaceDetectionModel,
FaceRecognitionModel, FaceAttributeTypeDetection03)
from azure.core.credentials import AzureKeyCredential
client = FaceClient(endpoint, AzureKeyCredential(key))
faces = client.detect(image_content=img_bytes,
detection_model=FaceDetectionModel.DETECTION03,
recognition_model=FaceRecognitionModel.RECOGNITION04,
return_face_id=True, return_face_landmarks=True,
return_face_attributes=[FaceAttributeTypeDetection03.HEAD_POSE,
FaceAttributeTypeDetection03.BLUR,
FaceAttributeTypeDetection03.MASK])
On the Exam: The "highest accuracy" answer is almost always detection_03 + recognition_04. A returned
faceIdis usable for only 24 hours, then it expires — code that caches faceIds for later identification is a classic bug the exam plants.
Verification (1:1) vs. Identification (1:N)
- Verification compares exactly two inputs and returns
is_identicalplus a confidence. Default decision threshold is roughly 0.5; KYC and access-control flows often raise it. - Identification searches one face against a trained PersonGroup (or PersonDirectory / LargeFaceList) and returns ranked candidates.
res = client.verify_face_to_face(face_id1=a, face_id2=b)
print(res.is_identical, res.confidence)
PersonGroup Identification Lifecycle
The order of operations is a guaranteed exam item.
| Step | Call | Note |
|---|---|---|
| 1. Create group | create_person_group(id, recognition_model=...) | Recognition model is fixed at creation |
| 2. Add person | create_person_group_person(group, name) | Returns a personId |
| 3. Add faces | add_person_group_person_face(...) | Several images per person raise accuracy |
| 4. Train | train_person_group(group) | Required after any add/update/delete |
| 5. Identify | identify(face_ids=[...], person_group_id=group) | Returns ranked candidates |
results = client.identify(face_ids=[unknown_id], person_group_id="employees")
for r in results:
if r.candidates:
print(r.candidates[0].person_id, r.candidates[0].confidence)
If you skip step 4 after adding faces, identification returns stale or empty results — the symptom many exam scenarios describe.
Liveness Detection (anti-spoofing)
Liveness proves the input is a live human, not a photo, screen replay, or deepfake. It runs from a mobile/web SDK that produces a short session token the backend validates.
| Mode | What it does | Best for |
|---|---|---|
| Passive liveness | Analyzes one capture for spoof artifacts; no user action | Frictionless onboarding |
| Active liveness | User performs a prompted motion (blink, turn) | Highest assurance |
| Liveness with verification | Liveness check + matches the live face to a reference photo | Remote identity proofing |
On the Exam: A scenario where someone holds up a printed photo to fool sign-in is solved by adding liveness detection — not by raising the verification threshold or adding emotion detection.
Limited Access and Retired Attributes
| Feature | Access | Status |
|---|---|---|
| Face detection / landmarks | Open | Available |
| Verification & identification | Limited Access | Submit Microsoft intake form first |
| Liveness | Limited Access | Approval required |
| Emotion, age, gender, smile, hair, makeup | n/a | Retired (2022-2023 Responsible AI) |
Limited Access means a new resource cannot call verify/identify until the registration form is approved; SDK calls fail with an authorization error until then. The retired demographic and emotion attributes are simply no longer returned by any detection model — if an option lists "emotion" as a current Face attribute, it is wrong.
Worked Example
A bank onboards customers remotely. Use liveness with verification: the mobile SDK captures a liveness session, the backend confirms the session is genuine, then verifies the live face against the photographed ID using recognition_04. Because verification and liveness are Limited Access, the bank must complete the intake form before the resource will process these calls.
Find Similar and Grouping
Beyond the headline operations, two utility calls show up in exam distractors. Find Similar takes one face and returns the most visually similar faces from a candidate list or LargeFaceList, ranked by similarity — useful for de-duplication or "have we seen this person before" without a labeled PersonGroup. Group takes a set of unknown faces and clusters them into groups that likely belong to the same person, returning a messyGroup for faces it cannot confidently cluster. Neither identifies who a person is; they only measure similarity.
If a scenario says "organize a photo library so each person's shots are grouped, but we have no labels," the answer is Group, not Identify, because Identify requires a trained PersonGroup of known people.
Confidence Thresholds and False Matches
Verification and identification both return a confidence between 0 and 1, and your application — not the service — decides the cutoff. Microsoft's guidance ties the threshold to risk tolerance: a low-security photo-tagging feature can accept around 0.5, while access control or financial KYC should demand a higher confidence (often 0.8 or above) to suppress false accepts, accepting that more legitimate users will be asked to retry.
A frequent trap pairs a complaint about impostors getting in with the wrong fix ("add more training faces"); the correct response to false accepts is to raise the confidence threshold, whereas false rejects of genuine users point to adding varied enrollment images or improving capture quality.
What is the difference between Face verification and Face identification?
You add several new face images to a PersonGroup, then identification calls return no matches. What step was most likely skipped?
Which Face API features did Microsoft retire as part of its Responsible AI commitments?
For the highest face recognition accuracy on a production identity-verification system, which model combination should you choose?