पुलिस, किराया डेस्क, नियोक्ता, बीमाकर्ता: वे एक ही डेटा क्यों नहीं देख सकते

भविष्य के अंतर्राष्ट्रीय ड्राइविंग परमिट (आईडीपी) में सबसे बड़ी डिज़ाइन की गलती यह होगी कि हर सत्यापनकर्ता को एक जैसा माना जाए। एक पुलिस अधिकारी, एक कार किराया डेस्क, एक नियोक्ता और एक बीमाकर्ता एक ही सवाल नहीं पूछते — इसलिए उन्हें एक जैसा उत्तर नहीं मिलना चाहिए।

एक चालक। ड्राइव करने का एक अंतर्निहित अधिकार। एक वॉलेट। लेकिन चार बिल्कुल अलग सत्यापनकर्ता:

• सड़क किनारे एक पुलिस अधिकारी
• वाहन लेते समय एक कार किराया डेस्क
• फ्लीट पात्रता जाँचने वाला एक नियोक्ता
• दावे की समीक्षा करने वाला एक बीमाकर्ता

यदि भविष्य का आईडीपी चारों को एक जैसा डेटा दिखाता है, तो यह प्रणाली पहले से ही विफल हो चुकी है। इसलिए नहीं कि क्रेडेंशियल असुरक्षित है, बल्कि इसलिए कि प्रकटीकरण का मॉडल बहुत सरल है।

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

भौतिक कार्ड ने हमें गलत सोचना क्यों सिखाया

एक भौतिक लाइसेंस ने हमें सब-कुछ दिखाने के दृष्टिकोण में प्रशिक्षित किया। आप कार्ड सौंपते हैं। दूसरा व्यक्ति देखता है कि कार्ड पर क्या है। बस यही पूरी बातचीत है।

यह दृष्टिकोण कागज़ की दुनिया में स्वीकार्य है क्योंकि कोई विकल्प नहीं है। यह डिजिटल दुनिया में अस्वीकार्य हो जाता है।

W3C वीसी डेटा मॉडल 2.0 सीधे कहता है: एक ड्राइवर के लाइसेंस में आईडी नंबर, ऊँचाई, वजन, जन्मतिथि और घर का पता हो सकता है — लेकिन फिर भी यह किसी दिए गए लेनदेन के लिए आवश्यकता से कहीं अधिक हो सकता है। वर्तमान मानकों के मुख्य बिंदु:

• W3C की सर्वोत्तम प्रथा: चयनात्मक प्रकटीकरण का समर्थन करें, और केवल वही माँगें जो सख्त रूप से आवश्यक हो
• यूरोपीय संघ का डेटा-संरक्षण मार्गदर्शन: प्रसंस्करण निर्दिष्ट उद्देश्यों तक सीमित होना चाहिए, और संसाधित डेटा आवश्यक और आनुपातिक होना चाहिए
• भविष्य के आईडीपी का पहला सिद्धांत: एक ही क्रेडेंशियल का अर्थ यह नहीं कि निरीक्षण का समान अधिकार

सही मॉडल नीति-आधारित प्रकटीकरण है

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

NIST SP 800-205 पहुँच-नियंत्रण निर्णयों को विषय, वस्तु, अनुरोधित ऑपरेशन और पर्यावरणीय स्थितियों से जुड़े गुणों के मूल्यांकन के रूप में नीति के विरुद्ध परिभाषित करता है। भविष्य के आईडीपी के लिए यही सही संरचना है:

• विषय: चालक
• वस्तु: अनुरोधित डेटा फ़ील्ड
• कार्रवाई: अमूर्त रूप से “लाइसेंस देखें” नहीं, बल्कि कुछ विशिष्ट जैसे “सड़क किनारे श्रेणी बी चलाने की पात्रता सत्यापित करें” या “बुकिंग के लिए किराया पात्रता सत्यापित करें”
• पर्यावरण: सड़क किनारे, किराया डेस्क, दूरस्थ पूर्व-जाँच, फ्लीट ऑनबोर्डिंग, और हानि-पश्चात दावा समीक्षा अलग-अलग परिवेश हैं और अलग-अलग निर्णयों की ओर ले जाने चाहिए

