कोई कॉल-होम सत्यापन नहीं: भविष्य के डिजिटल आईडीपी को हर उपयोग पर जारीकर्ता को फ़ोन क्यों नहीं करना चाहिए

किसी भी भविष्य के डिजिटल अंतर्राष्ट्रीय ड्राइविंग परमिट (IDP) में निरस्तीकरण सबसे कठिन समस्या है। इसे हल करने का सबसे आसान तरीका सबसे खतरनाक भी है: जारीकर्ता को हर एकल प्रस्तुति में भागीदार बनाना। एक आधुनिक सीमा-पार ड्राइविंग क्रेडेंशियल को डिफ़ॉल्ट रूप से इस शॉर्टकट से मना करना चाहिए।

लगभग हर डिजिटल-पहचान प्रस्ताव में एक ही आश्वस्त करने वाला वाक्य होता है:

“क्रेडेंशियल को तुरंत सत्यापित किया जा सकता है।”

कभी-कभी वह वाक्य वास्तविक प्रगति का वर्णन करता है। कभी-कभी यह एक अधिक मित्रवत यूज़र इंटरफ़ेस के साथ निगरानी का वर्णन करता है।

आज के प्रकाशित मानक पहले से ही स्पष्ट करते हैं कि एक सत्यापनकर्ता को हर बार क्रेडेंशियल दिखाए जाने पर जारीकर्ता से संपर्क करने की आवश्यकता नहीं है:

• NIST का वर्तमान mDL आर्किटेक्चर कहता है कि एक सत्यापनकर्ता जारीकर्ता के हस्ताक्षर और सार्वजनिक कुंजियों पर भरोसा करके प्रामाणिकता और अखंडता को सत्यापित कर सकता है — जारीकर्ता से किसी भी प्रत्यक्ष संपर्क के बिना।
• AAMVA पुष्टि करता है कि ISO/IEC 18013-5 डिवाइस रिट्रीवल के लिए समर्थन की आवश्यकता है और केवल वैकल्पिक रूप से सर्वर रिट्रीवल की अनुमति देता है।
• AAMVA यह भी चेतावनी देता है कि सर्वर रिट्रीवल के तहत, जारी करने वाला प्राधिकरण हर उपयोग पर वास्तविक समय में शामिल होता है — जिसका अर्थ है कि वह तकनीकी रूप से लॉग कर सकता है कि क्रेडेंशियल का उपयोग कब किया गया, कौन-सा डेटा साझा किया गया, और IP विश्लेषण से स्थान का भी अनुमान लगा सकता है।

यह कोई मामूली फुटनोट नहीं है। यह सीमा-पार ड्राइविंग क्रेडेंशियल की अगली पीढ़ी के लिए केंद्रीय डिज़ाइन प्रश्न है।

खतरनाक शॉर्टकट: चार प्रश्नों को एक नेटवर्क कॉल में समेटना

ख़राब आर्किटेक्चर चार बहुत अलग प्रश्नों को जारीकर्ता के एकल लाइव कॉल में बंडल कर देते हैं:

1. क्या यह क्रेडेंशियल प्रामाणिक है?
2. क्या इसे प्रस्तुत करने वाला व्यक्ति वैध धारक है?
3. क्या क्रेडेंशियल स्वयं अभी भी वैध है?
4. क्या अंतर्निहित राष्ट्रीय ड्राइविंग अधिकार अभी भी लागू है?

एक खराब डिज़ाइन किया गया सिस्टम वास्तविक समय में होम कॉल करके सभी चारों का उत्तर देता है। एक अच्छी तरह से डिज़ाइन किया गया सिस्टम उन्हें अलग करता है — क्योंकि वे एक ही समस्या नहीं हैं और उन्हें एक ही तंत्र साझा नहीं करना चाहिए।

प्रामाणिकता का सत्यापन स्थानीय रूप से होना चाहिए, नेटवर्क पर नहीं

एक क्रेडेंशियल क्रिप्टोग्राफ़िक रूप से वास्तविक हो सकता है, बिना जारीकर्ता के लेन-देन का कभी अवलोकन किए।

