प्रहरी, भाडा काउन्टर, रोजगारदाता, बीमाकर्ता: किन तिनीहरूले एउटै डेटा देख्नु हुँदैन

भविष्यको अन्तर्राष्ट्रिय ड्राइभिङ अनुमतिपत्र (IDP) को सबैभन्दा ठूलो डिजाइन गल्ती हुनेछ — प्रत्येक प्रमाणकर्तालाई एउटै प्रमाणकर्ता ठान्नु। एक प्रहरी अधिकारी, एउटा गाडी भाडा काउन्टर, एउटा रोजगारदाता, र एउटा बीमाकर्ता एउटै प्रश्न सोध्दैनन् — त्यसैले तिनीहरूले एउटै उत्तर पाउनु हुँदैन।

एक चालक। सवारी चलाउने एउटा मूल अधिकार। एउटा वालेट। तर चार बिल्कुल फरक प्रमाणकर्ता:

• सडकमा खटिएको प्रहरी अधिकारी
• गाडी बुझ्ने बेलाको भाडा काउन्टर
• फ्लीट पात्रता जाँच्ने रोजगारदाता
• दाबी समीक्षा गर्ने बीमाकर्ता

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

मानकहरूको समुदाय त्यो सरल मोडेलबाट पहिले नै टाढिइसकेको छ। W3C को प्रमाणयोग्य-प्रमाणपत्र कार्यले जारीकर्ता, धारक र प्रमाणकर्ताको वरिपरिको पारिस्थितिकी तन्त्र वर्णन गर्छ, रोजगारदाता र वेबसाइटलाई प्रमाणकर्ताका उदाहरणका रूपमा प्रयोग गरेर। युरोपेली संघ (EU) को मोबाइल ड्राइभिङ लाइसेन्स सम्बन्धी कार्यले सडक जाँच र गाडी भाडालाई छुट्टाछुट्टै प्रमाणीकरण परिदृश्यका रूपमा पहिले नै व्यवहार गर्छ, जसमा भाडाका लागि टाढाबाट अग्रिम साझेदारी र प्रहरीका लागि व्यक्तिगत जाँच समावेश छ। वास्तुकला पहिले नै धेरै प्रमाणकर्ता प्रकारका लागि डिजाइन गरिएको छ। गल्ती हुनेछ — प्रयोगकर्ता अनुभवलाई यस्तो डिजाइन गर्नु जसमा केवल एउटै प्रकार अवस्थित छ।

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

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

कागजी दुनियाँमा यो दृष्टिकोण स्वीकार्य छ किनभने विकल्प नै छैन। डिजिटल दुनियाँमा यो अस्वीकार्य बन्छ।

W3C VC डेटा मोडेल २.० ले सिधै भन्छ: ड्राइभिङ लाइसेन्समा ID नम्बर, उचाइ, तौल, जन्मदिन र घरको ठेगाना हुन सक्छ — तर त्यो अझै पनि कुनै निश्चित कारोबारका लागि आवश्यकभन्दा धेरै हुन सक्छ। वर्तमान मानकहरूका मुख्य बुँदाहरू:

• W3C उत्तम अभ्यास: चयनात्मक प्रकटीकरणलाई समर्थन गर्नु, र कडाईसँग आवश्यक भएको मात्र माग गर्नु
• EU डेटा-सुरक्षा मार्गदर्शन: प्रशोधन निर्दिष्ट उद्देश्यमा सीमित हुनुपर्छ, र प्रशोधन गरिएको डेटा आवश्यक र समानुपातिक हुनुपर्छ
• भविष्यको IDP को पहिलो सिद्धान्त: एउटै प्रमाणपत्रको अर्थ निरीक्षण गर्ने समान अधिकार होइन

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

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

NIST SP 800-205 ले पहुँच-नियन्त्रण निर्णयहरूलाई नीतिका विरुद्ध विषय, वस्तु, अनुरोधित सञ्चालन र वातावरण अवस्थाहरूसँग सम्बद्ध विशेषताहरूको मूल्यांकनका रूपमा परिभाषित गर्छ। यो भविष्यको IDP का लागि ठीक सही संरचना हो:

• विषय: चालक
• वस्तु: अनुरोध गरिएका डेटा फिल्डहरू
• कार्य: अमूर्त रूपमा “लाइसेन्स हेर्नु” होइन, बरु “सडकमा श्रेणी B चलाउने हकको प्रमाणीकरण गर्नु” वा “बुकिङका लागि भाडा पात्रता प्रमाणित गर्नु” जस्ता विशिष्ट कुरा
• वातावरण: सडक, भाडा काउन्टर, टाढाबाट अग्रिम जाँच, फ्लीट अनबोर्डिङ, र हानि-पछिको दाबी समीक्षा फरक-फरक वातावरण हुन् र फरक-फरक निर्णयतर्फ लैजानु पर्छ

