प्रतिनिधि इंटरव्यू विषय

सिस्टम डिज़ाइन: आप गोपनीयता बनाए रखने वाली आयु-सत्यापन सेवा कैसे बनाएंगे?

सिस्टम डिज़ाइनकठिन
Offer.cc संपादकीय टीमप्रकाशित अपडेट किया गया

प्रश्न

कई वेबसाइटों के लिए एक आयु-सत्यापन सेवा डिज़ाइन करें: जन्म तिथि, नाम या क्रॉस-साइट ट्रैकिंग पहचानकर्ता को उजागर किए बिना आयु सीमा साबित करें।

प्रॉम्प्ट और संदर्भ

गेमिंग, कंटेंट और ऑनलाइन-फ़ार्मेसी साइटों को यह जांचने की आवश्यकता होती है कि उपयोगकर्ता 13, 16 या 18 वर्ष का है या नहीं। उपयोगकर्ता के पास सरकार या किसी विश्वसनीय जारीकर्ता (issuer) से प्राप्त क्रेडेंशियल होता है। इस सेवा को कई जारीकर्ताओं, ऑफ़लाइन रिकवरी, निरसन (revocation) और दुरुपयोग की जांच का समर्थन करना चाहिए।

साक्षात्कारकर्ता क्या परीक्षण करता है

वे क्रेडेंशियल जीवनचक्र, डेटा न्यूनीकरण, ट्रस्ट रूट्स, रीप्ले प्रतिरोध, उपलब्धता और विनियामक ऑडिट ट्रेड-ऑफ़ का परीक्षण कर रहे हैं। W3C VC 2.0 जारीकर्ता, धारक (holder) और सत्यापनकर्ता (verifier) को परिभाषित करता है; Digital Credentials API एक उपयोगकर्ता एजेंट को प्रस्तुति की मध्यस्थता करने की अनुमति देता है।

स्पष्ट करने हेतु प्रश्न

सीमाओं (thresholds), क्षेत्राधिकारों, क्रेडेंशियल स्रोतों, अनाम प्रमाण, विफलता UX और डेटा प्रतिधारण (retention) के बारे में पूछें। स्पष्ट करें कि क्या साइट को सटीक आयु की आवश्यकता है या केवल एक बूलियन परिणाम की, और क्या उच्च-जोखिम वाले मामलों में मैन्युअल समीक्षा की आवश्यकता है।

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

“एक जारीकर्ता आयु-युक्त सत्यापन योग्य क्रेडेंशियल बनाता है, और वॉलेट केवल सीमा प्रमाण प्रस्तुत करता है, जन्म तिथि या नाम नहीं। प्रत्येक अनुरोध के लिए सत्यापनकर्ता एक nonce और audience बनाता है, फिर हस्ताक्षर, समाप्ति, स्थिति और उद्देश्य बाइंडिंग की जांच करता है; सेवा केवल न्यूनतम ऑडिट इवेंट संग्रहीत करती है। मैं एक क्षेत्राधिकार और सीमा से शुरुआत करूँगा, सफलता, रीप्ले अस्वीकृति, गलत अस्वीकृति और लीकेज को मापूँगा, और फिर जारीकर्ताओं तथा ऑफ़लाइन प्रवाहों का विस्तार करूँगा।”

चरण-दर-चरण गहन विश्लेषण

प्रतिभागियों और ट्रस्ट रूट्स को परिभाषित करें

जारीकर्ता तथ्यों को प्रमाणित करता है, धारक वॉलेट प्रकटीकरण को नियंत्रित करता है, और सत्यापनकर्ता साइट एक बार का अनुरोध करती है। प्लेटफ़ॉर्म स्वयं पहचान को फिर से साबित किए बिना विश्वसनीय-जारीकर्ता मेटाडेटा और कुंजी रोटेशन बनाए रखता है।

न्यूनतम प्रकटीकरण डिज़ाइन करें

जन्म तिथि, नाम या स्थिर पहचानकर्ता के बजाय एक व्युत्पन्न “कम से कम 18” का दावा, क्रेडेंशियल प्रकार और समाप्ति वापस करें। क्षेत्राधिकार और सीमा के अनुसार स्कीमा परिभाषित करें ताकि अतिरिक्त फ़ील्ड कभी भी लॉग में दर्ज न हों।

रीप्ले और सहसंबंध को रोकें

प्रत्येक प्रस्तुति को एक nonce, audience, कॉलबैक मूल (origin) और संक्षिप्त समाप्ति से बाँधें। पुन: उपयोग किए गए nonce को अस्वीकार करें; पुन: प्रयोज्य सहसंबंधकों से बचें और आवश्यकता पड़ने पर सत्यापनकर्ता-विशिष्ट छद्म नाम जारी करें।

हस्ताक्षर और स्थिति सत्यापित करें