• NIST का mDL ट्रस्ट मॉडल कहता है कि प्रामाणिकता और अखंडता जारीकर्ता के हस्ताक्षर और सार्वजनिक कुंजियों से सत्यापित की जाती है — कोई लाइव जारीकर्ता संपर्क आवश्यक नहीं।
• AAMVA की डिजिटल ट्रस्ट सेवा विशेष रूप से सत्यापनकर्ताओं को प्रति-लेन-देन कॉलबैक के बिना वैध जारीकर्ता सार्वजनिक कुंजियों तक पहुँच देने के लिए मौजूद है।

डिज़ाइन सिद्धांत 1: लाइव कनेक्टिविटी का उपयोग उस समस्या को हल करने के लिए न करें जिसे हस्ताक्षर पहले से ही हल करते हैं।

यदि कोई सत्यापनकर्ता विश्वसनीय जारीकर्ता कुंजियाँ रखता है और मानक-अनुपालन प्रस्तुति प्राप्त करता है, तो प्रामाणिकता एक स्थानीय क्रिप्टोग्राफ़िक जाँच है, न कि नेटवर्क निर्भरता।

धारक बाइंडिंग स्थानीय रूप से सिद्ध होनी चाहिए, वैश्विक रूप से रिपोर्ट नहीं

दूसरा प्रश्न — क्या यह वैध धारक है? — का भी एक गैर-नेटवर्क उत्तर है।

वर्तमान EUDI आर्किटेक्चर PID और ISO/IEC 18013-5 अटेस्टेशन के लिए डिवाइस बाइंडिंग को अनिवार्य करता है। सत्यापनकर्ता वॉलेट से उस निजी कुंजी का उपयोग करके एक ताज़ा चुनौती पर हस्ताक्षर करने के लिए कहता है जो क्रेडेंशियल में एम्बेड की गई सार्वजनिक कुंजी से मेल खाती है:

• ISO/IEC 18013-5 में इसे mdoc प्रमाणीकरण कहा जाता है।
• SD-JWT VC में इसे की बाइंडिंग कहा जाता है।

दोनों मामलों में, कब्ज़ा स्थानीय और क्रिप्टोग्राफ़िक रूप से सिद्ध होता है। कोई भी व्यक्तिगत डेटा कभी भी जारीकर्ता तक पहुँचने की आवश्यकता नहीं होती।

डिज़ाइन सिद्धांत 2: कब्ज़ा स्थानीय रूप से सिद्ध करें। पहचान वैश्विक रूप से सिद्ध न करें।

एक भावी IDP को किसी भी जारीकर्ता-साइड तंत्र पर विचार करने से पहले डिवाइस बाइंडिंग, स्थानीय धारक प्रमाणीकरण, और सत्यापनकर्ता चुनौती-प्रतिक्रिया को समाप्त कर देना चाहिए।

क्रेडेंशियल स्थिति और ड्राइविंग-अधिकार स्थिति दो अलग चीज़ें हैं

कई डिजिटल-पहचान डिज़ाइन इस अंतर को धुंधला करते हैं, और यहीं वे गलत हो जाते हैं।

W3C की बिटस्ट्रिंग स्टेटस लिस्ट विशिष्टता इस बात को स्पष्ट करती है: एक सत्यापन योग्य क्रेडेंशियल से जुड़ी स्थिति जानकारी सत्यापन योग्य क्रेडेंशियल स्वयं पर लागू होती है — जरूरी नहीं कि अंतर्निहित वास्तविक-दुनिया के अधिकार पर। एक डिजिटल क्रेडेंशियल को इसलिए निरस्त किया जा सकता है क्योंकि इसका हस्ताक्षर तंत्र समझौता हो गया था, जबकि अंतर्निहित ड्राइविंग अधिकार पूरी तरह से वैध बना रहता है।

इसलिए एक भावी IDP को दो अलग स्थिति परतों की आवश्यकता है:

• क्रेडेंशियल-स्थिति परत — डिजिटल क्रेडेंशियल या प्रस्तुति चैनल के लिए।
• ड्राइविंग-अधिकार परत — ड्राइव करने के अंतर्निहित राष्ट्रीय अधिकार के लिए।

कभी-कभी ये एक साथ बदलते हैं। अक्सर नहीं बदलते। एक ऐसा सिस्टम जो उन्हें मिलाता है, अत्यधिक प्रतिक्रिया करेगा, आवश्यकता से अधिक डेटा उजागर करेगा, या दोनों।

