Biometric consent for BIPA, CUBI and Colorado

Illinois (BIPA), Texas (CUBI) and Colorado require a notice and an explicit release before a business collects face geometry, from a selfie or from the photo on an ID. Didit can show a consent step before the first face capture to the people those laws cover, and keeps the answer on the session as evidence. This page explains when the step appears, which apps can show it, and how the answer reaches your decision and webhooks.

Didit shows the step and records the answer. You decide whether your user journey meets the biometric laws that apply to your business. This page is not legal advice: review your implementation with your counsel.

When the step appears

A session shows the consent step when both of these are true:

The workflow captures a face. A Liveness, Face Match or Age Estimation step, the front-camera selfie the ID Verification step takes (unless you turned it off), or full-session video recording.
The application’s consent mode asks for it. In Auto mode, one of the triggers below applies. In Always mode, every session that captures a face asks.

The step appears before the first face capture. When only the ID document shows a covered state, it appears right after the ID capture and before the selfie, and no face geometry is computed from the ID capture images until the person agrees. Didit checks the requirement when the person opens the flow and again at each step until it applies. Once a session requires consent, it keeps requiring it. Choose the mode in the console, under the application’s Settings > Data and privacy > Biometric consent. Each change is recorded in the audit log.

Mode	What happens
Auto (default, recommended)	Shows the step only where a trigger applies. Everyone else sees the standard one-line notice.
Always	Every person whose face is captured sees the step, wherever they are. The decision records `trigger: "forced"`.
Never	Didit never shows the step. Where state law requires consent, you collect it yourself before the selfie and keep the record.

What triggers the step in Auto mode

Didit checks these rules in order and records the first one that applies in biometric_consent.trigger:

Trigger	When it applies
`declared_state`	You declared a covered state when creating the session: `user_state`, or a US address in `expected_details`.
`ip_state`	The person’s IP is located in Illinois, Texas or Colorado.
`ip_unknown`	The person looks to be in the US (a US IP, a US document, or US details you sent) but their state cannot be told: the IP is in the US with no state, or cannot be located while your details or the document place the person in the US.
`document_issuer`	The identity document read at ID capture was issued by a covered state.

VPNs, proxies and hosting networks do not ask on their own. Didit locates the person’s IP like any other: one in Illinois, Texas or Colorado shows the step, one anywhere else does not. The step is asked only on clear evidence of a covered state (the IP, the state that issued the ID, or a state you declared), or when the person is placed in the US without a state (ip_unknown). A person in a covered state behind a VPN that exits elsewhere, with an ID no covered state issued, is not asked; use Always mode, or send user_state, if you need to cover that case. Two more values describe how a session’s consent was settled rather than why it was asked:

Trigger	Meaning
`forced`	The application’s mode is Always.
`customer_collected`	You sent consent you had already collected when creating the session (see below).

Tell Didit what you already know

Create Session takes two optional fields for this:

Field	What it does
`user_state`	Where the person lives, when you know it: an ISO 3166-2 subdivision code (`US-IL`, `ES-M`) or a US state code or name (`IL`, `Illinois`). A covered state shows the step with `trigger: "declared_state"`. An unknown value returns `400`.
`biometric_consent`	Consent you already collected: `{ "given_at": "<ISO 8601>", "text_version": "<your version id>" }`. The flow does not ask again, and the decision records `status: "given"` with `trigger: "customer_collected"`. `given_at` cannot be in the future.

{
  "workflow_id": "YOUR_WORKFLOW_ID",
  "vendor_data": "user-42",
  "user_state": "US-IL",
  "biometric_consent": {
    "given_at": "2026-10-13T09:12:00Z",
    "text_version": "consent-v3"
  }
}

Which apps show the step

The step needs an app that can display it. Didit decides this on every request the app makes:

Where the person verifies	Shows the step
The hosted verification flow: a browser, the Web SDK, or a WebView	Yes
Native SDK 4.10.0 or later (iOS, Android, and React Native or Flutter releases that bundle native 4.10.0 or later)	Yes
A native SDK below 4.10.0, or one that does not report its version	No

Native SDKs below 4.10.0

Native SDKs released before 4.10.0 do not know the consent step, so Didit never asks them for it. The verification runs exactly as it did before: the selfie and the other face captures are accepted and processed, and the session reaches its decision as usual. Didit never records consent that was not given. When the session required consent and an older SDK captured a face, the decision shows:

"biometric_consent": {
  "required": true,
  "trigger": "ip_state",
  "status": "pending",
  "given_at": null,
  "reason": "BIOMETRIC_CONSENT_UNSUPPORTED_SDK"
}