NIST यह भी नोट करता है कि विशेषता प्रणालियों को दानेदारपन, प्रशासन, और विशेषताओं की कमी, समूहीकरण और न्यूनीकरण के तंत्र की आवश्यकता है।

इसलिए भविष्य के आईडीपी को यह नहीं पूछना चाहिए: क्या यह सत्यापनकर्ता लाइसेंस पढ़ सकता है? इसे पूछना चाहिए: इस सत्यापनकर्ता को किस इरादे से उपयोग के लिए, इस परिवेश में, किन प्रतिधारण नियमों के साथ, कौन से दावे मिल सकते हैं?

एक सत्यापनकर्ता को कुछ भी माँगने से पहले अपनी पहचान बतानी चाहिए

भविष्य के आईडीपी की शुरुआत वॉलेट द्वारा डेटा दिखाने से नहीं होनी चाहिए। इसकी शुरुआत सत्यापनकर्ता द्वारा यह साबित करने से होनी चाहिए कि वह कौन है।

EUDI वास्तुकला इस पर स्पष्ट है। भरोसेमंद पक्षों को अवश्य:

• यह पंजीकृत करना होगा कि वे किन विशेषताओं का अनुरोध करने का इरादा रखते हैं और किस उद्देश्य के लिए
• पहुँच प्रमाण-पत्र प्राप्त करने होंगे
• किसी भी प्रकटीकरण से पहले वॉलेट से प्रमाणित होना होगा
• जहाँ पंजीकरण जानकारी उपलब्ध हो, वहाँ उनके पंजीकृत दायरे के विरुद्ध जाँचा जाना होगा

उपयोगकर्ता तब देख सकता है कि कौन पूछ रहा है, क्या माँगा जा रहा है, और क्या अनुरोध पंजीकृत दायरे के भीतर है।

ETSI का वर्तमान वॉलेट-भरोसेमंद-पक्ष प्रमाण-पत्र कार्य इसे और अधिक ठोस बनाता है। एक वॉलेट-भरोसेमंद-पक्ष पंजीकरण प्रमाण-पत्र भरोसेमंद पक्ष के इच्छित उपयोग और उसके अनुरोध करने के लिए पंजीकृत विशेषताओं का वर्णन कर सकता है। संबंधित पहुँच प्रमाण-पत्र यह सुनिश्चित करने के लिए मौजूद है कि अनुरोध एक वैध, अधिकृत पक्ष से आता है। ETSI में भरोसेमंद-पक्ष मेटाडेटा भी शामिल है जैसे:

• व्यापार का नाम
• समर्थन यूआरआई
• इच्छित उपयोग
• पात्रताएँ
• रजिस्ट्री यूआरआई
• पर्यवेक्षी-प्राधिकरण जानकारी

भविष्य के आईडीपी का दूसरा सिद्धांत: कोई सत्यापनकर्ता पहचान नहीं, तो कोई प्रकटीकरण नहीं।

सहमति स्क्रीन पर्याप्त क्यों नहीं हैं

यहाँ एक और गलती है: उपयोगकर्ता की मंज़ूरी को कानूनी वैधता के समान मानना।

EUDI वास्तुकला स्पष्ट रूप से कहती है कि विशेषताओं को प्रस्तुत करने के लिए उपयोगकर्ता की मंज़ूरी को भरोसेमंद पक्ष के व्यक्तिगत डेटा के प्रसंस्करण के लिए वैध आधार नहीं माना जाना चाहिए। भरोसेमंद पक्ष के पास अभी भी अपना वैध आधार होना चाहिए। EUDI को सभी उपयोग-मामलों में उपयोगकर्ता की मंज़ूरी की भी आवश्यकता है, जिसमें वे मामले भी शामिल हैं जहाँ भरोसेमंद पक्ष कानून प्रवर्तन या किसी अन्य सरकारी एजेंसी का हिस्सा हो सकता है।

