概要
ライブネスレポートの警告は、Diditがライブネスチェックの実行中に検出したすべての状況を示します。警告はliveness_checks[]の各項目にあるwarnings[]配列に格納され(ライブネスレポートを参照)、featureは"LIVENESS"に設定されます。各エントリーは共通の警告オブジェクトの形式に従います:feature、risk、additional_data、log_type、short_description、long_description、node_id。
すべての警告は3つの層で構成されます。
riskコード:コード内で照合に使える安定した識別子です(以下に記載のコード)。log_type:information、warning、errorのいずれかです。自動却下となるリスクには常にerrorが設定されます。設定可能なリスクでは、設定されたアクションから決まります:No action →information、Review →warning、Decline →error。しきい値に基づくリスク(LOW_LIVENESS_SCORE、LOW_FACE_QUALITY)では、値が却下しきい値を超えた場合はerror、レビューしきい値のみを超えた場合はwarningになります。- 判定への影響:同じ振り分けがライブネスレポートの
statusも決定します。ReviewアクションではIn Reviewに、Declineアクション(または自動却下となるいずれかのリスク)ではDeclinedに移行し、アクションなしでは変更されません。
PASSIVEの場合にのみ発生します。以下の表には、ライブネスのリスクコードとその重大度をすべて記載しています。これ以外のライブネスのリスクコードは存在しません。
自動却下の条件
以下のリスクは、常にライブネスレポート(およびセッション)をDeclinedにし、log_type: "error"が設定されます:
NO_FACE_DETECTEDが発生した場合、LOW_LIVENESS_SCOREは抑制されます(スコアを算出する顔がないため)。
設定可能な検証設定
Diditコンソールでは、ライブネスのリスクは以下のワークフロー設定にまとめられています:生成される警告
コアライブネス
キャプチャチャネルの完全性
キャプチャ時にクライアントから報告されるインジェクション攻撃のシグナルです。プレゼンテーション攻撃(本物のカメラの前に偽造物をかざすもの)とは異なり、これらはカメラ映像そのものが差し替えられたり傍受されたりしていることを示します。 いずれもワークフローごとに設定でき、デフォルトはアクションなしです。そのため、この機能を有効にしても、明示的に設定するまで判定は変わりません。ブラウザはOSレベルのカメラソース認証をどのベンダーにも公開していないため、Webではこれらのシグナルは証明ではなく裏付けとなる証拠です。Webでは、判定結果が
nullの場合は未判定(カメラの権限が付与されるまでデバイスラベルを取得できないため)を意味し、リスクが発生することはありません。FRAME_INJECTION_SUSPECTEDで報告されます。これはカメラ名ではなく、デバイス環境(レンダリングスタックと、ユーザーエージェントで報告されるデバイスモデル)から検出されます。デバイス環境に基づく検出結果にはadditional_data.reason: "emulated_capture_device"が付与され、ライブネスモデル自体によるフレーム分析と区別されます。
ブラウザからのマシン検出は証拠であって認証ではなく、意図的な攻撃者はこれを妨害できます。ネイティブのモバイルSDKは、ブラウザからは確認できない、より強力なオペレーティングシステムレベルの完全性シグナル(エミュレーター、root化またはジェイルブレイクされたデバイス、ランタイムフッキング、アタッチされたデバッガー)を報告し、それぞれにデバイスとランタイムの完全性で設定可能なアクションがあります。これらのシグナルは攻撃者のコストを大幅に引き上げますが、それだけではキャプチャが本物のデバイスから行われたことを証明するものではありません。デバイスの完全性シグナルはライブネスの方式とは独立しているため、Passive、3D Flash、3D Action & Flashのいずれとも組み合わせられます。
録画の健全性フォレンジック
LIVENESS_VIDEO_ANOMALYは、ライブネスモデルとは独立して、保存されたライブネス録画に対してサーバー側で算出されます。複数のサイクルにわたって繰り返される動きのあるシーケンスを検出します。これはループ再生された映像と一致する特徴です。
アクションはライブネス検知または年齢推定のノードで設定します。
NO_ACTIONは情報レベルの検出結果を記録し、REVIEWは判定済みの認証をレビュー中に引き上げ、DECLINEは却下に引き上げることがあります。このチェックは非同期で実行されるため、引き上げは最初の結果の後に届く場合があります。既存の判定がより重大な場合は引き下げられず、手動レビューによる判定は維持されます。
バージョン2の検出結果には、forensics_version: 2、repeated_sequenceの証拠、およびanomaly_reasons内のrepeated_moving_sequenceが含まれます。unique_frame_ratio、static_pair_ratio、decoded_fps_ratio、max_frame_gap_secondsなどの配信に関する測定値は診断情報にとどまり、それだけではリプレイを立証できません。以前の検出結果は当時使用された検出器のバージョンに基づくものであり、遡って再分類されることはありません。
これは控えめな追加シグナルであり、合成メディアや注入された映像を完全に検出するものではありません。異常のない録画がライブネスの証明になるわけではありません。短いキャプチャや判断が曖昧なキャプチャ、有効なリプレイの証拠がないキャプチャは、このチェックではフラグが立てられません。録画が存在しないか読み取れない場合、このチェックによる検出結果は生成されませんが、他の認証チェックは引き続き適用されます。
セッション横断の顔照合
インポートされた顔やリスト登録された顔(セッションを持たない顔)との一致の場合、
additional_data内の*_session_id、*_session_number、api_serviceの値はnullになります。
同じユーザー(同じvendor_data、または利用可能な場合は同じvendorユーザー)に属する顔は、インデックス検索の全体から除外されます。これは重複検知とブロックリストスクリーニングの両方に適用されます。一致の優先順位は、ブロックリスト完全一致 → 許可リスト完全一致 → 重複完全一致 → ブロックリスト一致の可能性 → 許可リスト一致の可能性 → 重複の可能性の順で、相互に排他的なこれら6つのコードのうち、1件のレポートに表示されるのは1つだけです。DUPLICATED_FACE_NAME_MISMATCHはこの優先順位グループには含まれません。これは本人情報の確認も失敗した場合にDUPLICATED_FACEに加えて出力される追加のコードであり、その代わりに出力されることはありません。additional_data.name_match_scoreに比較対象の氏名が含まれることはありません。含まれるのはIDとスコアのみであるため、警告ペイロードにPIIが入ることはありません。
書類ごとに異なる文字体系で書かれた氏名(例えば一方はヘブライ文字、もう一方はラテン文字)は、両方のセッションが同一人物のものであってもしきい値を下回るスコアになることがあります。この場合に限り、2つのセッションの身分証明書類が以下のすべてについて互いに裏付けられているときは、DUPLICATED_FACE_NAME_MISMATCHは出力されません。
- 両方の書類の発行国が同じであること。
- 2つの書類の間で識別子が完全に一致すること。書類の種類によって同じ国民番号がどちらのフィールドにも記載されうるため、
document_numberとpersonal_numberは相互に同等として扱われます。 - 両方の書類に生年月日が記載されている場合、それが同じ日付であること。
パッシブライブネスの品質 (method = "PASSIVE"の場合のみ)
LOW_FACE_LUMINANCEとHIGH_FACE_LUMINANCEは相互に排他的です。輝度は最小値を下回るか最大値を上回るかのいずれかであり、両方になることはありません。
年齢推定 (アダプティブワークフローとAGE_ESTIMATIONノード)
完全一致の説明文字列
APIは、各リスクについて次のshort_descriptionとlong_descriptionの文字列をそのまま返します。
スタンドアロンのパッシブライブネスAPI
スタンドアロンのライブネスAPIは同じリスクコードを使用しますが、動作にいくつか違いがあります。NO_FACE_DETECTEDとLOW_LIVENESS_SCOREが同時に発生することはありません。スコアのチェックは顔が検出された場合にのみ実行されます。LOW_LIVENESS_SCOREはリクエストのface_liveness_score_decline_threshold(デフォルトは30)を基準に発生し、常にlog_type: "error"を持ちます。POSSIBLE_FACE_IN_BLOCKLISTはレビューではなく却下(log_type: "error")として扱われます。MULTIPLE_FACES_DETECTEDはlog_type: "warning"を持ち、顔の重複に関するリスクは情報として扱われたままです。スタンドアロンのレスポンスのstatusをDeclinedに変えるのは、errorレベルの警告のみです。- スタンドアロンの警告エントリには
featureが含まれますが、node_idは含まれません。
例
攻撃検知時の自動却下
パッシブキャプチャでの設定可能な警告
ペイロード付きの重複顔
log_type: "warning"を持ち、ライブネスレポートのステータスはIn Reviewになります。デフォルト(アクションなし)の場合は、代わりにlog_type: "information"になります。一致した顔がスタンドアロンのAPI呼び出しではなくワークフローのセッションから得られたものであるため、api_serviceはnullです。
異なる氏名での重複顔
DUPLICATED_FACEは独自に設定されたアクション(ここではアクションなし、log_type: "information")のままですが、DUPLICATED_FACE_NAME_MISMATCHは独自のアクションを持ち、デフォルトは「レビュー」(log_type: "warning")です。ライブネスレポートのステータスは、2つのうち重大度の高いほうに従います。重複顔のみの設定ではフラグは立たなかったにもかかわらず、ここではIn Reviewになります。
測定値を伴う録画の整合性異常
NO_ACTIONであるため、log_typeはinformationです。簡潔にするためこの例では省略しているフレーム配信の診断情報は、この検出をトリガーしません。
警告の種類
各リスクには、アプリケーションの設定に基づいて重大度が割り当てられます。重大度は次の3つです。関連情報
- ライブネスレポート:レポートの完全なスキーマとステータス。
- 顔照合の警告:関連する1:1顔照合の警告。
- Webhook:
session.status.updatedは、ライブネスステップの完了後すぐに警告を含みます。 - データモデル:ライブネスチェック:すべてのフィールドを含む正式なスキーマ。
- データモデル:警告オブジェクト:
warnings[]の各エントリの構造。