NIST ले यो पनि उल्लेख गर्छ कि विशेषता प्रणालीहरूलाई विशेषताहरूको कमी, समूहीकरण र न्यूनीकरणका लागि दानेदारता, शासन र तन्त्रहरू आवश्यक छन्।

त्यसैले भविष्यको IDP ले यो सोध्नु हुँदैन: के यो प्रमाणकर्ताले लाइसेन्स पढ्न सक्छ? यसले सोध्नु पर्छ: यो प्रमाणकर्ताले कुन दाबी, कुन उद्देश्यका लागि, यस वातावरणमा, कुन अवधारण नियमसहित प्राप्त गर्न पाउँछ?

प्रमाणकर्ताले केही माग्नु अघि आफ्नो परिचय दिनु पर्छ

भविष्यको IDP वालेटले डेटा देखाउँदैन — यो प्रमाणकर्ताले आफू को हो भनेर प्रमाणित गर्नुबाट सुरु हुनु पर्छ।

EUDI वास्तुकला यसबारे स्पष्ट छ। भर-पर्ने पक्षहरूले:

• तिनीहरूले कुन विशेषताहरू माग्ने र कुन उद्देश्यका लागि भन्ने दर्ता गर्नु पर्छ
• पहुँच प्रमाणपत्र प्राप्त गर्नु पर्छ
• कुनै पनि प्रकटीकरणअघि वालेटमा प्रमाणीकरण गर्नु पर्छ
• उनीहरूको दर्ता दायरा विरुद्ध जाँचिनु पर्छ, जहाँ दर्ता जानकारी उपलब्ध छ

त्यसपछि प्रयोगकर्ताले को सोधिरहेको छ, के सोधिएको छ, र अनुरोध दर्ता दायरा भित्र छ कि छैन हेर्न सक्छ।

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

• व्यापार नाम
• समर्थन URI
• अभिप्रेत उपयोग
• अधिकारहरू
• रेजिस्ट्री URI
• पर्यवेक्षी-प्राधिकरण जानकारी

भविष्यको IDP को दोस्रो सिद्धान्त: प्रमाणकर्ताको पहिचान नभई, प्रकटीकरण नहोस्।

किन सहमति स्क्रिनहरू पर्याप्त छैनन्

यहाँ अर्को गल्ती पनि छ: प्रयोगकर्ताको अनुमोदनलाई कानुनी वैधतासँग एउटै कुरा ठान्नु।

EUDI वास्तुकला स्पष्ट रूपमा भन्छ कि विशेषताहरू प्रस्तुत गर्न प्रयोगकर्ताको अनुमोदनलाई भर-पर्ने पक्षको व्यक्तिगत डेटा प्रशोधनको कानुनी आधारका रूपमा व्यवहार गरिनु हुँदैन। भर-पर्ने पक्षसँग अझै पनि आफ्नै कानुनी आधार हुनु पर्छ। EUDI ले कानून प्रवर्तन वा अर्को सरकारी एजेन्सीको हिस्सा हुन सक्ने भर-पर्ने पक्ष भएका मुद्दाहरू सहित सबै प्रयोग मामलाहरूमा प्रयोगकर्ता अनुमोदन आवश्यक गर्छ।

एउटा राम्रो वालेट इन्टरफेसले मद्दत गर्न सक्छ, तर यसले एक्लै प्रमाणकर्ताको अतिक्रमण समाधान गर्न सक्दैन। नियम इन्टरफेसभन्दा पहिले नै अवस्थित हुनु पर्छ।

त्यसैले भविष्यको IDP लाई दुवै चाहिन्छ:

• क्रिप्टोग्राफिक प्रमाणकर्ता प्रमाणीकरण को सोधिरहेको छ भनेर पुष्टि गर्न
• नीति अवरोधहरू त्यो प्रमाणकर्ता श्रेणीले के माग्न पाउँछ भन्नेमा

दुवै बिना, “प्रयोगकर्ता छनौट” नीतिको असफलतालाई व्यक्तिमाथि थोपार्ने तरिका बन्छ।

१. प्रहरी: सवारी चलाउने अधिकार प्रमाणित गर्नु, सम्पूर्ण व्यक्ति होइन