एक अच्छा वॉलेट इंटरफ़ेस मदद कर सकता है, लेकिन यह अकेले सत्यापनकर्ता की अतिरेकता को हल नहीं कर सकता। नियम इंटरफ़ेस से पहले मौजूद होना चाहिए।

इसलिए भविष्य के आईडीपी को दोनों की आवश्यकता है:

• क्रिप्टोग्राफिक सत्यापनकर्ता प्रमाणीकरण यह पुष्टि करने के लिए कि कौन पूछ रहा है
• नीति बाधाएँ इस बारे में कि उस सत्यापनकर्ता श्रेणी को क्या अनुरोध करने की अनुमति है

दोनों के बिना, “उपयोगकर्ता की पसंद” नीति की विफलता को व्यक्ति पर डालने का एक तरीका बन जाती है।

1. पुलिस: पूरे व्यक्ति को नहीं, ड्राइव करने के अधिकार को सत्यापित करें

पुलिस का सड़क किनारे का परिदृश्य सबसे केंद्रित है।

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

• क्या यह व्यक्ति धारक है?
• क्या क्रेडेंशियल वैध है?
• कौन सी वाहन पात्रताएँ और प्रतिबंध लागू होते हैं?

डिफ़ॉल्ट रूप से अनुमत:

• नाम
• चित्र
• लाइसेंस की स्थिति
• जारी करने और समाप्ति की तारीखें
• श्रेणियाँ
• ड्राइविंग-संबंधित प्रतिबंध
• जारीकर्ता और क्षेत्राधिकार
• ताज़गी/स्थिति परिणाम

डिफ़ॉल्ट रूप से अनुमत नहीं:

• घर का पता
• आंतरिक पहचानकर्ता जो सड़क किनारे उपयोग के लिए आवश्यक नहीं
• अन्य प्रमाणीकरणों से असंबंधित विशेषताएँ
• ऐतिहासिक प्रस्तुति लॉग
• व्यावसायिक मेटाडेटा

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

पुलिस का मामला राज्य को सब कुछ प्राप्त करने के बारे में नहीं है। यह राज्य को सड़क किनारे प्रवर्तन के लिए आवश्यक ड्राइविंग-विशिष्ट डेटा प्राप्त करने के बारे में है। यह एक महत्वपूर्ण अंतर है।

2. किराया डेस्क: पात्रता, पहचान मिलान, और कुछ भी अनावश्यक नहीं

किराए का मामला अधिक विस्तृत है क्योंकि वास्तव में दो क्षण होते हैं: आगमन से पहले दूरस्थ पूर्व-जाँच, और जब कोई व्यक्ति या कियोस्क चाबियाँ सौंपता है तब पिकअप।

यूरोपीय संघ की एमडीएल मैनुअल दोनों को पहले से ही मॉडल करती है। एक कार-किराया सेवा बुकिंग के दौरान पहचान के प्रमाण के साथ एमडीएल का अनुरोध कर सकती है, प्रमाणीकरणों को मान्य कर सकती है, और बाद में वाहन जारी करने से पहले पिकअप पर व्यक्तिगत रूप से ग्राहक को सत्यापित कर सकती है। उपयोगकर्ता व्यक्तिगत रूप से या अग्रिम में दूरस्थ रूप से कार-किराया कंपनियों के साथ अपने एमडीएल साझा कर सकते हैं।

किराया डेस्क को मुख्य रूप से किसी घटना की जाँच करने की आवश्यकता नहीं है। इसे निर्णय लेने की आवश्यकता है: क्या मैं इस बुकिंग और नीति के तहत इस ग्राहक को यह वाहन किराए पर दे सकता हूँ?

दूरस्थ पूर्व-जाँच में शामिल होना चाहिए:

• पहचान लिंकेज
• चित्र या समकक्ष पहचान-बाइंडिंग तत्व
• संबंधित वाहन श्रेणी
• जारी करने और समाप्ति की तारीखें
• वर्तमान वैधता
• संभवतः आयु सीमा या आयु बैंड