वॉलेट समझौते को स्थिति के माध्यम से प्रसारित होना चाहिए — सत्यापनकर्ता कॉलबैक को ट्रिगर नहीं करना चाहिए

एक भावी IDP को इस बात का भी स्पष्ट उत्तर चाहिए कि जब कोई वॉलेट समझौता हो जाए तो क्या होता है।

EUDI आर्किटेक्चर एक प्रदान करता है:

• वॉलेट प्रदाता वॉलेट यूनिट अटेस्टेशन जारी करता है जिसमें निरस्तीकरण जानकारी होती है।
• वॉलेट अखंडता समय के साथ पुनः-सत्यापित होती है; यदि कोई वॉलेट अब सुरक्षित नहीं है, तो उसका अटेस्टेशन निरस्त कर दिया जाता है।
• PID प्रदाताओं को नियमित रूप से जाँचना होता है कि क्या वॉलेट निरस्त किया गया है। यदि हो गया है, तो वे PID निरस्त करते हैं।
• PID स्थिति सत्यापित करके, भरोसेमंद पक्ष अप्रत्यक्ष रूप से वॉलेट स्थिति सत्यापित करता है।

यह वह स्तरीकरण है जिसे एक भावी IDP को अपनाना चाहिए। हर सत्यापनकर्ता से स्वतंत्र रूप से वॉलेट प्रदाता की जाँच करने के लिए न कहें। वॉलेट समझौते को मौजूदा क्रेडेंशियल-स्थिति पाइपलाइन के माध्यम से प्रसारित होने दें, और सत्यापनकर्ताओं को उस एकल गोपनीयता-संरक्षित चैनल से परामर्श करने दें।

तीन व्यावहारिक निरस्तीकरण पैटर्न (कोई कॉलबैक आवश्यक नहीं)

EUDI प्रदाताओं को तीन निरस्तीकरण विधियों में से एक का उपयोग करने की आवश्यकता है:

• अल्पकालिक अटेस्टेशन — 24 घंटे या उससे कम के लिए वैध, इसलिए निरस्तीकरण अनावश्यक हो जाता है।
• अटेस्टेशन स्टेटस लिस्ट — एक प्रकाशित सूची जिसे सत्यापनकर्ता परामर्श कर सकते हैं।
• अटेस्टेशन रिवोकेशन लिस्ट — निरस्त क्रेडेंशियल की एक स्पष्ट सूची।

24 घंटे से अधिक के लिए वैध अटेस्टेशन के लिए, EUDI निरस्तीकरण जानकारी एम्बेड करने की आवश्यकता है जिसमें शामिल हैं:

• एक URL जहाँ भरोसेमंद पक्ष स्थिति सूची प्राप्त कर सकते हैं।
• उस सूची के भीतर क्रेडेंशियल का पता लगाने वाला एक पहचानकर्ता।

यदि विश्वसनीय निरस्तीकरण जानकारी अनुपलब्ध है — उदाहरण के लिए, जब भरोसेमंद पक्ष ऑफ़लाइन हो — तो EUDI भरोसेमंद पक्ष को क्रेडेंशियल स्वीकार करने या अस्वीकार करने से पहले जोखिम विश्लेषण करने का निर्देश देता है।

निष्कर्ष: निरस्तीकरण एकल तंत्र नहीं है, और निश्चित रूप से अनिवार्य जारीकर्ता कॉलबैक का औचित्य नहीं है।

डिफ़ॉल्ट रूप से अल्पकालिक, केवल जहाँ आवश्यक हो वहाँ दीर्घकालिक

पूरे स्टैक में सबसे प्रभावी गोपनीयता उपायों में से एक सबसे सरल भी है: जो प्रस्तुत किया जाए उसे अल्पकालिक रखें।

