डेटा इंजीनियरिंग इंटरव्यू: आप Recognized Entities के साथ एक सत्यापन योग्य ट्रस्ट रजिस्ट्री कैसे बनाएंगे?

प्रॉम्प्ट और दायरा

कई विश्वविद्यालय किसी एक केंद्रीय रजिस्ट्री पर निर्भर हुए बिना संस्थानों और क्रेडेंशियल जारीकर्ताओं की सत्यापन योग्य डायरेक्टरी साझा करना चाहते हैं। बताएं कि आप RecognizedEntity, RecognizedAction, और VerifiableRecognitionCredential को कैसे मॉडल करेंगे, और प्राइवेसी, रिवोकेशन, प्रतिरूपण (impersonation), और परस्पर विरोधी रजिस्ट्रियों को कैसे संभालेंगे।

W3C Recognized Entities v1.0 वर्तमान में एक First Public Working Draft है। यह किसी इकोसिस्टम द्वारा किसी विशिष्ट कार्य (action) को करने के लिए पहचानी गई एंटिटी के डेटा मॉडल का वर्णन करता है, जिससे पहचान की जानकारी को प्रकाशित करने या सीधे सत्यापनकर्ता (verifier) को सौंपने की अनुमति मिलती है। यह प्रश्न वर्किंग ड्राफ्ट को अंतिम मानक माने बिना सत्यापन योग्य डेटा मॉडलिंग और ट्रस्ट निर्णयों का परीक्षण करता है।

साक्षात्कारकर्ता क्या मूल्यांकन करता है

साक्षात्कारकर्ता एंटिटीज़, एक्शन्स, पहचानकर्ताओं (recognizers), क्रेडेंशियल की वैधता और सत्यापन नीति के लिए अलग-अलग मॉडलों के साथ-साथ क्रॉस-रजिस्ट्री जांच, रिवोकेशन और प्राइवेसी सीमाओं की तलाश करता है। एक मजबूत उत्तर यह रेखांकित करता है कि धारक (holder) द्वारा प्रदान किए गए क्रेडेंशियल को सत्यापनकर्ता द्वारा स्वीकार किया जाना अनिवार्य नहीं है और पहचान का दावा (assertion) स्वचालित व्यावसायिक प्राधिकरण (business authorization) नहीं है।

उत्तर देने से पहले स्पष्ट करने वाले प्रश्न

पहचानकर्ता (recognizer), पहचानी गई एंटिटी और अंतिम सत्यापनकर्ता कौन हैं, और प्रत्येक किस रजिस्ट्री पर भरोसा करता है?
क्या मान्यता प्राप्त एक्शन जारी करना (issuing), सत्यापित करना (verifying) या कुछ और है, और इसका आउटपुट स्कीमा कैसे परिभाषित है?
क्या क्रेडेंशियल सीधे सत्यापनकर्ता को सौंपा जाता है, या वर्तमान स्थिति को जारीकर्ता से फ़ेच किया जाना चाहिए?
कौन से रिवोकेशन, वैधता, की-रोटेशन और प्राइवेसी आवश्यकताएं लागू होती हैं?
जब रजिस्ट्रियों में असहमति होती है, तो मध्यस्थता कौन करता है और कारण कौन दर्ज करता है?

30-सेकंड का उत्तर ढांचा

"मैं एंटिटी, एक्शन, पहचानकर्ता और क्रेडेंशियल दावे को सत्यापन योग्य ऑब्जेक्ट्स के रूप में मॉडल करूंगा। RecognizedEntity एक एक्शन से recognizedTo के माध्यम से जुड़ता है; एक्शन recognizedBy और एक आउटपुट स्कीमा का नाम देता है; और VerifiableRecognitionCredential जारीकर्ता, वैधता और विषय सेट को रिकॉर्ड करता है। एक सत्यापनकर्ता हस्ताक्षर, स्थिति और समय की जांच करता है, फिर स्थानीय ट्रस्ट नीति के तहत पहचानकर्ताओं का चयन करता है, पहचान श्रृंखलाओं (recognition chains) का पालन करता है और आउटपुट स्कीमा को मान्य करता है। धारक द्वारा प्रदान किया गया क्रेडेंशियल लुकअप से बचा सकता है, लेकिन यह उच्च-जोखिम वाले निर्णयों के लिए फ्रेशनेस जांच की जगह नहीं ले सकता। मैं व्यक्तिगत डेटा को न्यूनतम रखूंगा और रिवोकेशन, की-रोटेशन और विवाद निर्णयों का ऑडिट करूंगा।"

चरण-दर-चरण विस्तृत उत्तर

1. एंटिटीज़, एक्शन्स और मान्यता को मॉडल करें