प्रहरी सडक परिदृश्य सबैभन्दा केन्द्रित हो।

EU mDL म्यानुअलले यसलाई सिधै वर्णन गर्छ: प्रहरी वा अन्य अधिकारीहरूले आवश्यक परेमा लाइसेन्स जाँच गर्छन्, लाइसेन्सको वैधता र सवारी अधिकारहरू सहित। प्रयोगकर्ता यात्रामा, अधिकारीले QR-ट्रिगर गरिएको प्रवाह, ब्लुटुथ, Wi-Fi Aware, वा NFC मार्फत लाइसेन्स प्रमाणित गर्छ। यो एक केन्द्रित प्रमाणीकरण कार्य हो:

• के यो व्यक्ति धारक हो?
• के प्रमाणपत्र वैध छ?
• कुन सवारी अधिकारहरू र प्रतिबन्धहरू लागू हुन्छन्?

पूर्वनिर्धारितरूपमा अनुमति दिइएको:

• नाम
• तस्बिर
• लाइसेन्स स्थिति
• जारी र म्याद समाप्ति मितिहरू
• श्रेणीहरू
• सवारी-सम्बन्धित प्रतिबन्धहरू
• जारीकर्ता र क्षेत्राधिकार
• ताजापन/स्थिति परिणाम

पूर्वनिर्धारितरूपमा अनुमति नदिइएको:

• घरको ठेगाना
• सडक प्रयोगका लागि आवश्यक नपर्ने आन्तरिक पहिचानकर्ताहरू
• अन्य प्रमाणीकरणबाट असम्बन्धित विशेषताहरू
• ऐतिहासिक प्रस्तुति लगहरू
• व्यावसायिक मेटाडेटा

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

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

२. भाडा काउन्टर: पात्रता, पहिचान मिलान, र अनावश्यक केही होइन

भाडाको मामला अधिक विस्तृत छ किनभने वास्तवमा दुई क्षण छन्: आगमनअघि टाढाबाट अग्रिम जाँच, र चाबी सुम्पँदा व्यक्ति वा किओस्कको बेलाको पिकअप।

EU mDL म्यानुअलले दुवैको मोडेल पहिले नै बनाएको छ। एउटा कार-भाडा सेवाले बुकिङको क्रममा पहिचानको प्रमाणसहित mDL माग गर्न, प्रमाणीकरणहरू प्रमाणित गर्न, र पछि सवारी छाड्नुअघि पिकअपमा ग्राहकलाई व्यक्तिगत रूपमा प्रमाणित गर्न सक्छ। प्रयोगकर्ताहरू व्यक्तिगत रूपमा वा अग्रिम टाढाबाट कार-भाडा कम्पनीहरूसँग आफ्नो mDL साझा गर्न सक्छन्।

भाडा काउन्टरलाई मुख्यतः कुनै घटनाको अनुसन्धान गर्न पर्दैन। यसले निर्णय गर्न चाहिन्छ: के म यो बुकिङ र नीति अन्तर्गत यो ग्राहकलाई यो सवारी भाडामा दिन सक्छु?

टाढाबाट अग्रिम जाँचमा समावेश हुनु पर्ने:

• पहिचान सम्बन्ध
• तस्बिर वा समकक्ष पहिचान-बन्धन तत्त्व
• सम्बन्धित सवारी श्रेणी
• जारी र म्याद समाप्ति मितिहरू
• वर्तमान वैधता
• सम्भवतः उमेर सीमा वा उमेर ब्यान्ड

पिकअपले पुष्टि गर्नु पर्ने:

• धारक त्यही व्यक्ति हो जसले अग्रिम जाँच पूरा गरेको थियो
• वर्तमान वैधता
• सम्बन्धित अधिकारहरू

पूर्वनिर्धारितरूपमा आवश्यक नपर्ने:

• पूर्ण घरको ठेगाना जब बुकिङ प्रोफाइलमा सम्पर्क विवरण पहिले नै छ
• पूर्ण जन्मतिथि जहाँ उमेर-माथि वा उमेर-ब्यान्ड पर्याप्त छ
• असम्बन्धित पहिचान विशेषताहरू
• बुकिङ प्रमाणीकरण पहिले नै अवस्थित भए पूर्ण प्रमाणपत्रको पुनः-प्रस्तुति

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

३. रोजगारदाता: एउटा प्रमाणकर्ता श्रेणी, पूर्ण पहिचानमा प्रवेश होइन

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

एक रोजगारदाता वा फ्लीट अपरेटरलाई वैध रूपमा जान्न आवश्यक हुन सक्छ:

• एउटा कर्मचारी हाल निश्चित सवारी श्रेणीहरू चलाउन अधिकृत छ कि छैन
• मुख्य प्रतिबन्धहरू अवस्थित छन् कि छैनन्
• अधिकार वैध रहन्छ कि रहँदैन

यो एक वास्तविक व्यावसायिक आवश्यकता हो। तर यसले स्वतः सम्पूर्ण ड्राइभिङ प्रमाणपत्र, पूर्ण पहिचान डेटा, वा बारम्बार प्रस्तुतिको निरन्तर धारामा स्थायी पहुँचलाई उचित ठहर्याउँदैन।

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

भविष्यको IDP कार्यस्थल पहुँच ब्याज बन्नु हुँदैन।

रोजगारदाता र फ्लीट प्रयोगका लागि, सही ढाँचा सामान्यतः हो:

• काम-सम्बन्धित पात्रता जाँच
• सम्भवतः आवधिक अनुपालन प्रमाणीकरण
• सम्भवतः धारक निर्दिष्ट श्रेणीहरूका लागि वैध रहन्छ भन्ने दाबी
• तर कर्मचारी प्रणालीमा साइन इन गर्दा वा पाली सुरु गर्दा हरेक पटक सम्पूर्ण लाइसेन्स डेटाको पूर्वनिर्धारित हस्तान्तरण होइन

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

४. बीमाकर्ता: दाबीहरू निरन्तर दृश्यताको अनुमति होइन

बीमाको मामला प्रायः वास्तविक हुन्छ। EU mDL प्रयोग-केस सामग्रीमा, बीमाकर्ताहरू भाडा परिदृश्यमा अप्रत्यक्ष रूपमा देखिन्छन्: बीमा कम्पनीहरूले कार-भाडा कम्पनीहरूलाई गाडी भाडामा लिने व्यक्तिलाई गाडी चलाउने अधिकार छ कि छैन जाँच्न आवश्यक गर्छन्। बीमाले ड्राइभिङ-प्रमाणीकरण प्रवाहलाई पहिले नै प्रभाव पार्छ।

तर यसको मतलब बीमाकर्ताले प्रहरीसँग समान डेटा, वा प्रमाणपत्रमा स्थायी पहुँचको अधिकार पाउनु पर्छ भन्ने होइन।

भविष्यको IDP ले बीमाकर्तालाई छुट्टाछुट्टै अभिप्रेत उपयोगसहित एक छुट्टै प्रमाणकर्ता श्रेणीका रूपमा व्यवहार गर्नु पर्छ:

• अन्डरराइटिङ
• भाडा-जोखिम प्रमाणीकरण
• हानि-पछिको दाबी व्यवस्थापन
• धोखाधडी समीक्षा

ती एउटै उद्देश्य होइनन्। EU डेटा-सुरक्षा सिद्धान्तहरू अन्तर्गत, व्यक्तिगत डेटा निर्दिष्ट उद्देश्यका लागि संकलन गरिनु पर्छ र त्यो उद्देश्यका लागि आवश्यक र समानुपातिकमा सीमित हुनु पर्छ। W3C को VC मार्गदर्शनले प्राविधिक रूपमा उही निष्कर्षमा पुग्छ: प्रमाणकर्ताहरूले कडाईसँग आवश्यक भएको मात्र माग्नु पर्छ।

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

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

पूर्वनिर्धारितरूपमा अनुमति नदिइएको:

• अन्तर्निहित प्रमाणपत्रमा निरन्तर पहुँच
• ग्राहकले बीमाकर्तासँग अन्तरक्रिया गर्दा हरेक पटक बारम्बार सामान्य प्रमाणीकरण
• लगइन टोकनका रूपमा ड्राइभिङ प्रमाणपत्रको प्रयोग
• असम्बन्धित विशेषताहरूको संकलन

ड्राइभिङ प्रमाणपत्र निगरानी सदस्यता होइन। र यो चुपचाप त्यस्तो बन्नु हुँदैन।

किन मध्यस्थकर्ताहरू दृश्यमान हुनु आवश्यक छ

वास्तविक बजारहरूमा मध्यस्थकर्ताहरू हुन्छन्। भाडा प्लेटफर्महरू, फ्लीट विक्रेताहरू, रोजगारदाता HR प्रणालीहरू, र बीमा दाबी प्रशोधकहरू प्रायः तेस्रो पक्षहरू मार्फत काम गर्छन्।