• EUDI कहता है कि 24 घंटे या उससे कम के लिए वैध अटेस्टेशन को निरस्तीकरण बुनियादी ढाँचे की आवश्यकता नहीं है — वे निरस्तीकरण मायने रखने से पहले ही समाप्त हो जाते हैं।
• W3C कहता है कि सत्यापन योग्य प्रस्तुतियाँ आमतौर पर अल्पकालिक होती हैं और दीर्घकालिक भंडारण के लिए डिज़ाइन नहीं की गई हैं।
• NIST स्पष्ट रूप से रोज़मर्रा के उपयोग के लिए पुन: उपयोग योग्य पहचानकर्ताओं को बार-बार प्रसारित करने के खिलाफ चेतावनी देता है। दिन-प्रतिदिन का प्रमाणीकरण उस उद्देश्य के लिए बनाई गई तकनीकों पर निर्भर होना चाहिए, जैसे पासकी, न कि पहचान-समृद्ध क्रेडेंशियल की बार-बार प्रस्तुति।
• NIST ने विशेष रूप से स्थानीय डिवाइस प्रमाणीकरण को सर्वर-साइड बायोमेट्रिक मिलान के बजाय चुना क्योंकि स्थानीय प्रमाणीकरण गोपनीयता को संरक्षित करता है और परिचालन रूप से अधिक कुशल है।

डिज़ाइन सिद्धांत 3: आधार क्रेडेंशियल की मध्यम वैधता अवधि हो सकती है, लेकिन प्रस्तुति स्वयं अल्पकालिक, सत्यापनकर्ता-विशिष्ट और गैर-पुन: उपयोगी होनी चाहिए।

स्टेटस लिस्ट सही डिफ़ॉल्ट तंत्र है

जब आप हर चीज़ को अल्पकालिक नहीं बना सकते, तो आपको स्थिति बुनियादी ढाँचे की आवश्यकता होती है — और स्टेटस लिस्ट सही डिफ़ॉल्ट है।

W3C की बिटस्ट्रिंग स्टेटस लिस्ट v1.0 निलंबन या निरस्तीकरण जैसे स्थिति डेटा प्रकाशित करने के लिए एक गोपनीयता-संरक्षित, स्थान-कुशल, उच्च-प्रदर्शन तंत्र का वर्णन करती है। मुख्य गुणों में शामिल हैं:

• प्रत्येक जारीकर्ता अपने द्वारा जारी किए गए क्रेडेंशियल के लिए एक सूची प्रबंधित करता है।
• प्रारूप अच्छी तरह से संपीड़ित होता है, क्योंकि अधिकांश क्रेडेंशियल निरस्त नहीं होते।
• डिफ़ॉल्ट सूची का आकार 1,31,072 प्रविष्टियाँ है, जो W3C के अनुसार औसत मामले में पर्याप्त समूह गोपनीयता प्रदान करता है।
• जहाँ मजबूत समूह गोपनीयता की आवश्यकता हो वहाँ बड़ी सूचियों का उपयोग किया जा सकता है।

यह प्रश्न को इससे बदल देता है:

“क्या मैं अभी इस उपयोगकर्ता के बारे में जारीकर्ता से पूछ सकता हूँ?”

इसमें बदलकर:

“क्या मेरे पास पहले से ही एक हालिया पर्याप्त गोपनीयता-संरक्षित स्टेटस लिस्ट है जिससे स्थानीय रूप से निर्णय लिया जा सके?”

यह एक बेहतर प्रश्न है — तकनीकी और राजनीतिक दोनों दृष्टि से।

“नो कॉल-होम” एक डाउनलोड पैटर्न है, नारा नहीं

EUDI की गोपनीयता मार्गदर्शिका में सबसे महत्वपूर्ण नियम प्रक्रियात्मक है, दार्शनिक नहीं।

भरोसेमंद पक्षों को हर बार क्रेडेंशियल प्रस्तुत होने पर स्टेटस लिस्ट का अनुरोध नहीं करना चाहिए। इसके बजाय, उन्हें:

• सूची का प्रत्येक नया संस्करण एक बार डाउनलोड करना चाहिए।
• ऐसा किसी भी उपयोगकर्ता प्रस्तुति से असंबंधित समय और स्थान से करना चाहिए।
• सूची को भरोसेमंद-पक्ष संगठन के भीतर आंतरिक रूप से वितरित करना चाहिए।
• भरोसेमंद पक्ष को प्रमाणित किए बिना सूची प्राप्त करनी चाहिए।