एंटिटी के लिए विश्व स्तर पर अद्वितीय URL का उपयोग करें और recognizedTo को एक या अधिक RecognizedAction ऑब्जेक्ट्स पर इंगित करें। एक एक्शन में आउटपुट को मान्य करने के लिए एक नाम, पहचानकर्ता और स्कीमा शामिल होता है; "संस्थान विश्वसनीय है" को बिना स्कोप वाले बूलियन के रूप में एनकोड न करें। recognizedIn किसी मौजूदा ट्रस्ट सूची या किसी अन्य मान्यता क्रेडेंशियल का संदर्भ ले सकता है ताकि सत्यापनकर्ता दावे के पीछे के इकोसिस्टम की पहचान कर सकें।

2. दावे को एक सत्यापन योग्य क्रेडेंशियल के रूप में रैप करें

क्रेडेंशियल को Verifiable Credentials Data Model v2.0 के अनुरूप होना चाहिए और इसमें इसका प्रकार, जारीकर्ता, validFrom, validUntil, और credentialSubject में मान्यता प्राप्त एंटिटीज़ शामिल होनी चाहिए। एक वैध हस्ताक्षर जारीकर्ता की कुंजी के नियंत्रण को साबित करता है, न कि यह कि सत्यापनकर्ता को उस जारीकर्ता पर भरोसा करना चाहिए; स्थानीय ट्रस्ट रूट्स, अनुमति सूचियों (allowlists) और एक्शन स्कोप को एक अलग निर्णय के रूप में लागू करें।

text

credential = {
  type: ["VerifiableCredential", "VerifiableRecognitionCredential"],
  issuer: "did:web:accreditor.example",
  validFrom: "2026-01-01T00:00:00Z",
  credentialSubject: [{
    id: "did:web:university.example",
    recognizedTo: [{ action: "issue", outputValidation: [schema] }]
  }]
}

3. सत्यापन और पहचान श्रृंखलाएं डिज़ाइन करें

पहले सिंटैक्स, हस्ताक्षर, जारीकर्ता, वैधता, रिवोकेशन और स्कीमा की जांच करें, फिर निर्धारित करें कि क्या पहचानकर्ता स्थानीय ट्रस्ट सेट से संबंधित है। बहु-स्तरीय recognizedBy या recognizedIn श्रृंखलाओं के लिए, अधिकतम गहराई निर्धारित करें, साइकिलों का पता लगाएं और प्रत्येक स्तर की अवधि को मान्य करें; एक लंबी श्रृंखला स्वचालित रूप से अधिक विश्वसनीय नहीं होती है। जब नीति की आवश्यकता हो तो ETSI Trust Service Lists, X.509 CA सूचियों या किसी अन्य नियंत्रित रजिस्ट्री के साथ क्रॉस-चेक करें।

4. फ्रेशनेस और रिवोकेशन को संभालें

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

5. प्राइवेसी की रक्षा करें और दुरुपयोग को रोकें

सार्वजनिक रूप से नामों, पहचानकर्ताओं, संगठनात्मक संबंधों और एक्शन्स को सूचीबद्ध करने से निगरानी (surveillance) या संगति के आधार पर दोष (guilt by association) संभव हो सकता है। प्रति संदर्भ फ़ील्ड्स को न्यूनतम करें और धारक-नियंत्रित चयनात्मक प्रकटीकरण (selective disclosure) को प्राथमिकता दें; एक मान्यता से असंबंधित गुणों का अनुमान न लगाएं दुर्भावनापूर्ण धारकों को हस्ताक्षरों, स्थिति, स्रोत और स्कीमा को संयुक्त रूप से मान्य करके और स्वीकार्य जारीकर्ताओं को प्रतिबंधित करके झूठे क्रेडेंशियल्स का प्रचार करने से रोकें।

6. विवादों और रोलबैक का संचालन करें

विभिन्न रजिस्ट्रियां एक ही एंटिटी को अलग-अलग एक्शन्स, वैधता या स्थिति सौंप सकती हैं। निर्णय संग्रहीत करने से पहले प्राथमिकता, दायरा, समय और साक्ष्य के नियम परिभाषित करें, और चयनित कारण का ऑडिट करें। वर्किंग ड्राफ्ट में बदलाव होने पर संदर्भों, स्कीमाओं और सत्यापन एल्गोरिदम का संस्करण बनाएं; व्यावसायिक प्राधिकरण को बदले बिना शैडो-रीड (shadow-read) करें। प्रतिरूपण, प्राइवेसी लीकेज, या सत्यापन रिग्रेशन होने पर नए पथ को अक्षम करना चाहिए और पुरानी रजिस्ट्री को पुनर्स्थापित करना चाहिए।

उच्च गुणवत्ता वाला नमूना उत्तर

