मुख्य सामग्री पर जाएं

विवरण

लाइवनेस रिपोर्ट पर चेतावनियाँ लाइवनेस जांच चलाते समय Didit द्वारा देखी गई प्रत्येक स्थिति को फ़्लैग करती हैं। वे liveness_checks[] के प्रत्येक आइटम पर warnings[] ऐरे में आती हैं (देखें लाइवनेस रिपोर्ट), जिसमें feature "LIVENESS" पर सेट होता है। प्रत्येक प्रविष्टि साझा चेतावनी ऑब्जेक्ट संरचना का अनुसरण करती है: feature, risk, additional_data, log_type, short_description, long_description, node_id। प्रत्येक चेतावनी के तीन स्तर होते हैं:
  1. risk कोड — एक स्थिर पहचानकर्ता जिसे आप अपने कोड में मैच कर सकते हैं (नीचे सूचीबद्ध कोड)।
  2. log_type — information, warning, या error में से एक। ऑटो-डिक्लाइन जोखिम हमेशा error ले जाते हैं। कॉन्फ़िगर करने योग्य जोखिमों के लिए यह कॉन्फ़िगर की गई कार्रवाई से प्राप्त होता है: कोई कार्रवाई नहीं → information, समीक्षा → warning, अस्वीकार करें → error। थ्रेशोल्ड-आधारित जोखिमों (LOW_LIVENESS_SCORE, LOW_FACE_QUALITY) के लिए यह तब error होता है जब मान अस्वीकार थ्रेशोल्ड को पार करता है और तब warning होता है जब यह केवल समीक्षा थ्रेशोल्ड को पार करता है।
  3. निर्णय पर प्रभाव — यही रूटिंग लाइवनेस रिपोर्ट के status को निर्धारित करती है: समीक्षा (Review) कार्रवाई इसे In Review में ले जाती है, अस्वीकार करें (Decline) कार्रवाई (या कोई भी ऑटो-डिक्लाइन जोखिम) इसे Declined में ले जाती है, और कोई कार्रवाई नहीं (No action) इसे अप्रभावित छोड़ देती है।
कुछ जोखिम केवल तभी जारी किए जाते हैं जब लाइवनेस विधि PASSIVE हो (मल्टीपल-फ़ेस, गुणवत्ता और चमक जांच)। नीचे दी गई तालिकाएँ लाइवनेस जोखिम कोड और उनकी गंभीरता का पूरा सेट सूचीबद्ध करती हैं — कोई अन्य लाइवनेस जोखिम कोड मौजूद नहीं हैं।

ऑटो-डिक्लाइन शर्तें

निम्नलिखित जोखिम हमेशा लाइवनेस रिपोर्ट (और सत्र) को log_type: "error" के साथ Declined करने के लिए बाध्य करते हैं: जब NO_FACE_DETECTED ट्रिगर होता है, तो LOW_LIVENESS_SCORE को दबा दिया जाता है (स्कोर करने के लिए कोई चेहरा नहीं होता है)।

कॉन्फ़िगर करने योग्य सत्यापन सेटिंग्स

Didit कंसोल में, लाइवनेस जोखिमों को निम्नलिखित वर्कफ़्लो सेटिंग्स के अंतर्गत समूहीकृत किया गया है:

उत्पन्न चेतावनियाँ

कोर लाइवनेस

कैप्चर चैनल अखंडता

