Compare what each proofing method really proves

Setup

You need the patients and schema from the What proofing establishes lab, Mia's inbox from the Establishing an identity lab, and the toolkit. Choose a second plus-address for Mia, such as [email protected].

1. On this lab page choose Lab Photos and press Start.

2. Authentication > Profile: turn on email change. Save.

3. Set the variables:

ISSUER=https://tenant-<id>.beyondthelogin.dev
SCIM="$ISSUER/scim/v2"
EXT='<lab-tmp-clinic-patient schema URN>'
MIA_EMAIL='[email protected]'
MIA_EMAIL2='[email protected]'

4. Get SCIM_TOKEN as in the What proofing establishes lab.

Planned walkthrough

These steps need a proofing service in the tenant (G34). They run for the resolved Alex Rivera.

1. Proofing: enable three routes, "document and selfie", "record check and mailed code", and "trusted referee", and set the lab-results level to require both validation and verification.

2. Route A: submit a sample license image and a short selfie video. Read the validation result (security features, expiry, issuer check) separately from the verification result (similarity score, threshold, liveness).

3. Submit a photo of a photo, then a prepared video fed straight into the capture. Liveness refuses the first as a presentation attack; the capture integrity check refuses the second as an injection attack.

4. Route B: an issuer record check by license number plus a one-time code mailed to the postal address already in Alex's patient record. The proofing record notes that the record check is strong validation and weak verification, and the mailed code supplies the verification.

5. Route C: Ben, holding a Proofing referee role, reviews the evidence Alex does have together with a statement from Alex's clinician, and records his decision. Audit shows Ben as actor.

6. Compare the three proofing records: the same level reached with different evidence, and the alternate route recorded.

Do today

1. Confirming an address: where the code goes decides what it proves. Sign in as Mia at $ISSUER/account and change her email to $MIA_EMAIL2. The code goes to the new address you just typed, and the account keeps the old address until you enter it. Enter it. Audit shows account.profile with reason email_changed.

Why it matters: receiving that code proves only that someone can read mail at an address they chose. A reset link sent to the address already on record, which you can try at /reset-password, connects the person to the record instead.

2. Checking records. Look up a patient by details only:

curl -s -G "$SCIM/Users" -H "Authorization: Bearer $SCIM_TOKEN" --data-urlencode "filter=$EXT:patientNumber eq \"P-48213\" and $EXT:dateOfBirth eq \"1990-04-12\"" --data-urlencode "attributes=id" | jq .totalResults

Expected: 1, for anyone who holds a token and those two details.

Why it matters: a record check is strong validation of the details and weak verification of the person. Anyone who knows Alex's details can submit them.

3. Signed data. Sign in as Ava through $ISSUER/token-decoder and keep the ID token with read -rs ID_TOKEN. Verify it, then copy it to another terminal or machine and verify it there too:

btl-lab verify "$ID_TOKEN" --issuer "$ISSUER" --audience <Token Decoder client ID from the token's aud> --type id --no-nonce

Expected: valid in both places.

Why it matters: like the data on a passport chip, an issuer signature shows origin and integrity. It does not show who is presenting it, or whether the issuer has since withdrawn it.

4. Comparing a face.

Simulation. the tenant has no face comparison (G34), so this step uses sample similarity scores. Each pair is one comparison; genuine pairs are the same person, impostor pairs are not.

Pick a threshold, then count false matches (impostors at or above it) and false rejections (genuine pairs below it). Try 0.60, 0.70 and 0.80. Then choose the fallback route for the genuine applicant your threshold rejects.

Why it matters: any threshold allows some false matches and rejects some real people. A service using face comparison needs another route, not a permanent rejection.

5. Comparing the methods. Fill in the lesson's comparison for the three things you tested today: what each mainly supports, validation or verification, and its common weakness.

Break it

1. Today: start another email change for Mia and enter a wrong code. The tenant answers that the code is not correct or has expired, and the address does not change.

2. Planned (G34): submit an expired license with a face that matches. Validation fails although verification passes, and the route is refused.

Check your work

This lab is planned, so it has no automated checks. In Audit, look for:

• tenant.authentication.update succeeded (email change turned on, and later off).

• account.profile succeeded with reason email_changed, and a rejected account.profile for the wrong code.

• scim.users.search succeeded for the record check.

Cleanup

1. As Mia, change her email back to $MIA_EMAIL.

2. Authentication > Profile: turn email change off.

3. Delete the three patients and the schema. Deleting the schema deletes its stored values.

for u in alex1 alex2 alexandra; do
  id=$(curl -s -G "$SCIM/Users" -H "Authorization: Bearer $SCIM_TOKEN" --data-urlencode "filter=userName eq \"[email protected]\"" | jq -r '.Resources[0].id')
  curl -s -o /dev/null -w '%{http_code}\n' -X DELETE "$SCIM/Users/$id" -H "Authorization: Bearer $SCIM_TOKEN"
done

Then delete lab-tmp-clinic-patient on Schemas, and run unset ID_TOKEN.

Missing infrastructure

• G34 Identity proofing. The tenant has no document capture or validation (including chip signature checks), no liveness or one-to-one face comparison, no postal delivery to an address on record, no referee workflow with its own permission, and no proofing record per route. Once these exist, the planned walkthrough compares the three routes for real. Until then, the lesson's comparison table can be tested only for address confirmation, record checks and signed data.