生物识别同意：BIPA、CUBI 与科罗拉多州合规

伊利诺伊州（BIPA）、德克萨斯州（CUBI）和科罗拉多州要求，企业在通过自拍照或身份证件上的照片采集面部几何特征之前，必须提供通知并获得明确授权。Didit 可以在首次采集人脸之前，向受这些法律管辖的人群展示同意步骤，并将答复保留在会话中作为凭证。本页介绍了该步骤何时出现、哪些应用可以展示该步骤，以及答复如何传递到您的决策和 Webhook 中。

Didit 负责展示该步骤并记录答复。您应自行决定您的用户旅程是否符合适用于您业务的生物识别法律。本页内容不构成法律建议：请与您的法律顾问一起审查您的实现方案。

何时显示该步骤

当以下两个条件均满足时，会话将展示同意步骤：

工作流采集了人脸。 活体检测、人脸比对或年龄估算步骤、身份证件验证步骤拍摄的前置摄像头自拍照（除非您已将其关闭），或全会话视频录制。
应用的同意模式要求显示该步骤。 在自动模式下，适用以下任一触发器。在始终模式下，每个采集人脸的会话都会要求提供。

该步骤出现在首次人脸采集之前。如果只有身份证件表明其属于适用州，它将在证件采集之后、自拍之前立即出现，并且在用户同意之前，不会根据证件采集图像计算任何面部几何特征。 Didit 会在用户打开流程时检查该要求，并在每个步骤再次检查，直到适用该要求。一旦某个会话需要同意，它将始终要求同意。

同意模式

在控制台中选择模式，路径为应用的 Settings > Data and privacy > Biometric consent。每次更改都会记录在审计日志中。

模式	执行逻辑
自动（默认，推荐）	仅在适用触发器时展示该步骤。其他所有人均看到标准的一行提示。
始终	无论身在何处，每个被采集人脸的用户都会看到该步骤。决策记录为 `trigger: "forced"`。
从未	Didit 从不展示该步骤。如果州法律要求同意，您需在自拍前自行收集并保留记录。

自动模式下的步骤触发条件

Didit 按顺序检查以下规则，并在 biometric_consent.trigger 中记录首个适用的规则：

触发器	适用条件
`declared_state`	您在创建会话时声明了受管辖的州：`user_state`，或 `expected_details` 中的美国地址。
`ip_state`	用户的 IP 位于伊利诺伊州、德克萨斯州或科罗拉多州。
`ip_unknown`	用户看起来在美国（美国 IP、美国证件或您发送的美国详细信息），但无法确定其所在的州：IP 位于美国但没有具体州，或者在您的详细信息或证件显示用户位于美国时无法定位 IP。
`document_issuer`	在证件采集时读取的身份证件由受管辖的州签发。

VPN、代理和托管网络本身不会直接触发要求。 Didit 像定位其他 IP 一样定位用户的 IP：位于伊利诺伊州、德克萨斯州或科罗拉多州的 IP 会显示该步骤，其他任何地方的 IP 则不会。仅在有受管辖州的明确凭证（IP、签发身份证件的州或您声明的州）时，或者当用户位于美国但没有具体州（ip_unknown）时，才会要求执行该步骤。如果受管辖州的用户使用了出口在其他地方的 VPN，且身份证件并非由受管辖州签发，则不会要求该步骤；如果您需要覆盖这种情况，请使用始终模式，或发送 user_state。还有两个值描述了会话同意是如何确定的，而不是为何要求的：

触发器	含义
`forced`	应用的模式为始终。
`customer_collected`	您在创建会话时发送了已收集的同意（见下文）。

向 Didit 提供已知信息

创建会话为此提供了两个可选字段：

字段	功能
`user_state`	用户的居住地（已知时）：ISO 3166-2 行政区划代码（`US-IL`、`ES-M`）或美国州代码或名称（`IL`、`Illinois`）。如果声明的州属于适用州，则显示该步骤，并记录 `trigger: "declared_state"`。未知值将返回 `400`。
`biometric_consent`	您已收集的同意：`{ "given_at": "<ISO 8601>", "text_version": "<your version id>" }`。流程不会再次要求，决策记录为 `status: "given"` 且 `trigger: "customer_collected"`。`given_at` 不能是未来的时间。

{
  "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"
  }
}

哪些应用会显示该步骤

该步骤需要由能够显示它的应用来呈现。Didit 会在应用发出的每次请求中做出判断：

用户进行验证的位置	是否显示该步骤
托管验证流程：浏览器、Web SDK 或 WebView	是
原生 SDK 4.10.0 或更高版本（iOS、Android 以及打包了原生 4.10.0 或更高版本的 React Native 或 Flutter 发行版）	是
4.10.0 以下版本的原生 SDK，或未报告版本的 SDK	否

4.10.0 以下版本的原生 SDK

