Overview

Identity Verification — NIST IAL2 establishes a verified identity for users who are entirely new to your system and require a NIST SP 800-63A-4 IAL2 level of assurance — no prior account, no existing data. This is the Unknown → Verified transition in the Trust Progression Model.

The workflow leads with low-friction name, address and phone matching. Users whose attributes are confirmed present one FAIR and one STRONG piece of evidence: their phone account and a government ID. Users whose attributes cannot be confirmed are stepped up automatically. They are asked whether they hold a REAL ID-compliant driver's license; if they do, they verify with that one document, validated against the issuing state through AAMVA. If they don't, they verify with two government IDs. Every path ends in a single document capture session with a selfie.

The user's verified identity is linked to a credential, and the devices used during proofing — the desktop browser and the mobile device used for document capture — can be trusted credential, enabling frictionless re-authentication in Continuous Re-Authentication.

Level of Assurance

NIST SP 800-63A-4 IAL2, delivered as remote unattended proofing. There are three paths:

• Phone path: one FAIR piece (phone account) plus one STRONG piece (government ID).
• REAL ID path (Strong+): one STRONG piece (REAL ID-compliant driver's license) validated with the issuing source through AAMVA.
• Two-document path: two STRONG pieces (two government IDs).

At IAL2, remote unattended proofing requires ownership verification of every piece of presented evidence. The phone path combines two verification pathways: the Digital Evidence Pathway for the phone account and the Biometric Pathway for the government ID. The REAL ID and two-document paths use the Biometric Pathway alone, with the selfie compared against the portrait on each document presented.

User Friction Level

• Phone path: Low to medium — one form, one SMS interaction, one document capture.
• REAL ID path: Low to medium — one form, one yes/no question, one document capture.
• Two-document path: Medium — two document captures.

End User Requirements

Phone path: a mobile line with a carrier account confirmable in the user's name, ability to receive SMS, one government-issued photo ID that qualifies as STRONG evidence, and a device with a camera.

REAL ID path: a REAL ID-compliant driver's license or ID card issued by a state that participates in AAMVA validation (45+ states), and a device with a camera.

Two-document path: two government-issued photo IDs that qualify as STRONG evidence, and a device with a camera. The phone is used only as a delivery channel here and carries no assurance weight.

Speed

About one minute for the phone and REAL ID paths. Two to three minutes for the two-document path.

Use Cases & Fraud Prevention

• Federal and state agency online services whose digital identity risk assessment returns an initial IAL2 selection under the SP 800-63 Digital Identity Risk Management process.
• Regulated onboarding where an IAL2 claim is contractually required by a relying party.
• Any use case where a user is unknown and a verified identity must be established from scratch at IAL2.
• Fraud prevention: synthetic identity, basic evidence falsification and theft, document fraud, impersonation, digital injection and forged-media attacks. On the REAL ID path, AAMVA validation confirms the license data matches the issuing state's record, which catches altered or counterfeit licenses that pass visual inspection.

How It Works

flowchart LR
    Start([User begins]) --> Consent[Consent + Session Risk<br/>Passive risk, bot detection]
    Consent -->|High risk| Deny([Denied])
    Consent -->|Passes| PII[PII Validation<br/>Name-to-phone + name-to-SSN<br/>+ attribute validation]
    PII -->|Validated + mobile| OTP[SMS OTP<br/>6-digit code to validated number]
    PII -->|Validated + desktop| Phone
    OTP -->|Code returned| Phone[1 FAIR + 1 STRONG<br/>Phone Possession + Gov ID and Selfie]
    PII -->|Not validated| RID{Real ID availability<br/>Do you have a REAL ID?}
    RID -->|Yes| Plus[Strong+<br/>REAL ID + DMV Validation + Selfie]
    RID -->|No| Two[Two STRONG<br/>2x Gov ID + Selfie]
    Phone -->|Pass| Approve([Verified])
    Plus -->|Pass| Approve
    Two -->|Pass| Approve
    OTP -->|Not returned| Deny
    Phone -->|Fail| Deny
    Plus -->|Fail| Deny
    Two -->|Fail| Deny

Consent + Session Risk. An explicit collection notice is presented and consent captured, including separate informed consent for biometric collection and use. Device fingerprint, network signals, and automated-attack indicators are assessed silently. High-risk sessions — TOR, flagged or blocklisted IPs, velocity violations, bot signals — are denied before any user input is collected. This step collects no evidence.

PII Validation. The user submits their name, address, and phone number. This step does three distinct jobs off one call:

1. It validates all core attributes against authoritative or credible sources. This is an independent IAL2 requirement and applies on every path.
2. It confirms the presence of the user's account with the mobile network operator, establishing name-to-phone. Since a phone account has no physical document to inspect, this attribute confirmation with the carrier is the approved validation method for treating the account as FAIR evidence.

Phone path

Confirming the carrier and bureau records establishes that the number belongs to the claimed identity. It does not establish that the person in the session holds it. Ownership verification is a separate, required step, and how it is delivered depends on where the session started:

• Mobile session: the user goes to SMS OTP. A 6-digit code is sent to the validated number and entered in session, after which capture continues on the same device. A user who cannot return the code is denied.
• Desktop session: the user goes directly to the document step. A single-use capture link is sent by SMS to the validated number. Tapping the link returns the confirmation code and moves capture onto a device with a usable camera in one action.

Both mechanisms satisfy the Digital Evidence Pathway method for FAIR evidence: returning a confirmation code delivered to a validated digital address associated with the evidence. The phone number is locked read-only from PII Validation onward, so the number that was validated is the number that receives the code.

1 FAIR, 1 STRONG: Phone Possession + Gov ID and Selfie. The user captures a government ID and a selfie. The document is authenticated against its physical security features with live capture and document presence checks, and the MRZ or barcode is compared to the printed data for consistency. The selfie is compared biometrically to the document portrait, verifying the STRONG piece under the Biometric Pathway.

Step-up paths

Real ID availability. A short screen that asks the user whether they have a REAL ID. Yes routes to Strong+; no routes to Two STRONG.

Strong+: REAL ID Driver's License, DMV Validation, Selfie. The user captures their REAL ID-compliant license and a selfie. The document is authenticated the same way as on the phone path, and the license data is then validated against the issuing state's record through AAMVA. The selfie is compared biometrically to the license portrait.

Two STRONG: 2x Gov ID + Selfie. Two government IDs are captured and authenticated independently, and the selfie is compared biometrically against the portrait on each document.

Evidence Summary

What Gets Established on Approval

On a successful verification, the device and browser can be bound to the user's credential. A returning user on a trusted device with clean session signals can be approved with no challenge.

Integration: Gateway (OIDC)

Standard OIDC flow. See Gateway (OIDC) Integration. Routing between the phone, REAL ID, and two-document paths, and between in-session code and link delivery, is handled automatically by the hosted UI — your application receives a single authorization code regardless of which path the user took.

Step-by-step Setup

• Navigate to the Workflow page in the Admin Console.
• Click Add Workflow, select Identity Verification — NIST IAL2, name it, and deploy.
• Configure asyncUIRedirect — required for all document capture paths.
• Confirm the phone attribute is locked read-only after PII Validation.
• Confirm confirmation code lifetime is set to 10 minutes or less.

Related Resources

→ Trust Progression Model | → Identity Binding | → Continuous Re-Authentication | → PII Validation | → Government ID and Selfie Match | → Gateway (OIDC) Integration