पिकअप में पुष्टि होनी चाहिए:

• धारक वही व्यक्ति है जिसने पूर्व-जाँच पूरी की
• वर्तमान वैधता
• संबंधित पात्रताएँ

डिफ़ॉल्ट रूप से आवश्यक नहीं:

• पूरा घर का पता जब बुकिंग प्रोफ़ाइल में पहले से संपर्क विवरण हो
• पूरी जन्म तारीख जहाँ आयु-ओवर या आयु-बैंड पर्याप्त हो
• असंबंधित पहचान विशेषताएँ
• यदि कोई बुकिंग प्रमाणीकरण पहले से मौजूद है तो पूरे क्रेडेंशियल की बार-बार पुनः-प्रस्तुति

NIST की वर्तमान एमडीएल वास्तुकला दिखाती है कि भरोसेमंद पक्ष केवल आवश्यक विशेषताओं का अनुरोध करने के लिए DCQL का उपयोग करता है, और स्पष्ट रूप से कहता है कि यह अनुरोध को एकल इकाई के रूप में क्रेडेंशियल मानने के बजाय संरचित करके डेटा न्यूनीकरण और धारक सहमति का समर्थन करता है। AAMVA जोड़ता है कि एप्लिकेशन को स्पष्ट रूप से दिखाना चाहिए कि कौन सा डेटा अनुरोध किया गया था और क्या सत्यापनकर्ता जानकारी बनाए रखने का इरादा रखता है।

3. नियोक्ता: एक सत्यापनकर्ता श्रेणी, पूर्ण पहचान में प्रवेश नहीं

W3C का अवलोकन विश्वविद्यालय की डिग्री की जाँच करने वाली नियोक्ता की डिजिटल प्रणाली को सत्यापनकर्ता उदाहरण के रूप में उपयोग करता है। यह हमें याद दिलाता है कि नियोक्ता सत्यापन क्रेडेंशियल पारितंत्रों में पहले से ही एक मान्यता प्राप्त पैटर्न है।

एक नियोक्ता या फ्लीट ऑपरेटर को वैध रूप से जानने की आवश्यकता हो सकती है:

• क्या कोई कर्मचारी वर्तमान में कुछ वाहन श्रेणियाँ चलाने का हकदार है
• क्या प्रमुख प्रतिबंध मौजूद हैं
• क्या पात्रता वैध रहती है

यह एक वास्तविक व्यावसायिक आवश्यकता है। लेकिन यह स्वचालित रूप से पूरे ड्राइविंग क्रेडेंशियल, पूर्ण पहचान डेटा, या बार-बार प्रस्तुतियों की निरंतर धारा तक स्थायी पहुँच को उचित नहीं ठहराता।

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

भविष्य का आईडीपी कार्यस्थल पहुँच बैज नहीं बनना चाहिए।

नियोक्ता और फ्लीट उपयोग के लिए, सही पैटर्न आमतौर पर है:

• नौकरी-संबंधित पात्रता जाँच
• शायद एक आवधिक अनुपालन प्रमाणीकरण
• शायद यह दावा कि धारक निर्दिष्ट श्रेणियों के लिए वैध रहता है
• लेकिन हर बार जब कर्मचारी किसी सिस्टम में साइन इन करता है या शिफ्ट शुरू करता है तो सभी लाइसेंस डेटा का डिफ़ॉल्ट स्थानांतरण नहीं

फ्लीट अनुपालन एक अलग भरोसेमंद-पक्ष श्रेणी है, जिसमें एक अलग इच्छित उपयोग और एक अलग प्रकटीकरण प्रोफ़ाइल है।

4. बीमाकर्ता: दावे निरंतर दृश्यता की अनुमति नहीं हैं