कैप्चर के समय क्लाइंट द्वारा रिपोर्ट किए गए इंजेक्शन अटैक संकेत। प्रेज़ेंटेशन अटैक (असली कैमरे के सामने रखी गई कोई कृत्रिम वस्तु) के विपरीत, ये कैमरा फ़ीड को ही बदले जाने या इंटरसेप्ट किए जाने को दर्शाते हैं। प्रत्येक वर्कफ़्लो के लिए कॉन्फ़िगर करने योग्य है और डिफ़ॉल्ट रूप से कोई कार्रवाई नहीं पर सेट होता है, इसलिए जब तक आप ऑप्ट इन नहीं करते, इस सुविधा को सक्षम करने से कोई निर्णय नहीं बदलता है।
ब्राउज़र किसी भी वेंडर को OS-स्तरीय कैमरा-स्रोत अटेस्टेशन प्रदान नहीं करते हैं, इसलिए वेब पर ये संकेत प्रमाण के बजाय पुष्टि करने वाले साक्ष्य होते हैं। वेब पर, null निर्णय का अर्थ है निर्धारित नहीं (कैमरा अनुमति दिए जाने तक डिवाइस लेबल अनुपलब्ध होते हैं) और यह कभी भी जोखिम ट्रिगर नहीं करता है।
वर्चुअल कैमरे की पहचान उसके डिवाइस नाम से की जाती है, इसलिए ऑपरेटिंग सिस्टम सामान्य नाम के तहत जिस कैमरे को प्रस्तुत करता है, उसे इस तरह से नहीं पहचाना जाता है। Android एमुलेटर के अंदर रीमैप किए गए कैमरे को किसी भी बिल्ट-इन कैमरे की तरह लेबल किया जाता है, यही कारण है कि एमुलेटेड-हार्डवेयर केस को इसके बजाय FRAME_INJECTION_SUSPECTED के माध्यम से रिपोर्ट किया जाता है: इसका पता कैमरे के नाम के बजाय डिवाइस एनवायरनमेंट - रेंडरिंग स्टैक और यूज़र एजेंट में रिपोर्ट किए गए डिवाइस मॉडल - से लगाया जाता है। डिवाइस एनवायरनमेंट से मिलने वाले निष्कर्षों में additional_data.reason: "emulated_capture_device" शामिल होता है, जो उन्हें लाइवनेस मॉडल के अपने फ़्रेम विश्लेषण से अलग करता है।
ब्राउज़र से मशीन का पता लगाना साक्ष्य है, अटेस्टेशन नहीं, और एक दृढ़ हमलावर इसमें हस्तक्षेप कर सकता है। नेटिव मोबाइल SDK अधिक मज़बूत, ऑपरेटिंग-सिस्टम-स्तरीय अखंडता संकेत रिपोर्ट करते हैं जिन्हें कोई ब्राउज़र नहीं देख सकता (एमुलेटर, रूटेड या जेलब्रोकन डिवाइस, रनटाइम हुकिंग, अटैच्ड डिबगर), जिनमें से प्रत्येक की अपनी कॉन्फ़िगर करने योग्य कार्रवाई डिवाइस और रनटाइम अखंडता के अंतर्गत होती है। ये संकेत हमलावर की लागत को काफी बढ़ा देते हैं, लेकिन अपने आप में वे यह साबित नहीं करते कि कैप्चर किसी वास्तविक डिवाइस से आया था। डिवाइस अखंडता संकेत लाइवनेस विधि से स्वतंत्र होते हैं, इसलिए वे 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, या उपलब्ध होने पर समान वेंडर उपयोगकर्ता) से संबंधित चेहरों को संपूर्ण इंडेक्स खोज से बाहर रखा जाता है — डुप्लिकेट डिटेक्शन और ब्लॉकलिस्ट स्क्रीनिंग दोनों। मिलान की प्राथमिकता है: ब्लॉकलिस्ट सटीक → अलाउलिस्ट सटीक → डुप्लिकेट सटीक → ब्लॉकलिस्ट संभावित → अलाउलिस्ट संभावित → डुप्लिकेट संभावित — प्रति रिपोर्ट इन छह परस्पर अनन्य कोडों में से केवल एक ही दिखाई देता है। DUPLICATED_FACE_NAME_MISMATCH उस प्राथमिकता समूह का हिस्सा नहीं है: यह पहचान जांच विफल होने पर भी DUPLICATED_FACE के अलावा जारी होने वाला एक अतिरिक्त कोड है, कभी भी उसके स्थान पर नहीं। additional_data.name_match_score में कभी भी तुलना किए जा रहे नाम शामिल नहीं होते हैं — केवल आईडी और एक स्कोर होता है, ताकि कोई भी PII चेतावनी payload में न पहुंचे। प्रत्येक दस्तावेज़ पर अलग लिपि में लिखा गया नाम (उदाहरण के लिए एक पर हिब्रू और दूसरे पर लैटिन) थ्रेशोल्ड से कम स्कोर कर सकता है, भले ही दोनों सत्र एक ही व्यक्ति के हों। उस एकमात्र मामले में, DUPLICATED_FACE_NAME_MISMATCH तब जारी नहीं किया जाता है जब दोनों सत्रों के पहचान दस्तावेज़ इन सभी पर एक-दूसरे की पुष्टि करते हैं:
  • दोनों दस्तावेज़ों में समान जारीकर्ता राज्य है।
  • दोनों दस्तावेज़ों के बीच एक पहचानकर्ता बिल्कुल मेल खाता है। document_number और personal_number को एक-दूसरे के स्थान पर माना जाता है, क्योंकि दस्तावेज़ के प्रकार के आधार पर समान राष्ट्रीय संख्या दोनों में से किसी भी फ़ील्ड में हो सकती है।
  • जहाँ दोनों दस्तावेज़ों में जन्म तिथि होती है, वह समान तिथि होती है।
