> ## 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 इसे ऐसे नहीं मानेगा।

यह अंतर उस स्थिति में सबसे ज़रूरी है जिसने इसे ज़रूरी बनाया: एक असली, सहमति देने वाला व्यक्ति किसी ऐसी पहचान के तहत सत्यापन करने की कोशिश करता है जो उसकी अपनी नहीं है। वह कोशिश रोकी जानी चाहिए। लेकिन उसके बाद तीन अलग-अलग लोगों को परेशान नहीं किया जाना चाहिए: वही व्यक्ति, जब बाद में वह अपनी वैध पहचान से सत्यापन करे; वह व्यक्ति जिसकी पहचान उधार ली गई थी (जो अपराधी नहीं, पीड़ित है); और कोई भी ऐसा व्यक्ति जिसका चेहरा बस मिलता-जुलता दिखता है।

इसलिए धोखाधड़ी का अर्थ एक **पहचान दावे** से जुड़ा होता है, जो एक घटना है, न कि उस व्यक्ति से या उस पहचान से जिसे उसने दावा किया।

## चार आयाम, चार फ़ील्ड

निर्णय को कभी भी आपकी ओर से चुने गए एक शब्द में समेटा नहीं जाता। इनमें से हर एक अलग से रिपोर्ट होता है, और यह संयोजन आपके उत्पाद में क्या करेगा, यह आप तय करते हैं:

| आयाम | यह क्या बताता है | यह कहाँ दिखता है |
| - | - | - |
| **इनपुट की अखंडता** | क्या कैप्चर लाइव था, अपरिवर्तित था और किसी असली कैमरे से आया था? | लाइवनेस चेतावनियाँ (`LIVENESS_FACE_ATTACK`, `VIRTUAL_CAMERA_DETECTED`, …) |
| **पहचान मिलान** | क्या व्यक्ति उस पहचान से मेल खाता है जिसका उसने दावा किया, एक भरोसेमंद संदर्भ के विरुद्ध? | सत्र पर चेहरा मिलान और डुप्लिकेट-चेहरा चेतावनियाँ |
| **व्यवहार और नेटवर्क साक्ष्य** | क्या दूसरे संगठनों ने इसी व्यक्ति के ऐसी पहचान-दावा घटनाएँ देखी हैं जो मेल नहीं खाईं? | `CROSS_ORG_IDENTITY_CLAIM_PATTERN` |
| **अंतिम निर्णय** | सत्र की स्थिति अंत में क्या बनी | निर्णय payload पर `status` |

लाइवनेस जाँच में विफलता, पहचान का मेल न खाना और नेटवर्क पैटर्न, ये तीन अलग-अलग चीज़ों के बारे में तीन अलग बयान हैं। इन्हें एक संख्या की तरह पढ़ना ही वह तरीका है जिससे एक खराब तस्वीर आरोप में बदल जाती है।

### पहचान मिलान के लिए एक भरोसेमंद संदर्भ चाहिए

`match` और `mismatch` तभी बनाए जाते हैं जब चेहरे की तुलना करने के लिए कुछ भरोसेमंद मौजूद हो, जैसे सरकारी दस्तावेज़ का चित्र, या कोई ऐसी पहचान जो उस चेहरे से पहले से मज़बूती से जुड़ी हो। सिर्फ़ ईमेल पता या फ़ोन नंबर, जिनका कोई पहले का मज़बूत जुड़ाव न हो, चेहरे की तुलना के लिए कोई आधार नहीं देते। ऐसे में जवाब **कोई संदर्भ नहीं** होता, कभी `mismatch` नहीं, और चेहरे के इतिहास भर से निकाला गया `match` भी नहीं।

## संगठनों के बीच के साक्ष्य क्या कह सकते हैं और क्या नहीं

जब आपका संगठन Enterprise प्लान पर हो और उसका साझाकरण मोड `global` हो, तब कोई सत्र `CROSS_ORG_IDENTITY_CLAIM_PATTERN` उठा सकता है।
Enterprise से नीचे के प्लान पर, या जब साझाकरण `private` या `off` पर हो, तब संगठनों के बीच की जाँच नहीं चलती।
दावे का साक्ष्य केवल उन दूसरे संगठनों से आता है जो भी Enterprise प्लान पर हैं और वैश्विक रूप से साझा करते हैं।
इस चेतावनी का मतलब है:

> अन्य भाग लेने वाले संगठनों ने इसी व्यक्ति के लिए पहचान-दावा घटनाएँ दर्ज कीं, जिनमें
> दावा की गई पहचान उन सत्रों के साक्ष्य से मेल नहीं खाई।

इसका मतलब यह **नहीं** है कि व्यक्ति धोखेबाज़ है, और कोई भी Didit रिस्पॉन्स ऐसा नहीं कहेगा। इसके समर्थन में तीन गारंटियाँ हैं:

* **यदि आपकी अपनी जाँच पास हुई हो तो यह दबा दी जाती है।** अगर इस सत्र का अपना पहचान मिलान `match` है, तो चेतावनी बिल्कुल नहीं उठती। जो व्यक्ति अपने भरोसेमंद संदर्भ के विरुद्ध सफलतापूर्वक सत्यापन करता है, वह सत्यापित है। उसकी पहले की किसी भी भागीदारी का संबंध उन पिछले दावों से है, इस दावे से नहीं।
* **यह अस्वीकार का कारण नहीं बन सकती।** कार्रवाई समीक्षा या कोई कार्रवाई नहीं होती। `cross_org_identity_claim_pattern_action` पर अस्वीकार सेट करने को समीक्षा में बदल दिया जाता है, क्योंकि किसी व्यक्ति का इतिहास मौजूदा दावे की जाँच खोल सकता है, लेकिन उसे अस्वीकार नहीं कर सकता।
* **यह केवल समग्र जानकारी देती है।** payload में यह होता है कि कितने संगठन शामिल हैं, कितने दावे मेल नहीं खाए, कितनी अलग पहचानों का दावा किया गया और ये दावा घटनाएँ कितनी हाल की हैं। यह कभी नहीं बताता कि वे कौन हैं, उनके सत्र कौन से हैं, या उनका कोई भी डेटा।