यह नो-कॉल-होम सत्यापन का परिचालन मूल है: स्थिति को उपयोगकर्ता प्रस्तुतियों से अलग रिफ़्रेश करें — कभी भी प्रति व्यक्ति नहीं, कभी भी प्रति लेन-देन नहीं।

यह एकल डिज़ाइन विकल्प जारीकर्ता या स्थिति प्रदाता को यह जानने से रोकता है कि किस सत्यापनकर्ता ने किस क्षण किस क्रेडेंशियल की जाँच की।

समूह गोपनीयता: वह आवश्यकता जो अधिकांश डिज़ाइन भूल जाते हैं

कई सिस्टम प्रस्तुति के भीतर चुनिंदा प्रकटीकरण का ढिंढोरा पीटते हैं, फिर चुपचाप स्थिति लुकअप की गोपनीयता को अनदेखा कर देते हैं। यह एक महत्वपूर्ण कमी है।

EUDI की गोपनीयता आवश्यकताएँ निर्दिष्ट करती हैं कि:

• स्टेटस लिस्ट में सूचकांक यादृच्छिक रूप से असाइन किए जाने चाहिए, ताकि सूचकांक स्वयं कभी भी ट्रैकिंग सिग्नल न बन जाए।
• प्रत्येक सूची में समूह गोपनीयता सुनिश्चित करने के लिए पर्याप्त बड़ी संख्या में क्रेडेंशियल होने चाहिए।
• यदि कोई सूची अन्यथा बहुत छोटी होगी, तो प्रदाताओं को वास्तविक क्रेडेंशियल संख्या को अस्पष्ट करने के लिए अप्रयुक्त प्रविष्टियाँ जोड़नी चाहिए।

एक भावी IDP केवल चुनिंदा प्रकटीकरण की ताकत पर गोपनीयता-संरक्षित होने का दावा नहीं कर सकता। यदि निरस्तीकरण तंत्र प्रस्तुति घटना को लीक करता है, तो गोपनीयता डिज़ाइन अधूरा है।

ऑफ़लाइन संचालन एक सीमांत मामला नहीं है — यह एक मूल आवश्यकता है

कोई भी यात्रा प्रणाली जो पूर्ण कनेक्टिविटी मानती है, खराब डिज़ाइन की गई है।

• AAMVA पुष्टि करता है कि डिवाइस रिट्रीवल धारक डिवाइस और रीडर दोनों के लिए बाहरी कनेक्टिविटी के बिना काम करता है, और ISO/IEC 18013-5 के लिए mDL को डिवाइस रिट्रीवल का समर्थन करना आवश्यक है।
• EUDI स्वीकार करता है कि भरोसेमंद पक्ष ऑफ़लाइन हो सकते हैं और उनके पास कैश की गई स्टेटस लिस्ट नहीं हो सकती, जिस स्थिति में यह निर्णय लेने से पहले जोखिम विश्लेषण की सिफ़ारिश करता है।

इस समझौते को जल्दी स्वीकार करें:

आप एक साथ पूर्ण ऑफ़लाइन संचालन और पूर्ण वास्तविक-समय ताज़गी नहीं पा सकते।

कोई भी आर्किटेक्चर जो बिना समझौते के दोनों का वादा करे, या तो अस्पष्ट है या चुपचाप निगरानी को पुनः प्रस्तुत कर रहा है। सही प्रतिक्रिया ताज़गी को एक नीति इनपुट बनाना है, न कि एक सार्वभौमिक नेटवर्क निर्भरता।

लॉग वह जगह है जहाँ गोपनीयता चुपचाप विफल होती है

यहाँ तक कि एक उत्कृष्ट स्थिति आर्किटेक्चर को भी लापरवाह लॉगिंग से नुकसान पहुँच सकता है।

• EUDI के लिए भरोसेमंद-पक्ष उदाहरणों को अनूठे तत्वों और टाइमस्टैंप को जैसे ही उनकी आवश्यकता न रहे, त्यागने और उन्हें अग्रेषित करने से मना करने की आवश्यकता होती है।
• AAMVA हितधारकों को mDL धारकों या mDL उपयोग को ट्रैक करने से प्रतिबंधित करता है सिवाय जहाँ कानून द्वारा आवश्यक हो, जारी करने वाले अधिकारियों को स्थिर या दीर्घकालिक मेटाडेटा के साझाकरण को न्यूनतम करने की आवश्यकता होती है, और गतिविधि-लॉग पहुँच को धारक तक सीमित करता है।
• AAMVA यह भी आवश्यक करता है कि ऑन-डिवाइस हटाने से लॉग जानकारी और मेटाडेटा हटाए जो उपयोग इतिहास प्रकट कर सकते हैं — और यह हटाना ऑफ़लाइन भी संभव होना चाहिए।