मैं RecognizedEntity, RecognizedAction, पहचानकर्ता और VerifiableRecognitionCredential को अलग-अलग मॉडल करूंगा। एंटिटी का एक वैश्विक URL होता है, एक्शन अपने दायरे, पहचानकर्ता और आउटपुट स्कीमा का नाम देता है, और क्रेडेंशियल जारीकर्ता, वैधता और विषयों के साथ VC Data Model 2.0 का पालन करता है। सत्यापनकर्ता हस्ताक्षर, समय, रिवोकेशन और स्कीमा की जांच करता है, फिर स्थानीय ट्रस्ट रूट्स और अनुमति सूचियों को लागू करता है; मान्यता श्रृंखलाओं में गहराई और चक्र की सीमाएं होती हैं और ETSI या X.509 सूचियों के साथ क्रॉस-चेक किया जा सकता है। धारक द्वारा प्रस्तुत क्रेडेंशियल लुकअप को कम करते हैं लेकिन उच्च-जोखिम वाले मामलों के लिए फ्रेशनेस जांच को नहीं हटाते हैं। निगरानी या संगति के आधार पर दोष से बचने के लिए व्यक्तिगत फ़ील्ड को न्यूनतम करें। दायरे, समय और प्रशासन नियमों के साथ रजिस्ट्री विवादों को हल करें और परिणाम का ऑडिट करें। वर्किंग ड्राफ्ट अपडेट के दौरान संदर्भों और सत्यापनकर्ताओं का संस्करण बनाएं, और प्रतिरूपण, पुरानी रिवोकेशन स्थिति, या प्राइवेसी विफलताओं के सामने आने पर रोलबैक करें।

सामान्य गलतियाँ

वैध हस्ताक्षर को व्यावसायिक ट्रस्ट मानना → यह केवल कुंजी नियंत्रण साबित करता है → फिर भी ट्रस्ट रूट्स, स्थिति और एक्शन स्कोप की जांच करें।
मान्यता को बिना स्कोप वाले ट्रस्टेड फ़्लैग के रूप में एनकोड करना → मान्यता प्राप्त एक्शन खो जाता है → recognizedTo और एक आउटपुट स्कीमा को मॉडल करें।
हमेशा धारक के नवीनतम क्रेडेंशियल पर भरोसा करना → यह रिवोक या समाप्त हो सकता है → जोखिम के अनुसार स्थिति और वैधता की जांच करें।
पूरी व्यक्तिगत रजिस्ट्री प्रकाशित करना → एकत्रीकरण (aggregation) निगरानी को सक्षम कर सकता है → प्रकटीकरण को न्यूनतम करें और एकत्रीकरण को सीमित करें।
रजिस्ट्रियों के परस्पर विरोधी होने पर पहला परिणाम लेना → निर्णय गैर-ऑडिट योग्य और हेरफेर योग्य हो जाते हैं → प्राथमिकता, दायरा, समय और साक्ष्य परिभाषित करें।

फॉलो-अप प्रश्न और उत्तर

कोई मान्यता क्रेडेंशियल सीधे व्यावसायिक अनुमति क्यों नहीं देता है?

यह दावा करता है कि एक पहचानकर्ता किसी कार्य को करने के लिए किसी एंटिटी को जानता है। व्यावसायिक अनुमति संसाधन, टेनेंट, समय, जोखिम और स्थानीय नीति पर भी निर्भर करती है।

आप अनंत पहचान श्रृंखलाओं (infinite recognition chains) को कैसे रोकते हैं?

अधिकतम गहराई निर्धारित करें, विज़िट किए गए पहचानकर्ताओं को ट्रैक करें, और कुल बजट लागू करें; चक्रों या सीमाओं के पार होने पर विफल करें और कारण दर्ज करें।

एक सत्यापनकर्ता को वर्तमान स्थिति कब फ़ेच करनी चाहिए?

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

आप किसी व्यक्ति की गलत पहचान किए जाने को कैसे संभालते हैं?

रिवोकेशन, अपील और सुधार पथ प्रदान करें; सार्वजनिक फ़ील्ड को न्यूनतम करें; जारी करने और सत्यापन के साक्ष्य को सुरक्षित रखें; और सही स्थिति प्रभावी होने पर पुराने क्रेडेंशियल को स्वीकार करना बंद कर दें।

आप किसी वर्किंग ड्राफ्ट का सुरक्षित रूप से परीक्षण कैसे करते हैं?

व्यावसायिक प्राधिकरण को बदले बिना अलग-थलग टेनेंट्स में शैडो-सत्यापन (shadow-verify) करें, विनिर्देश और परीक्षण वैक्टर को पिन करें, रोलबैक स्विच बनाए रखें, और कार्यान्वयन व सुरक्षा समीक्षाओं के बाद विस्तार करें।