Identity Proofing vs. Identity Binding

Two Modes of Verification

ID Dataweb supports two fundamentally different verification use cases. Understanding which one applies to your situation shapes how you configure your workflow, how data flows into the system, and what a successful result actually means.

	Identity Proofing	Identity Binding
Who is the user?	Unknown — no prior record	Known — has an existing account or profile
Goal	Establish a verified identity from scratch	Confirm the person in front of you matches a specific existing account
Typical context	New customer onboarding, KYC, account creation	Password reset, MFA enrollment, high-privilege access, step-up
Data source	User provides their own data	Account profile is the reference — user must match it

Identity Proofing

Identity proofing applies when a person is entirely unknown to you. You have no prior record of them. The goal is to verify that they are who they claim to be so you can establish a trusted identity record.

Example: A customer applies for a credit card. Your company has no existing data on this person. They provide their name, address, phone number, and a government ID. ID Dataweb verifies that this person is real, the identity is consistent, and the documents are authentic. On approval, you now have a verified identity to anchor their account to.

In this mode, the user provides all the data. ID Dataweb verifies it against authoritative sources and returns a decision. Your application uses that decision to create an account, grant access, or complete onboarding.

Identity Binding

Identity binding applies when the user already exists in your system and you need to verify that the person attempting access is genuinely the account holder — not just a person who can pass verification on their own.

The security risk this solves: Verification alone is not enough for known users. A fraudster can submit their own real identity data, pass every verification check, and still be attempting to take over someone else's account. If your system only checks "is this person verified?" without checking "does this person match this specific account?", that gap is exploitable.

Identity binding closes that gap by confirming two things simultaneously:

The person is who they claim to be (verified identity)
The verified identity matches the account they are accessing (account match)

Example: An employee needs to re-enroll in MFA after getting a new phone. They log in and trigger a step-up verification. ID Dataweb receives that employee's existing account data — name, address, phone — and runs the verification against it. The employee doesn't type in their own data; their profile data is the benchmark they must match. A bad actor who provides their own real identity data will fail the account match even if they pass verification.

The Known-User Data Problem

For identity binding to work, ID Dataweb needs the existing account's data to match against. This raises a practical question: how does that data get into the verification flow?

There are two broad approaches:

Gateway (OIDC): ID Dataweb provides three built-in mechanisms to inject account data into the workflow automatically. The user does not need to fill in a form — their profile data is retrieved from your systems and used as the reference. ID Dataweb then handles the matching.

API: Your application retrieves the user's profile data from your own systems and passes it directly as userAttributes in the /slverify call. The user is not asked to enter data you already have; your backend supplies it.

In both cases, the value is the same: you do not need to build comparison logic yourself. ID Dataweb receives the account's reference data and the verification evidence, and performs the match — purpose-built for this use case.

Gateway: Three Methods for Injecting Account Data

Login Hint

Your application passes the user's existing profile data to ID Dataweb via the login_hint parameter in the OIDC /authorize request. The data is encoded as a signed JWT and prefills the workflow inputs automatically.

When to use: Your application has the user's profile data in session and can form a signed JWT or make an API call to retrieve it at the time of the /authorize request.

→ See Login Hint for configuration details.

Federated Login

ID Dataweb acts as an OIDC relying party to your existing identity provider. The user authenticates to their existing account first — via your IdP — and ID Dataweb receives the resulting identity claims. Those claims are mapped directly as inputs to the verification workflow.

When to use: The user already has a username and password with your IdP, and you want them to authenticate to that account first before being verified. This is especially effective for workforce use cases where employees have existing directory credentials.

→ See Federated Login for configuration details.

Data Bridge

The user asserts an identifier (username, email, etc.) — or it is prefilled — and ID Dataweb calls a configured external API using that identifier to retrieve the user's full profile. That profile is then used as the verification inputs.

When to use: User profile data lives in an existing SaaS directory or custom API that ID Dataweb can call. This avoids the need to build a custom JWT or set up a federated OIDC connection — just configure an API endpoint and field mapping.

→ See Data Bridge for configuration details.

Choosing the Right Approach

Situation	Recommended approach
New user, no prior record	Identity Proofing — any workflow; user provides their own data
Known user, your app can supply profile data at auth time	Identity Binding — Gateway with Login Hint
Known user, user has existing credentials with your IdP	Identity Binding — Gateway with Federated Login
Known user, profile lives in an external API or SaaS directory	Identity Binding — Gateway with Data Bridge
Known user, API integration	Identity Binding — API; your backend fetches profile data and passes it as `userAttributes`

Related Resources