Identity Binding

Overview

Identity Binding establishes a verified identity for users who already have an account or profile in your system. This is the Unknown → Verified transition for known users in the Trust Progression Model.

The critical difference from Identity Verification: the user must match the account they are claiming — not just prove who they are. Their existing profile data is prefilled from your system and used as the verification benchmark. A fraudster using their own valid identity data will fail the account match even if they pass all other checks.

The flow is identical to Identity Verification, with two additions: the Session Risk step is used for user discovery (capturing the identifier needed to retrieve the user's data), and that data is prefilled into the PII Validation step automatically. The user does not fill in their own identity data.

On approval, the user's verified identity is linked to their credential, and both their devices — the desktop browser and the mobile device used for SMS Link — are fingerprinted and bound to that credential for future Continuous Re-Authentication sessions.

Level of Assurance

Medium-High to High — same as Identity Verification.

User Friction Level

Low — user provides only an identifier (username or email). All PII is prefilled. Document path applies for users who cannot be corroborated via carrier data.

End User Requirements

Ability to receive SMS; government-issued photo ID if routed to the document path.

Speed

Seconds for the phone path. 1–2 minutes for the document step-up.

Use Cases & Fraud Prevention

Account recovery — password reset, locked account, MFA re-enrollment.
HR → IAM birthright provisioning — verify an employee matches their HR record before granting access.
Known user verification — confirm identity before granting elevated privileges.
Prevents account takeover via identity impersonation: a bad actor who presents their own valid identity data will fail the account match.

How It Works

flowchart LR
    Start([User begins]) --> SR[Session Risk<br/>User discovery + data prefill]
    SR -->|High risk| Deny([Denied])
    SR -->|Passes| PII[PII Validation<br/>Prefilled from account data]
    PII -->|Match| FT[SMS Link<br/>Device possession check]
    PII -->|No match| Bio[Government ID and Selfie Match<br/>Document + selfie step-up]
    FT -->|Confirmed on mobile| Approve([Verified])
    FT -->|Not confirmed| Deny
    Bio -->|Pass| Approve
    Bio -->|Fail| Deny

Session Risk + User Discovery: Passive risk assessed silently. The user provides an identifier — typically username or email — which is used to retrieve their account data. Three methods are available for how that data reaches ID Dataweb (see below). High-risk sessions are denied before any data is processed.

PII Validation (prefilled): The user's name, address, and phone are populated from their account record — the user does not enter this data themselves. ID Dataweb cross-references this against carrier records and authoritative databases. The match must succeed against the account data, not just against any valid identity.

SMS Link: Same as Identity Verification — one-time SMS link sent to the user's registered phone. Must be tapped on mobile.

Government ID and Selfie Match (step-up): Same as Identity Verification — triggered when carrier data cannot corroborate the identity. Document and selfie are matched against the account's claimed name.

How Account Data Gets Prefilled

ID Dataweb supports three methods for injecting existing account data into the workflow. All three are available on the Gateway (OIDC) integration. For API integrations, your backend fetches and passes the data directly.

Login Hint — your application encodes the user's profile data as a signed JWT and passes it in the login_hint parameter of the OIDC /authorize request. The data is prefilled before the workflow begins. Best when your application has the user's profile in session and can sign a JWT.

Federated Login — ID Dataweb acts as an OIDC relying party to your existing identity provider. The user authenticates with their existing credentials first; the resulting identity claims are mapped as workflow inputs. Best when the user already has a username and password with your IdP.

Data Bridge — the user provides an identifier at the Session Risk step (username, email, employee ID), and ID Dataweb calls a configured external API to retrieve the full profile. Best when profile data lives in an existing SaaS directory or custom API.

→ See Identity Proofing vs. Identity Binding for full detail on each method.

What Gets Established on Approval

On a successful verification, two things are bound to the user's credential:

Desktop device — the browser fingerprint collected during Session Risk is registered against the credential.
Mobile device — the phone used to complete SMS Link is fingerprinted and registered as a trusted device.

On future sessions via Continuous Re-Authentication, these fingerprints are recognized. A returning user on a trusted device with clean session signals is approved with no challenge.

Configuration Options

Template Variations

Session Risk (username mode) + Data Bridge → PII Validation → SMS Link or Government ID and Selfie Match (default for known-user flows)
Session Risk (country mode) + Login Hint → PII Validation → SMS Link or Government ID and Selfie Match
Federated Login → Session Risk (autosubmit) → PII Validation → SMS Link or Government ID and Selfie Match

Optional Add-ons

Same add-ons as Identity Verification: SIM Swap detection, Email Risk, Persistent ID (LexID), KBA step-up.

Integration: Gateway (OIDC)

Standard OIDC flow with one of the three data injection methods configured. See Gateway (OIDC) Integration. The prefill is transparent to the hosted UI — the PII Validation form is pre-populated and not editable by the user.

Step-by-step Setup

Select a data injection method (Login Hint, Federated Login, or Data Bridge) and configure it for your workflow.
Configure Session Risk for username or autosubmit mode depending on the method.
Configure asyncUIRedirect for the document capture path.

Configuration Options — Gateway-specific

📝
Content coming soon.

Integration: ID Dataweb API

Same chain as Identity Verification. Your backend fetches the user's profile data from your own system and passes it as userAttributes in the PII Validation /slverify call — the user is not asked to enter data you already have.

See PII Validation, Government ID and Selfie Match, and API Authentication for code samples and field-level documentation.

Configuration Options — API-specific

📝
Content coming soon.

Testing in Preproduction

Same test credentials as Identity Verification. To test the account-match aspect, use Andrew Roshell data as the "account record" and submit mismatched PII to verify the match fails.

Scenario	Input	Expected Result
Phone path — approve	Andrew Roshell prefilled, tap SMS link	`approve` via phone match
Account mismatch — deny	Different name against Andrew Roshell's phone	`deny` — account match fails
Document step-up — approve	PII fail → Andrew Roshell + Passport	`approve` via document

Related Resources