बीमा का मामला अक्सर वास्तविक होता है। यूरोपीय संघ की एमडीएल उपयोग-मामले सामग्री में, बीमाकर्ता अप्रत्यक्ष रूप से किराए के परिदृश्य में प्रकट होते हैं: बीमा कंपनियाँ कार-किराया कंपनियों से यह जाँचने की आवश्यकता होती है कि कार किराए पर लेने वाले व्यक्ति को ड्राइव करने का अधिकार है। बीमा पहले से ही ड्राइविंग-सत्यापन प्रवाह को प्रभावित करती है।

लेकिन इसका मतलब यह नहीं कि एक बीमाकर्ता को पुलिस के समान डेटा, या क्रेडेंशियल तक स्थायी पहुँच का अधिकार मिलना चाहिए।

भविष्य का आईडीपी बीमाकर्ताओं को एक अलग सत्यापनकर्ता श्रेणी के रूप में, अलग-अलग इच्छित उपयोगों के साथ मानना चाहिए:

• हामीदारी
• किराया-जोखिम सत्यापन
• हानि-पश्चात दावा प्रबंधन
• धोखाधड़ी समीक्षा

ये एक ही उद्देश्य नहीं हैं। यूरोपीय संघ के डेटा-संरक्षण सिद्धांतों के तहत, व्यक्तिगत डेटा को निर्दिष्ट उद्देश्यों के लिए एकत्र किया जाना चाहिए और उस उद्देश्य के लिए आवश्यक और आनुपातिक तक सीमित होना चाहिए। W3C का वीसी मार्गदर्शन तकनीकी रूप से उसी निष्कर्ष पर पहुँचता है: सत्यापनकर्ताओं को केवल वही माँगना चाहिए जो सख्त रूप से आवश्यक हो।

वैध, घटना-विशिष्ट उदाहरण:

• प्रमाण कि संबंधित समय पर लाइसेंस वैध था
• संबंधित वाहन पात्रता का प्रमाण
• दावे के लिए आवश्यक होने पर पहचान लिंकेज का प्रमाण
• दावा-विशिष्ट प्रकटीकरण

डिफ़ॉल्ट रूप से अनुमत नहीं:

• अंतर्निहित क्रेडेंशियल तक स्थायी पहुँच
• हर बार जब ग्राहक बीमाकर्ता के साथ बातचीत करता है तो बार-बार सामान्य सत्यापन
• ड्राइविंग क्रेडेंशियल का लॉगिन टोकन के रूप में उपयोग
• असंबंधित विशेषताओं का संग्रह

एक ड्राइविंग क्रेडेंशियल निगरानी सदस्यता नहीं है। और इसे चुपचाप एक नहीं बनना चाहिए।

मध्यस्थ दृश्यमान क्यों होने चाहिए

वास्तविक बाज़ारों में मध्यस्थ शामिल होते हैं। किराया प्लेटफ़ॉर्म, फ्लीट विक्रेता, नियोक्ता एचआर सिस्टम, और बीमा दावा प्रोसेसर अक्सर तृतीय पक्षों के माध्यम से कार्य करते हैं।

EUDI वास्तुकला इसे इस तरह संभालती है:

• मध्यस्थों को भरोसेमंद पक्षों के रूप में मानना
• उन्हें पंजीकरण की आवश्यकता
• मध्यस्थ भरोसेमंद पक्ष के लिए अनुरोधित विशेषताओं के पंजीकृत होने की आवश्यकता
• उपयोगकर्ता को मध्यस्थ और अंतिम भरोसेमंद पक्ष दोनों दिखाना
• मध्यस्थों को लेनदेन की सामग्री के बारे में डेटा संग्रहीत करने से रोकना

भविष्य के आईडीपी को कभी भी ऐसा पैटर्न अनुमत नहीं करना चाहिए जहाँ उपयोगकर्ता सोचता है कि वे किराया कंपनी को प्रकट कर रहे हैं, लेकिन वास्तव में वे एक अदृश्य सत्यापन दलाल, विश्लेषण प्रोसेसर, और दावा विक्रेता श्रृंखला को प्रकट कर रहे हैं।

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

प्रतिधारण पहुँच नियंत्रण का हिस्सा है

