跳转到主要内容

概述

活体检测报告记录了 Didit 在验证摄像头前是否有真人(而非打印照片、屏幕回放或深度伪造)时观察到的一切信息。它包括活体检测方法、0–100 的置信度分数、参考自拍照和采集视频、可选的年龄估算、被动活体质量指标,以及与您应用的历史记录和黑名单进行跨会话人脸比对的结果。 该报告在用户完成工作流中的活体检测步骤(或调用独立人脸 endpoint)后生成。Didit 会运行三种活体检测方法之一(主动 3D、闪烁或被动),对捕获内容进行评分,排查已知的欺骗攻击模式,并在生物特征层面将该人脸与您应用中出现过的所有人脸进行比对。 每份报告都有其独立的 status(独立于整体会话状态),反映活体检测步骤本身的判定结果:
  • 已通过 — 检测到人脸,活体检测分数高于审核阈值,未触发自动拒绝警告。
  • 审核中 — 触发了一个或多个转入审核的警告,或者分数处于或低于审核阈值但高于拒绝阈值。
  • 已拒绝 — 触发了自动拒绝条件(NO_FACE_DETECTED、LIVENESS_FACE_ATTACK、FACE_IN_BLOCKLIST 或年龄估算流程中的年龄风险),可配置的警告被路由为拒绝,或者分数处于或低于拒绝阈值。
  • 未完成 — 用户未完成活体检测步骤。

在 API 响应中的位置

活体检测报告在 GET /v3/session/{sessionId}/decision/ 中以 liveness_checks[] 形式呈现 — 始终为 JSON 数组,绝不是单一的 liveness 对象。当工作流多次运行活体检测时(例如主要检查加上重新采集),会出现多个条目。
  • 会话决策 API — GET /v3/session/{sessionId}/decision/ 在顶层返回 liveness_checks[]。参见检索会话决策。
  • Webhook — 一旦该步骤生成数据,session.status.updated payload 就会包含相同的 liveness_checks[] 数组。参见 Webhook。
  • 独立活体检测 API — 参见活体检测独立 API。
请读取 response.liveness_checks[0] 并遍历该数组 — 某些旧教程中提到的单一 liveness 结构在 v3 决策 endpoint 上并不存在。

架构

标准的逐字段架构位于 Data models 参考页面。以下字段与该标准架构保持一致。

跨会话人脸匹配

matches[] 列出了您应用历史记录中与此自拍照的生物特征相似度超过阈值的人脸(最多 5 个条目,黑名单和白名单人脸优先,然后按相似度降序排列)。符合条件的候选对象包括黑名单人脸、白名单人脸、来自 Approved 会话的人脸以及针对您的供应商用户导入的人脸。属于同一用户的人脸(相同的 vendor_data,或在可用时属于同一供应商用户)将被排除在整个搜索范围之外,包括重复人脸检测和黑名单筛查。 每个条目包含:

状态值

状态来自共享的功能状态枚举(FeatureStatusChoices)。

示例

Approved: 正常的主动 3D 采集

In Review: 被动活体检测,低质量采集并存在疑似重复

此处人脸质量(12.4)低于默认审核阈值(15),亮度(18.7)低于默认最低值(20),且工作流的重复人脸操作设置为 Review,因此所有三个警告均带有 log_type: "warning",报告结果为 In Review。

安全提示

活体检测视频和自拍照属于生物识别数据,签名 URL 为临时链接并且会过期(默认 4 小时后)。请将其视为短效数据:不要对其进行缓存或公开展示。通常您的应用仅需要 status、score 和警告信息,应尽可能少地存储生物识别数据,以最大程度减少服务器上的生物识别数据。

相关内容

最后修改于 2026年11月7日