4.10.0 之前发布的原生 SDK 无法识别同意步骤，因此 Didit 不会向它们请求该步骤。验证过程将与之前完全一致：自拍照和其他人脸捕获均会被接收并处理，会话照常得出决策。 Didit 从不记录未获得的同意。当会话需要同意且旧版 SDK 捕获了人脸时，决策将显示：

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

如果您在原生应用中验证伊利诺伊州、德克萨斯州或科罗拉多州的用户，请升级至原生 SDK 4.10.0 或更高版本。 在升级之前，这些会话将在没有明确同意的情况下完成，而在自拍前收集同意是您的责任。

如果用户在托管流程中继续同一会话（在另一台设备上，或在应用为某些活体检测类型打开的 WebView 中），托管流程会显示该步骤，并且在用户做出选择之前不会捕获人脸。在此处给出的同意仍会保留 reason: "BIOMETRIC_CONSENT_UNSUPPORTED_SDK"，因为此前已在没有同意的情况下捕获了人脸。

用户看到的内容

该步骤会告知用户收集的内容、原因、持有方以及保留时长，并链接至生物识别数据政策。页面仅有一个按钮：我同意并继续，在用户勾选同意框之前该按钮保持禁用状态。 Didit 会保存用户的选择作为凭证：给出同意的时间、所展示文本的版本与哈希值、语言、工作流步骤，以及请求的 IP、地理位置和用户代理。用户一旦同意，该选择即为最终结果。

当用户不同意时

该步骤没有拒绝按钮。不愿意同意的用户会离开流程：系统不会捕获任何面部信息，且该会话将与任何其他用户未完成的会话一样以 Abandoned 结束（参见验证状态）。请为他们提供其他验证方式。

API 中的拒绝同意状态

决策中保留了 declined 状态和 BIOMETRIC_CONSENT_DECLINED 原因作为 API 取值。目前 Didit 界面均未提供拒绝选项，因此托管流程和原生 SDK 均不会记录拒绝。记录了拒绝的会话：

以 Declined 结束，并像任何其他拒绝情况一样触发 status.updated Webhook。
显示 biometric_consent.status 为 declined，reason 和 decline_reason 为 BIOMETRIC_CONSENT_DECLINED，并在 declined_at 中记录时间。
拒绝后不再捕获人脸。会话中已保存的每张人脸图像和生物特征模板均会被删除：自拍照、证件拍摄时的前置摄像头自拍照、证件肖像的人脸裁剪图、活体检测视频和完整会话视频。face_data_deleted_at 会记录删除时间。决策中将不再返回这些数据，且删除是不可逆的。
保留证件图像以及从中读取的数据：拒绝操作不会对其产生影响。

决策和 Webhook 中的体现

在获取会话中以及会话 Webhook 的 decision 中，每个用户验证决策均包含一个 biometric_consent 对象。若会话从未经过评估（例如没有进行人脸捕获的工作流），该对象为 null。

`status`	含义
`not_required`	会话不需要同意。
`pending`	需要同意但尚未给出。可通过查看 `reason` 来区分是旧版 SDK 还是用户尚未回答。
`given`	用户在流程中同意，或者您在创建时传递了 `biometric_consent`。
`declined`	记录了拒绝，且会话以 `Declined` 结束。目前 Didit 界面均未提供拒绝选项（参见上文）。

`reason`	含义
`BIOMETRIC_CONSENT_UNSUPPORTED_SDK`	4.10.0 以下版本或未报告版本的原生 SDK 在没有该步骤的情况下捕获了人脸。
`BIOMETRIC_CONSENT_DECLINED`	记录了拒绝。目前 Didit 界面均未提供拒绝选项。
`null`	无需说明。在会话不需要同意时始终为 `null`。

用户在托管流程中表示同意的会话：

"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
}

本示例经过缩减。所有字段及其类型均可在数据模型中查看。

概览

定价

工作流与验证

审核与运营

实体（用户与企业）

设置与自定义

安全与合规

Didit 学院

资源

生物识别同意：BIPA、CUBI 与科罗拉多州合规

何时显示该步骤

同意模式

自动模式下的步骤触发条件

向 Didit 提供已知信息

哪些应用会显示该步骤

4.10.0 以下版本的原生 SDK

用户看到的内容

当用户不同意时

API 中的拒绝同意状态

决策和 Webhook 中的体现

相关内容

​何时显示该步骤

​同意模式

​自动模式下的步骤触发条件

​向 Didit 提供已知信息

​哪些应用会显示该步骤

​4.10.0 以下版本的原生 SDK

​用户看到的内容

​当用户不同意时

​API 中的拒绝同意状态

​决策和 Webhook 中的体现

​相关内容

何时显示该步骤

同意模式

自动模式下的步骤触发条件

向 Didit 提供已知信息

哪些应用会显示该步骤

4.10.0 以下版本的原生 SDK

用户看到的内容

当用户不同意时

API 中的拒绝同意状态

决策和 Webhook 中的体现

相关内容