EUDI वास्तुकलाले यसलाई यसरी व्यवस्था गर्छ:

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

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

ETSI यहाँ मद्दत गर्छ। यसको वालेट-भर-पर्ने-पक्ष प्रमाणपत्र मोडेलमा समर्थन URI हरू, अभिप्रेत उपयोग, रेजिस्ट्री URI हरू, र पर्यवेक्षी-प्राधिकरण मेटाडेटा समावेश छ। यो प्रयोगकर्ताहरूले अनुरोधको अर्को छेउमा वास्तवमा को छ र मेटाउने वा सुधार चाहँदा कहाँ जाने भन्ने बुझ्नका लागि आवश्यक मेसिन-पठनयोग्य पूर्वाधारको प्रकार हो।

अवधारण पहुँच नियन्त्रणको अंश हो

चयनात्मक प्रकटीकरणबारे अधिकांश छलफलहरू धेरै चाँडो समाप्त हुन्छन्। तिनीहरू के प्रकट गरिन्छ भन्नेमा ध्यान केन्द्रित गर्छन्। तिनीहरू त्यसपछि कति समय रहन्छ भन्नेमा पर्याप्त ध्यान दिँदैनन्।

वर्तमान मार्गदर्शन पहिले नै एकीकृत हुँदैछ:

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

अवधारण वर्ग प्रकटीकरण नीतिकै अंश हुनु पर्छ:

• प्रहरी सडक जाँच: कानुनी परिचालन रेकर्डभन्दा बाहिर पूर्वनिर्धारित रूपमा कुनै अवधारण छैन
• भाडा अग्रिम जाँच: बुकिङसँग जोडिएको कारोबार रेकर्ड, पुन: प्रयोगयोग्य पहिचान प्रतिलिपि होइन
• रोजगारदाता फ्लीट अनुपालन: अनुपालन रेकर्ड वा प्रमाणीकरण परिणाम, कच्चा प्रमाणपत्र डेटा होइन
• बीमाकर्ता दाबी: दाबीमा सीमित दाबी रेकर्ड, स्थायी पहुँच होइन

अवधारणलाई बेवास्ता गर्ने भविष्यको IDP केवल आंशिक रूपमा गोपनीयता-संरक्षण गर्ने हो।

वालेटले वास्तवमा के निर्णय गर्नु पर्छ

यदि मैले यो सम्पूर्ण लेखलाई एउटा कार्यान्वयन नियममा घटाउनु पर्छ भने, यो हुनेछ:

वालेटले “के म यो प्रमाणपत्र प्रस्तुत गर्न सक्छु?” भनेर जवाफ दिनु हुँदैन। यसले जवाफ दिनु पर्छ “के म यो प्रमाणित प्रमाणकर्तालाई, यो अभिप्रेत उपयोगका लागि, यस सन्दर्भमा, यो अवधारण वर्ग अन्तर्गत, यो दाबीहरूको सेट प्रस्तुत गर्न सक्छु?”

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

• प्रमाणकर्ताको पहिचान
• प्रमाणकर्ता श्रेणी
• अभिप्रेत उपयोग
• दर्ता विशेषता दायरा
• जारीकर्ताबाट प्रकटीकरण नीति, यदि उपस्थित भए
• वातावरण (सडक, पिकअप, टाढाबाट, फ्लीट, दाबी)
• धारकको अनुमोदन
• लागू अवधारण नीति

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

मूल तर्क

भविष्यको IDP ले डेटा प्रकट गर्न सकिन्छ कि सकिँदैन भनेर सोध्नु हुँदैन। यसले सोध्नु पर्छ:

• को सोधिरहेको छ?
• कुन उद्देश्यका लागि?
• कुन अधिकार अन्तर्गत?
• कुन सन्दर्भमा?
• कुन अवधारण परिणामहरूसहित?

प्रहरी, भाडा काउन्टर, रोजगारदाता, र बीमाकर्ता अनुरोधको अर्को छेउमा चार लोगो मात्र होइनन्। तिनीहरू चार फरक जोखिम मोडेल, चार फरक कानुनी सन्दर्भ, सोध्ने चार फरक कारण हुन् — र तिनीहरूले चार फरक प्रकटीकरण सेटहरू उत्पन्न गर्नु पर्छ।

यो अनावश्यक जटिलता होइन। यो नै हो एउटा आधुनिक ड्राइभिङ प्रमाणपत्र कस्तो देखिन्छ जब यसले प्रत्येक प्रमाणकर्तालाई एउटै प्रमाणकर्ता ठान्न छाड्छ।