चयनात्मक प्रकटीकरण के बारे में अधिकांश चर्चाएँ बहुत जल्दी समाप्त हो जाती हैं। वे इस पर ध्यान केंद्रित करती हैं कि क्या प्रकट किया जाता है। वे इस पर पर्याप्त ध्यान नहीं देती हैं कि यह बाद में कितने समय तक रहता है।

वर्तमान मार्गदर्शन पहले से ही एकत्रित हो रहा है:

• AAMVA: वॉलेट को धारक को स्पष्ट रूप से बताना चाहिए कि कौन सा डेटा अनुरोध किया गया था और क्या सत्यापनकर्ता इसे बनाए रखने का इरादा रखता है; हितधारकों को कानून द्वारा आवश्यक होने के अलावा धारकों या एमडीएल उपयोग को ट्रैक नहीं करना चाहिए
• W3C: धारक सॉफ़्टवेयर को सत्यापनकर्ताओं के साथ साझा की गई जानकारी के लॉग प्रदान करने चाहिए, ताकि अत्यधिक अनुरोधों की पहचान की जा सके
• EUDI: उपयोगकर्ताओं को लेनदेन लॉग तक पहुँचने, संदिग्ध अनुरोधों की रिपोर्ट करने और विलोपन का अनुरोध करने में सक्षम होना चाहिए

प्रतिधारण वर्ग को स्वयं प्रकटीकरण नीति का हिस्सा होना चाहिए:

• पुलिस सड़क किनारे: वैध परिचालन रिकॉर्ड से परे डिफ़ॉल्ट रूप से कोई प्रतिधारण नहीं
• किराया पूर्व-जाँच: बुकिंग से जुड़ा लेनदेन रिकॉर्ड, पुन: उपयोग योग्य पहचान प्रति नहीं
• नियोक्ता फ्लीट अनुपालन: अनुपालन रिकॉर्ड या प्रमाणीकरण परिणाम, कच्चा क्रेडेंशियल डेटा नहीं
• बीमाकर्ता दावा: दावे तक सीमित दावा रिकॉर्ड, स्थायी पहुँच नहीं

जो भविष्य का आईडीपी प्रतिधारण को नज़रअंदाज़ करता है वह केवल आंशिक रूप से गोपनीयता-संरक्षण कर रहा है।

वॉलेट को वास्तव में क्या निर्णय लेना चाहिए

यदि मुझे इस पूरे लेख को एक कार्यान्वयन नियम में सीमित करना होता, तो यह होता:

वॉलेट को “क्या मैं यह क्रेडेंशियल प्रस्तुत कर सकता हूँ?” का उत्तर नहीं देना चाहिए। इसे उत्तर देना चाहिए “क्या मैं इस प्रमाणित सत्यापनकर्ता को, इस इच्छित उपयोग के लिए, इस संदर्भ में, इस प्रतिधारण वर्ग के तहत, दावों का यह सेट प्रस्तुत कर सकता हूँ?”

वह निर्णय कम से कम इन इनपुट द्वारा संचालित होना चाहिए:

• सत्यापनकर्ता पहचान
• सत्यापनकर्ता श्रेणी
• इच्छित उपयोग
• पंजीकृत विशेषता दायरा
• जारीकर्ता से प्रकटीकरण नीति, यदि मौजूद हो
• परिवेश (सड़क किनारे, पिकअप, दूरस्थ, फ्लीट, दावा)
• धारक की मंज़ूरी
• लागू प्रतिधारण नीति

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

मूल तर्क

भविष्य के आईडीपी को यह नहीं पूछना चाहिए कि क्या डेटा प्रकट किया जा सकता है। इसे पूछना चाहिए:

• कौन पूछ रहा है?
• किस उद्देश्य के लिए?
• किस अधिकार के तहत?
• किस संदर्भ में?
• किस प्रतिधारण परिणाम के साथ?

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

यह अनावश्यक जटिलता नहीं है। यही एक आधुनिक ड्राइविंग क्रेडेंशियल दिखता है जब यह हर सत्यापनकर्ता को एक जैसा मानना बंद कर देता है।