NIST IAL2

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 phone-based identity matching and automatically steps up to dual-document capture for users whose carrier account cannot be confirmed. Both paths satisfy a listed IAL2 evidence combination: the phone path presents one FAIR and one STRONG piece of evidence, the document path presents two STRONG. Most users complete the phone path in about a minute. The document path ensures coverage for everyone else.

On approval, 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 — are fingerprinted and bound to that credential. These device fingerprints enable frictionless re-authentication in Continuous Re-Authentication.

Level of Assurance

NIST SP 800-63A-4 IAL2, delivered as remote unattended proofing.

• Phone path: one FAIR piece of evidence (phone account) plus one STRONG piece (government ID).
• Document path: two STRONG pieces (two government IDs).

At IAL2, remote unattended proofing requires ownership verification of every piece of presented evidence, not only the strongest. The phone path combines two verification pathways: the Digital Evidence Pathway for the phone account and the Biometric Pathway for the government ID. The document path uses the Biometric Pathway alone, with the selfie compared against the portrait on both documents.

User Friction Level

Low to medium for the phone path — one form, one SMS interaction, one document capture. Medium for the two-document path.

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.

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 path. 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. SIM swap and recycled-number detection are configured on the PII Validation step (see Configuration Options).

How It Works

flowchart LR
    Start([User begins]) --> SR[Consent + Session Risk<br/>Passive risk, bot detection]
    SR -->|High risk| Deny([Denied])
    SR -->|Passes| PII[PII Validation<br/>MNO account + attribute validation]
    PII -->|Validated| Dev{Session<br/>device}
    PII -->|Not validated| Bio2[Government ID and Selfie Match 2x<br/>2 STRONG]
    Dev -->|Desktop| Link[Single-use capture link<br/>sent to validated number]
    Dev -->|Mobile| Code[6-digit OTP sent to<br/>validated number]
    Link --> Bio[Government ID and Selfie Match<br/>1 FAIR + 1 STRONG]
    Code --> Bio
    Bio -->|Pass| Approve([Verified])
    Bio -->|Fail| Deny
    Bio2 -->|Pass| Approve
    Bio2 -->|Fail| Deny

Consent + Session Risk. 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 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, phone number, and a government identifier. This step does two distinct jobs off one call:

1. It validates all core attributes, including the government identifier, against an authoritative or credible source. This is an independent IAL2 requirement and applies on both paths.
2. It confirms the presence of the user's account with the mobile network operator. 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.

A confirmed carrier account routes to the single-document path. Anything else — no carrier match, name mismatch, prepaid line with no proofing at issuance — routes to the two-document path.

Possession of the phone account. Confirming the carrier account 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:

• Desktop session: 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.
• Mobile session: A 6-digit code is sent to the validated number and entered in session, after which capture continues in the same context.

Both mechanisms are confirmation codes 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 this point, so the number that was validated is the number that receives the code.

Government ID and Selfie Match (phone path). 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.

Government ID and Selfie Match 2x (document path). For users whose carrier account cannot be confirmed. 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 so that on future sessions via Continuous Re-Authentication, these fingerprints are recognized. A returning user on a trusted device with clean session signals can be approved with no challenge.

Configuration Options

Template Variations

• Phone match → single document (default), with two-document fallback on carrier failure
• Two-document only — for populations where carrier coverage is poor or where a single unambiguous pathway is preferred

Optional Add-ons

• SIM Swap detection on the PII Validation step — confirms the number has not been recently ported to a new user or device. Particularly important on the phone path, where the phone account is load-bearing evidence.
• Email Risk on the PII validation step
• Device, account tenure, or velocity checks on the PII Validation and/or Session risk steps.
• Persistent ID (LexID) — stable cross-session identifier on approval

Integration: Gateway (OIDC)

Standard OIDC flow. See Gateway (OIDC) Integration. Step-up routing between the single- and two-document paths, and between link and in-session code 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 both document capture paths.
• Confirm the phone attribute is locked read-only on the single-document service.
• Confirm confirmation code lifetime is set to 10 minutes or less.

Integration: ID Dataweb API

Steps chain via forwardApiKey. The /slverify response after the PII Validation step signals which path applies — single document (carrier account confirmed) or two documents (not confirmed). See PII Validation and Government ID and Selfie Match for detailed API reference.

sequenceDiagram
    participant App as Your Application
    participant IDW as ID Dataweb API
    participant User as End User

    App->>IDW: POST /token (apiKey:secret)
    IDW-->>App: access_token

    App->>IDW: POST /slverify (Session Risk key)
    IDW-->>App: forwardApiKey₁

    App->>IDW: POST /slverify (PII Validation key + name, address, phone)
    IDW-->>App: forwardApiKey₂ + obligation (1 doc or 2 doc)

    alt Carrier account confirmed — 1 FAIR + 1 STRONG
        App->>IDW: POST /confirmation-code/send (validated number)
        IDW->>User: Capture link (desktop) or 6-digit code (mobile)
        User->>IDW: Returns code — phone account ownership verified
        App->>IDW: POST /async-ui/send-link (Government ID and Selfie Match key)
        User->>IDW: Captures ID + selfie
        App->>IDW: POST /slverify (Government ID and Selfie Match result)
    else Not confirmed — 2 STRONG
        App->>IDW: POST /async-ui/send-link (Government ID and Selfie Match 2x key)
        IDW->>User: Capture link
        User->>IDW: Captures two IDs + selfie, compared against both portraits
        App->>IDW: POST /slverify (Government ID and Selfie Match 2x result)
    end

    IDW-->>App: policyDecision (approve / deny) + pathways used

Step-by-step Setup

• Obtain an access_token — see API Authentication.
• Check the obligation field after the PII Validation step to determine which path to route.
• Pass transaction_id and credentialfrom the first response in all subsequent calls for session continuity.

Related Resources

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