Upgrade to native SDK 4.10.0 or later if you verify people in Illinois, Texas or Colorado in a native app. Until you do, those sessions finish without explicit consent, and collecting it before the selfie is your responsibility.

If the person continues the same session in the hosted flow (on another device, or in a WebView the app opens for some liveness types), the hosted flow shows the step and captures no face there until they answer. Consent given there keeps reason: "BIOMETRIC_CONSENT_UNSUPPORTED_SDK", because faces were already captured without it.

What the person sees

The step tells the person what is collected, why, who has it and how long it is kept, and links to the Biometric data policy. It has one button: Agree and continue, which stays disabled until the person ticks the agreement box. Didit keeps the answer as evidence: when it was given, the version and hash of the text shown, the language, the workflow step, and the IP, location and user agent of the request. Once the person agrees, the answer is final.

When the person does not agree

The step has no decline button. A person who does not want to agree leaves the flow: no face is captured, and the session ends as Abandoned like any other session the person does not finish (see Verification statuses). Offer them another way to verify. The decision keeps a declined status and the BIOMETRIC_CONSENT_DECLINED reason as API values. No Didit screen offers a decline today, so the hosted flow and the native SDKs do not record one. A session that records a decline:

Ends as Declined, and the status.updated webhook fires as for any other decline.
Shows biometric_consent.status as declined, reason and decline_reason as BIOMETRIC_CONSENT_DECLINED, and declined_at with the time.
Captures no face after the decline. Every face image and face template the session already holds is deleted: selfies, the ID capture’s front-camera selfie, the face crop of the document portrait, liveness and full-session videos. face_data_deleted_at records when. The decision no longer returns them, and the deletion is irreversible.
Keeps the document images and the data read from them: the decline does not affect them.

In the decision and webhooks

Every User Verification decision carries a biometric_consent object, in Retrieve Session and in the decision of session webhooks. It is null when the session was never evaluated, for example a workflow without a face capture.

`status`	Meaning
`not_required`	The session did not require consent.
`pending`	Consent is required and was not given. Read `reason` to tell an older SDK from a person who has not answered yet.
`given`	The person agreed in the flow, or you sent `biometric_consent` at creation.
`declined`	A decline was recorded, and the session ended as `Declined`. No Didit screen offers a decline today (see above).

`reason`	Meaning
`BIOMETRIC_CONSENT_UNSUPPORTED_SDK`	A native SDK below 4.10.0, or one that did not report its version, captured a face without the step.
`BIOMETRIC_CONSENT_DECLINED`	A decline was recorded. No Didit screen offers a decline today.
`null`	Nothing to explain. Always `null` when the session did not require consent.

A session where the person agreed in the hosted flow:

"biometric_consent": {
  "required": true,
  "trigger": "declared_state",
  "status": "given",
  "given_at": "2026-10-13T18:31:07.412000Z",
  "declined_at": null,
  "text_version": "bio-consent-2026-10-12",
  "locale": "en",
  "policy_url": "https://didit.me/legal/biometric-data-policy",
  "step": "LIVENESS",
  "ip_address": "198.51.100.23",
  "ip_country_code": "ES",
  "detected_ip_address": "198.51.100.23",
  "detected_country_code": "ES",
  "jurisdictions": ["IL"],
  "retention_months": 36,
  "reason": null,
  "decline_reason": null,
  "face_data_deleted_at": null
}

The example is shortened. Every field, with its type, is in Data models.

Create Session: user_state and biometric_consent.
Retrieve Session: the decision that carries biometric_consent.
Native SDKs: versions and upgrade steps.
Security and compliance: your responsibilities in verification flows.

Overview

Pricing

Workflows & Verification

Review & Operations

Entities (Users & Businesses)

Settings & Customization

Security & Compliance

Didit Academy

Resources

Biometric consent for BIPA, CUBI and Colorado

When the step appears

What triggers the step in Auto mode

Tell Didit what you already know

Which apps show the step

Native SDKs below 4.10.0

What the person sees

When the person does not agree

In the decision and webhooks

​When the step appears

​Consent modes

​What triggers the step in Auto mode

​Tell Didit what you already know

​Which apps show the step

​Native SDKs below 4.10.0

​What the person sees

​When the person does not agree

​Declined consent in the API

​In the decision and webhooks

​Related

When the step appears

Consent modes

What triggers the step in Auto mode

Tell Didit what you already know

Which apps show the step

Native SDKs below 4.10.0

What the person sees

When the person does not agree

Declined consent in the API

In the decision and webhooks

Related