क्रेडेंशियल श्रृंखला, एल्गोरिदम, जारीकर्ता ट्रस्ट, समाप्ति और निरसन या निलंबन स्थिति की जांच करें। स्थिति प्रतिक्रियाओं को केवल नवीनता सीमा (freshness limit) के साथ कैश किया जा सकता है; विफल लुकअप को बंद (fail closed) होना चाहिए या जोखिम के अनुसार समीक्षा की आवश्यकता होनी चाहिए।

ऑफ़लाइन और रिकवरी को संभालें

ऑफ़लाइन सत्यापन हस्ताक्षरित सामग्री और समाप्ति के साथ हालिया स्थिति स्नैपशॉट का उपयोग करता है, कभी भी अनिश्चितकालीन विश्वास का नहीं। खोए हुए वॉलेट के लिए सीमा को कम किए बिना एक नए डिवाइस पर पुन: बाइंडिंग या पुन: जारी करने की आवश्यकता होती है।

ऑडिट और डेटा सीमाएं निर्धारित करें

कच्चे क्रेडेंशियल या जन्म तिथि का नहीं, बल्कि अनुरोधकर्ता, नीति संस्करण, परिणाम और सत्यापन समय का ऑडिट करें। दुरुपयोग की जांच के लिए एक नियंत्रित सहसंबंध टोकन को अलग भंडारण, एन्क्रिप्शन और एक्सेस नियंत्रण के साथ सुरक्षित रखें।

आदर्श उत्तर

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

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

पूरा पहचान दस्तावेज़ एकत्र करना

यह न्यूनीकरण का उल्लंघन करता है और लीकेज तथा क्रॉस-साइट ट्रैकिंग को बढ़ाता है; आयु का एक निष्कर्ष आमतौर पर पर्याप्त होता है।

केवल हस्ताक्षर की जांच करना

एक वैध हस्ताक्षर समाप्ति, गैर-निरसन या सही audience साबित नहीं करता है। स्थिति और उद्देश्य की जांच की जानी चाहिए।

वैश्विक उपयोगकर्ता पहचानकर्ता का पुन: उपयोग करना

वैश्विक पहचानकर्ता साइटों को उपयोगकर्ताओं को सहसंबंधित करने की अनुमति देते हैं। एक सत्यापनकर्ता-विशिष्ट छद्म नाम या एक बार के दावे का उपयोग करें।

पुराने ऑफ़लाइन स्थिति पर हमेशा के लिए भरोसा करना

निरसन और कुंजी रोटेशन पुरानी स्थिति को अमान्य कर देते हैं। ऑफ़लाइन सामग्री को समाप्ति और एक अपग्रेड पथ की आवश्यकता होती है।

अनुवर्ती प्रश्न

क्या होगा यदि किसी कम उम्र के उपयोगकर्ता के पास क्रेडेंशियल नहीं है?

पुन: जारी करने, विनियमित मैन्युअल समीक्षा, या एक स्पष्ट अस्वीकृति पथ की पेशकश करें; प्लेटफ़ॉर्म पर पूरा पहचान दस्तावेज़ अपलोड करने की आवश्यकता न रखें।

आप किसी दुर्भावनापूर्ण साइट द्वारा क्रेडेंशियल रीप्ले करने को कैसे संभालते हैं?

प्रस्तुति को सत्यापनकर्ता, nonce और संक्षिप्त TTL से बाँधें; दोहराए गए nonces और असामान्य मूल की निगरानी करें, और आवश्यकता पड़ने पर ट्रस्ट कॉन्फ़िगरेशन को निरस्त करें।

क्या होगा यदि क्षेत्राधिकारों के अलग-अलग नियम हों?

नीति संस्करण, सीमा और जारीकर्ता निर्देशिका को कॉन्फ़िगर करने योग्य बनाएं; एकल वैश्विक नियम को हार्ड-कोड करने के बजाय परिणाम में क्षेत्राधिकार और नीति संस्करण शामिल करें।

आप गोपनीयता सुरक्षा कैसे साबित करते हैं?

एंड-टू-एंड परीक्षणों को यह सुनिश्चित करना चाहिए कि लॉग, एनालिटिक्स और त्रुटियों में कोई जन्म तिथि या स्थिर पहचानकर्ता शामिल न हो; प्रकट फ़ील्ड और स्थिति लुकअप का नियमित रूप से ऑडिट करें।

सार्वजनिक स्रोत

संबंधित प्रश्न

संबंधित इंटरव्यू टूल

सिस्टम डिज़ाइन उत्तर के लिए हल करें का उपयोग करें

पहले आवश्यकताओं को स्पष्ट करें, फिर स्केल, आर्किटेक्चर, कंपोनेंट चयन और ट्रेड-ऑफ की ओर बढ़ें।

टूल देखें