यह प्रोटोकॉल व्यवहार है, प्रशासनिक गृहव्यवस्था नहीं। एक भावी IDP को दीर्घकालिक पहचानकर्ताओं, टाइमस्टैंप और लॉग को संभावित ट्रैकिंग उपकरण के रूप में मानना चाहिए जब तक कि स्पष्ट रूप से अन्यथा सिद्ध न हो।

भावी IDP के लिए एक ठोस नो-कॉल-होम आर्किटेक्चर

सिद्धांतों को एक साथ रखते हुए, यहाँ बताया गया है कि सिस्टम को वास्तव में क्या करना चाहिए:

1. डिवाइस-बाउंड बेस क्रेडेंशियल जारी करें। क्रेडेंशियल को वॉलेट के सुरक्षित वातावरण में संरक्षित कुंजियों से बाँधें — EUDI के तहत PID और ISO/IEC 18013-5 अटेस्टेशन के लिए अनिवार्य।
2. केवल वही माँगें जो आवश्यक है, एक ताज़ी चुनौती के साथ। OpenID4VP लेन-देन में, एक DCQL क्वेरी वॉलेट को धारक को दिखाने देती है कि कौन-से एट्रिब्यूट माँगे जा रहे हैं, और सत्यापनकर्ता रीप्ले रोकने के लिए एक चुनौती जारी करता है (NIST के वर्तमान mDL आर्किटेक्चर के अनुसार)।
3. एक अल्पकालिक प्रस्तुति जनरेट करें, न कि पुन: उपयोगी पहचानकर्ता। प्रत्येक प्रस्तुति सत्यापनकर्ता, अनुरोध और क्षण के लिए विशिष्ट होनी चाहिए।
4. प्रामाणिकता स्थानीय रूप से सत्यापित करें। जारीकर्ता हस्ताक्षर और सार्वजनिक कुंजियों को ऑफ़लाइन सत्यापित करें; AAMVA की ट्रस्ट सेवा ठीक इसी के लिए बनाई गई है।
5. कैश की गई, अलग से रिफ़्रेश की गई सूचियों से स्थिति जाँचें। जहाँ क्रेडेंशियल निरस्तीकरण को छोड़ने के लिए बहुत अधिक समय तक वैध हों, वहाँ उपयोगकर्ता प्रस्तुतियों से असंबंधित एक कार्यक्रम पर रिफ़्रेश की गई स्थानीय कैश स्थिति सूचियों का उपयोग करें।
6. जब ताज़गी उपलब्ध न हो तो जोखिम नीति लागू करें। ऑफ़लाइन निर्णयों को स्पष्ट सत्यापनकर्ता नीति बनाएँ, असंरचित अनुमान नहीं।
7. ट्रैकिंग डेटा आक्रामक रूप से हटाएँ। लेन-देन-अनूठे तत्वों और टाइमस्टैंप को जब आवश्यकता न हो तब त्यागें; ऐसे लॉग न रखें जो आंदोलन इतिहास को पुनर्निर्मित कर सकें।

एक गंभीर नो-कॉल-होम आर्किटेक्चर ऐसा दिखता है — स्तरित, गोपनीयता-संरक्षित, क्रिप्टोग्राफ़िक रूप से स्थानीय, और ऑफ़लाइन वास्तविकता के बारे में परिचालन रूप से ईमानदार।

तीन पैटर्न जिन्हें डिज़ाइन द्वारा प्रतिबंधित किया जाना चाहिए

एक परिपक्व भावी IDP इकोसिस्टम को इन्हें अनुकूलन विकल्प नहीं, बल्कि आर्किटेक्चरल विफलताओं के रूप में देखना चाहिए:

• हर प्रस्तुति पर अनिवार्य जारीकर्ता कॉलबैक। AAMVA की अपनी गोपनीयता मार्गदर्शिका बताती है कि यह हानिकारक क्यों है।
• ड्राइविंग क्रेडेंशियल को नियमित लॉगिन के रूप में उपयोग करना। NIST स्पष्ट रूप से दैनिक प्रमाणीकरण के लिए पहचान-वाहक क्रेडेंशियल को बार-बार प्रस्तुत करने के खिलाफ चेतावनी देता है।
• ऐसे पहचानकर्ताओं, टाइमस्टैंप और लॉग को बनाए रखना जो प्रस्तुति इतिहास का पुनर्निर्माण कर सकते हैं। EUDI और AAMVA दोनों इसके विपरीत की आवश्यकता करते हैं।

एक वाक्य में मूल तर्क

तत्काल सत्यापन जारीकर्ता-साइड निगरानी की अनुमति नहीं बन सकता।

एक भावी IDP को सक्षम होना चाहिए:

• प्रामाणिकता स्थानीय रूप से सिद्ध करना।
• कब्ज़ा स्थानीय रूप से सिद्ध करना।
• ताज़गी निजी तौर पर जाँचना।
• ऑफ़लाइन वास्तविकता को सहन करना।
• जब पूर्ण जानकारी उपलब्ध न हो तब सुचारू रूप से काम करना।

इनमें से कोई भी सिस्टम को कमज़ोर नहीं बनाता। यह इसे बड़े पैमाने पर तैनात करने योग्य बनाता है।

जिस क्षण एक ड्राइविंग क्रेडेंशियल यह रिकॉर्ड करने का उपकरण बन जाता है कि किसने क्या, कहाँ और कब दिखाया, वह कागज़ का सुरक्षित संस्करण नहीं रहता। यह अवलोकन के लिए बुनियादी ढाँचा बन जाता है।

भावी IDP को ठीक यही बनने से इनकार करना चाहिए।

अक्सर पूछे जाने वाले प्रश्न

“कॉल-होम सत्यापन” क्या है?
यह कोई भी डिज़ाइन है जिसमें एक सत्यापनकर्ता क्रेडेंशियल को मान्य करने के लिए वास्तविक समय में जारीकर्ता से संपर्क करता है। हालाँकि यह एक साथ प्रामाणिकता और निरस्तीकरण को हल करता है, यह जारीकर्ता को हर प्रस्तुति घटना का निरीक्षण करने की भी अनुमति देता है।

क्या ISO/IEC 18013-5 के लिए ऑनलाइन जारीकर्ता संपर्क की आवश्यकता है?
नहीं। AAMVA पुष्टि करता है कि ISO/IEC 18013-5 डिवाइस रिट्रीवल के लिए समर्थन की आवश्यकता है और केवल वैकल्पिक रूप से सर्वर रिट्रीवल की अनुमति देता है।

जारीकर्ता से संपर्क किए बिना निरस्तीकरण कैसे काम कर सकता है?
अल्पकालिक क्रेडेंशियल, अटेस्टेशन स्टेटस लिस्ट, या अटेस्टेशन रिवोकेशन लिस्ट के माध्यम से — आदर्श रूप से भरोसेमंद पक्ष उपयोगकर्ता प्रस्तुतियों से अलग स्थिति डेटा डाउनलोड करता है।

स्टेटस लिस्ट के लिए “समूह गोपनीयता” महत्वपूर्ण क्यों है?
यदि कोई स्टेटस लिस्ट बहुत छोटी है या उसके सूचकांक अनुमानित हैं, तो एक स्थिति अनुरोध यह उजागर कर सकता है कि कौन-सा विशिष्ट क्रेडेंशियल अभी प्रस्तुत किया गया था। यादृच्छिक सूचकांक और बड़ी सूचियाँ इसे रोकती हैं।

क्या ऑफ़लाइन सत्यापन वास्तव में व्यावहारिक है?
हाँ — और AAMVA और EUDI सहित मानक निकाय स्पष्ट रूप से इसकी आवश्यकता करते हैं। समझौता यह है कि पूर्ण वास्तविक-समय ताज़गी पूर्ण ऑफ़लाइन संचालन के साथ असंगत है, इसलिए ताज़गी को एक नीति निर्णय बनना होगा, न कि एक कठोर निर्भरता।