Trust Progression — Unknown, Known & Verified States

Overview

Every user starts somewhere on a trust progression. ID Dataweb's workflows move users through four states — unknown, known, verified, and trusted — and different workflows handle different transitions.

flowchart TD
    U([<b>Unknown User</b>])
    K([<b>Known User</b>])
    V([<b>Verified Identity</b>])
    T([<b>Trusted User</b>])

    U --> IDV[<b>Identity Verification</b>]
    K --> IDB[<b>Identity Binding</b>]
    IDV --> V
    IDB --> V
    V --> TA[<b>Continuous Re-Authentication</b>]
    TA --> T

---

Unknown → Verified

An unknown user has no prior record anywhere in your system. Identity Verification takes them from unknown to verified in a single workflow. The user provides their own identity data, which is cross-referenced against authoritative sources. On approval, a verified identity is established and the user's device is bound to that credential.

Typical use cases: New customer onboarding, KYC/CIP, new account creation, HR-to-IAM provisioning for new hires.

→ Identity Verification

---

Known → Verified

A known user already exists in your system — their identity data is on file via HR, an identity governance system, a directory, or a prior account creation. Being known is not the same as being verified. Identity Binding takes a known user and confirms that the person in front of you actually matches the account on file. Their existing profile is the benchmark — the user must match it, not simply prove who they are in isolation.

This distinction matters for security: a fraudster can submit their own real identity data, pass every verification check, and still be attempting to take over someone else's account. Identity Binding closes that gap.

Typical use cases: MFA enrollment after account creation, employee re-verification, password reset, step-up verification for high-privilege access.

→ Identity Binding | → Identity Proofing vs. Identity Binding

---

Verified → Trusted

Once a user is verified, Continuous Re-Authentication manages ongoing re-authentication. Rather than applying the same challenge every session, it evaluates each session against multiple risk dimensions — the user's role, device, real-time session signals, behavioral patterns, and the sensitivity of what they are accessing. Trusted users pass through seamlessly; elevated-risk sessions receive a proportional challenge or are blocked.

Typical use cases: Risk-based re-authentication, account recovery, call center authentication, ongoing session trust for verified users.

→ Continuous Re-Authentication

---

Which Workflow to Use