> ## Documentation Index
> Fetch the complete documentation index at: https://docs.didit.me/llms.txt
> Use this file to discover all available pages before exploring further.

# 組織横断のアイデンティティクレーム

> Didit は、他の組織から得た本人確認の証拠を、誰にも不正のラベルを付けずに報告します。結果は項目ごとに分けて示され、共有はデフォルトでオフです。

## このページが存在する理由となるルール

顔は安定したアイデンティティです。不正のラベルではなく、Diditが顔を不正のラベルとして扱うことはありません。

この区別が最も重要になるのは、このルールのきっかけとなったケースです。実在し、同意している人物が、
自分のものではないアイデンティティで認証しようとする場合です。この試みは阻止しなければなりません。しかし、その後は3人の
別々の人物に影響を与えてはなりません。後に自分自身の有効なアイデンティティで認証する同じ人物、
アイデンティティを借用された人物(加害者ではなく被害者です)、
そして顔がたまたま似ているだけの人物です。

したがって、不正とみなす対象は、イベントである**アイデンティティの主張**であり、その主張を行った人物や主張されたアイデンティティではありません。

## 4つの観点と4つのフィールド

判定が、あなたに代わって選ばれた1つの言葉にまとめられることはありません。以下はそれぞれ
独立して報告され、その組み合わせに対してプロダクトがどう動くかはあなたが決めます。

| 観点 | 答える問い | 表示される場所 |
| - | - | - |
| **入力の完全性** | 撮影はライブで、改変されておらず、実際のカメラからのものか | ライブネスの警告(`LIVENESS_FACE_ATTACK`、`VIRTUAL_CAMERA_DETECTED`、…) |
| **本人確認との一致** | 信頼できる参照と照らして、その人物は主張したアイデンティティと一致したか | セッション上の顔照合および重複顔の警告 |
| **行動とネットワークの証拠** | 他の組織が、この同じ人物についてアイデンティティの主張が一致しなかったイベントを確認しているか | `CROSS_ORG_IDENTITY_CLAIM_PATTERN` |
| **最終判定** | セッションのステータスが最終的に何になったか | 判定ペイロードの`status` |

ライブネスチェックの失敗、アイデンティティの不一致、ネットワーク上のパターンは、3つの異なる対象についての
3つの異なる記述です。これらを1つの数値として読むことで、質の悪い写真が
告発に変わってしまうのです。

### 本人確認との一致には信頼できる参照が必要

`match`と`mismatch`は、顔を比較できる信頼できる対象がある場合にのみ生成されます。
たとえば、政府発行の書類の顔写真や、その顔にすでに強く紐づけられたアイデンティティです。
事前の強い紐づけがないメールアドレスや電話番号には、顔を比較する対象がありません。
その場合の答えは**参照なし**であり、`mismatch`になることはなく、顔の履歴だけから
推測された`match`になることもありません。

## 組織横断の証拠が示せること、示せないこと

組織がEnterpriseプランを利用しており、共有モードが`global`の場合、セッションで`CROSS_ORG_IDENTITY_CLAIM_PATTERN`が発生することがあります。
Enterprise未満のプラン、または共有が`private`や`off`に設定されている場合、組織横断のチェックは実行されません。
主張の証拠は、同じくEnterpriseプランを利用しグローバルに共有している他の組織からのみ得られます。
この警告の意味は次のとおりです。

> 参加している他の組織が、この同じ人物についてアイデンティティの主張イベントを記録しており、
> それらのセッションでは主張されたアイデンティティがセッション上の証拠と一致しなかった。

これは、その人物が不正を行っているという意味では**ありません**。Diditのレスポンスがそのように述べることは決してありません。
これは次の3つの保証によって裏付けられています。

* **自社のチェックが通過した場合は抑制されます。** このセッション自体の本人確認との一致が
  `match`であれば、警告はまったく発生しません。自身の信頼できる参照に対して認証に成功した人物は
  認証済みです。過去にその人物が関与していた可能性のある事柄は、それらの主張に属するものであり、
  今回の主張に属するものではありません。
* **却下はできません。** アクションは「レビュー」または「アクションなし」です。
  `cross_org_identity_claim_pattern_action`に「却下」を設定すると「レビュー」に引き下げられます。
  人物に関する履歴は、現在の主張についての調査を開始するきっかけにはなっても、主張を却下する根拠には決してならないためです。
* **集計情報のみです。** ペイロードに含まれるのは、組織の数、不一致だった主張の数、主張された
  異なるアイデンティティの数、およびどの程度最近のものかだけです。それらが誰であるか、どのセッションか、
  どのようなデータかは一切含まれません。

`CROSS_ORG_FRAUD_FACE`はこの警告の廃止された旧バージョンであり、現在は発生しません。既存のログや
ルールで引き続き参照できるよう、値としては残されています。過去の発生は記録であり、
人物に対する判断ではありません。

## 顔のみの検索: 判定ではなく人物ID

同じ人物を再び認識することは、その人物について何かを判定することとは別の機能です。
顔のみの検索は、同じ顔が高い信頼度で繰り返し撮影された場合に**安定した不透明な人物ID**を返し、
それ以外は何も返しません。

* このIDはランダムな識別子です。顔、エンベディング、セッション、組織、顧客の参照情報から
  生成されたものではないため、「この顔は以前にも撮影されている」ということ以外は何も明らかにしません。
* このIDに不正状態はなく、それを示すフィールドもありません。
* 信頼度の低い一致や一致の可能性では、2人の人物が統合されることはありません。過剰な統合は2人の
  人間を1つのアイデンティティに融合させ、データから元に戻すことはできません。過少統合でも、再現率が下がるだけです。

## 複数アカウントの検知は同一組織内でセグメント単位

「この顔が**自組織で**複数のアカウントを開設したか」は、組織横断の証拠とは異なるプロダクト上の問いであり、
あなた自身の組織内でのみ答えが出されます。

セッション作成時に`multi_account_segment`を設定すると、その検索に明示的な範囲を与えられます。異なるセグメントにある
2つのセッションが互いの重複と見なされることはありません。これにより、個人アカウントと企業アカウントの基盤を
分けて運用したり、サブクライアントごとに1つのセグメントを設けたりしても、それぞれに正当に1つずつアカウントを持つ人物が
アカウントファーミングのように見えることはありません。省略すると、すべてのセッションが単一のデフォルト範囲に入り、
これは現在の動作とまったく同じです。

ブロックリストと許可リストの照合は、意図的にセグメントを無視します。ブロックリストに登録された顔は
組織内のどこでもブロックリスト登録済みとなるため、セグメントを使ってブロックリストを回避することはできません。

## プライバシー

* 顔データが組織の境界を越えることはありません。共有の不正インデックスは物理的に顔データを保持できず、
  データベースが書き込みを拒否します。
* 境界を越えるのは、参加組織が不正としてラベル付けした完全一致の値(書類番号、
  デバイス、IP、電話番号、メールアドレス)の一方向キー付きハッシュです。
* 組織をまたぐ読み取りは、件数と直近性の区分で応答します。情報を提供した
  組織の名前が明かされることはなく、生の値、画像、セッションが外部に出ることも一切ありません。
* 共有は相互的なもので、Enterpriseプランと`global`共有モードの両方が必要です。
  情報を提供しない組織は照会できません。また、Enterpriseに満たないプランの組織は、共有モードにかかわらず情報の提供も照会もできません。
* 特に組織横断の**顔**インテリジェンスはデフォルトで無効になっており、生体情報に基づく個人識別子と
  クレームイベントモデルに関するデータ保護影響評価および法務レビューが完了するまで、
  無効のままとなります。


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.