यदि नाम समान लिपि में हैं, यदि पहचानकर्ता या जारीकर्ता राज्य भिन्न है या अनुपलब्ध है, या यदि जन्म तिथियाँ परस्पर विरोधी हैं, तो चेतावनी अभी भी ऊपर बताए अनुसार जारी की जाती है।

पैसिव लाइवनेस गुणवत्ता (केवल जब method = "PASSIVE")

LOW_FACE_LUMINANCE और HIGH_FACE_LUMINANCE परस्पर अनन्य हैं — ल्यूमिनेंस या तो न्यूनतम से नीचे होता है या अधिकतम से ऊपर, कभी भी दोनों नहीं।

आयु अनुमान (अनुकूली वर्कफ़्लो और AGE_ESTIMATION नोड)

सटीक विवरण स्ट्रिंग्स

API प्रत्येक जोखिम के लिए ये सटीक short_description और long_description स्ट्रिंग्स लौटाता है:

स्टैंडअलोन पैसिव लाइवनेस API

स्टैंडअलोन Liveness 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" होता है, जबकि डुप्लिकेट-चेहरे के जोखिम सूचनात्मक रहते हैं। केवल error-स्तरीय चेतावनियाँ स्टैंडअलोन रिस्पॉन्स की status को Declined में बदलती हैं।
  • स्टैंडअलोन चेतावनी प्रविष्टियों में feature शामिल होता है लेकिन कोई node_id नहीं होता।

उदाहरण

डिटेक्ट किए गए अटैक पर ऑटो-डिक्लाइन

पैसिव कैप्चर पर कॉन्फ़िगर करने योग्य चेतावनियाँ

payload के साथ डुप्लिकेट चेहरा

यहाँ डुप्लिकेट-चेहरा कार्रवाई Review पर सेट है, इसलिए चेतावनी में log_type: "warning" शामिल है और लाइवनेस रिपोर्ट की स्थिति In Review है। डिफ़ॉल्ट (No action) के साथ इसमें इसके बजाय log_type: "information" शामिल होगा। api_service null है क्योंकि मिलान किया गया चेहरा एक वर्कफ़्लो सत्र से आया था, न कि स्टैंडअलोन API कॉल से।

अलग नाम के तहत डुप्लिकेट चेहरा

DUPLICATED_FACE अपनी स्वयं की कॉन्फ़िगर की गई कार्रवाई पर रहता है (यहाँ, No action — log_type: "information"), जबकि DUPLICATED_FACE_NAME_MISMATCH अपनी स्वयं की कार्रवाई रखता है, जो डिफ़ॉल्ट रूप से Review (log_type: "warning") होती है। लाइवनेस रिपोर्ट की स्थिति दोनों कार्रवाइयों में से अधिक गंभीर वाली के अनुसार होती है: यहाँ In Review, भले ही अकेले सामान्य डुप्लिकेट-चेहरा सेटिंग ने इसे फ़्लैग न किया होता।

अपने मापों के साथ रिकॉर्डिंग सैनिटी विसंगति

यह उदाहरण किसी मूविंग सीक्वेंस की तीन प्रतियों वाली रिकॉर्डिंग से रीप्ले साक्ष्य दिखाता है। log_type information है क्योंकि कॉन्फ़िगर की गई कार्रवाई NO_ACTION है। संक्षिप्तता के लिए इस उदाहरण से छोड़े गए फ़्रेम-डिलीवरी डायग्नोस्टिक्स, इस डिटेक्शन को ट्रिगर नहीं करते हैं।

चेतावनी प्रकार

प्रत्येक जोखिम को आपके एप्लिकेशन के कॉन्फ़िगरेशन के आधार पर एक गंभीरता सौंपी जाती है। तीन गंभीरता स्तर हैं:

संबंधित

अंतिम संशोधन 7 नवंबर 2026