`CROSS_ORG_FRAUD_FACE` इस चेतावनी का हटाया गया संस्करण है और अब नहीं उठाई जाती। इसे मान के रूप में इसलिए रखा गया है ताकि मौजूदा लॉग और नियम हल होते रहें। पुरानी घटनाएँ रिकॉर्ड हैं, किसी व्यक्ति के बारे में कोई फ़ैसला नहीं।

## केवल-चेहरा खोज: एक व्यक्ति आईडी, कोई फ़ैसला नहीं

किसी इंसान को दोबारा पहचानना किसी के बारे में कोई फ़ैसला लेने से अलग क्षमता है। केवल-चेहरा खोज उसी चेहरे के बार-बार किए गए उच्च-विश्वास कैप्चर के लिए एक **स्थिर, अपारदर्शी व्यक्ति आईडी** लौटाती है, और इसके अलावा कुछ नहीं।

* यह आईडी एक यादृच्छिक पहचानकर्ता है। यह न किसी चेहरे, फ़ेस एम्बेडिंग, सत्र, संगठन या ग्राहक संदर्भ से निकाली जाती है, इसलिए यह "यह कैप्चर पहले देखा गया था" से अधिक कुछ उजागर नहीं करती।
* इसमें कोई धोखाधड़ी की स्थिति नहीं होती। इसमें ऐसा कोई फ़ील्ड नहीं है जो ऐसी स्थिति रख सके।
* कम विश्वास वाला या संभावित मिलान कभी दो लोगों को एक में नहीं मिलाता। अधिक-विलय दो इंसानों को एक पहचान में जोड़ देता है, और यह डेटा से पलटा नहीं जा सकता। कम-विलय से केवल रिकॉल कम होता है।

## बहु-खाता पहचान अपने संगठन के भीतर है और सेगमेंट में बँटी है

"क्या इस चेहरे ने **हमारे** साथ कई खाते खोले हैं" एक अलग उत्पाद प्रश्न है, संगठनों के बीच के साक्ष्य से अलग। इसका उत्तर केवल आपके अपने संगठन के भीतर दिया जाता है।

सत्र बनाते समय `multi_account_segment` सेट करें ताकि उस खोज को एक स्पष्ट क्षेत्र मिले। दो सत्र जो अलग सेगमेंट में हैं, कभी एक-दूसरे के डुप्लिकेट नहीं माने जाते। इसी से आप व्यक्तिगत और व्यावसायिक खाते का आधार अलग-अलग चला सकते हैं, या हर उप-ग्राहक के लिए एक सेगमेंट बना सकते हैं, और जो व्यक्ति वैध रूप से हर एक में एक खाता रखता है, वह खाते जुटाने वाला न दिखे। यदि आप इसे छोड़ दें, तो हर सत्र एक ही डिफ़ॉल्ट क्षेत्र में रहता है, और यह ठीक वही आज का व्यवहार है।

ब्लॉकलिस्ट और अनुमति सूची का मिलान जानबूझकर सेगमेंट को अनदेखा करता है: ब्लॉकलिस्ट वाला चेहरा आपके पूरे संगठन में ब्लॉकलिस्ट में है, और कोई सेगमेंट कभी उससे बचने के लिए इस्तेमाल नहीं हो सकता।

## Privacy

* चेहरे संगठन की सीमा कभी पार नहीं करते। साझा धोखाधड़ी इंडेक्स भौतिक रूप से कोई चेहरा नहीं रख सकता: डेटाबेस लिखने के प्रयास को अस्वीकार कर देता है।
* सीमा पार जो जाता है, वह किसी सटीक मान का एकतरफ़ा कुंजी-आधारित हैश होता है (दस्तावेज़ संख्या, डिवाइस, IP, फ़ोन या ईमेल), जिसे किसी भाग लेने वाले संगठन ने धोखाधड़ी के रूप में चिह्नित किया हो।
* संगठनों के बीच की क्वेरी गिनती और हालिया समय-श्रेणियों के रूप में उत्तर देती हैं। योगदान देने वाले संगठन का नाम कभी नहीं लिया जाता, और कोई कच्चा मान, छवि या सत्र कभी बाहर नहीं जाता।
* साझाकरण पारस्परिक है और इसके लिए Enterprise प्लान और `global` साझाकरण मोड, दोनों चाहिए। जो संगठन योगदान नहीं देता, वह क्वेरी भी नहीं करता। Enterprise से नीचे का कोई संगठन, उसका साझाकरण मोड चाहे जो हो, न योगदान देता है और न क्वेरी करता है।
* संगठनों के बीच की **चेहरे** से जुड़ी जानकारी विशेष रूप से डिफ़ॉल्ट रूप से बंद रहती है। जब तक बायोमेट्रिक-व्यक्ति पहचानकर्ता और क्लेम-इवेंट मॉडल के लिए डेटा संरक्षण प्रभाव आकलन और कानूनी समीक्षा पूरी नहीं हो जाती, तब तक यह बंद ही रहती है।


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