प्रॉम्प्ट और दायरा
कंपनी अपने दस्तावेज़-सत्यापन फ़्लो के एक हिस्से को ब्राउज़र-मध्यस्थता वाले Digital Credentials API से बदलना चाहती है। आप इसे अपनाने, प्रेज़ेंटेशन या जारी करने (issuance) में से किससे शुरुआत करने, और कम्पैटिबिलिटी व प्राइवेसी जोखिम को नियंत्रित करने का निर्णय कैसे लेंगे?
इंटरव्यूअर क्या मूल्यांकन करता है
- ड्राफ़्ट स्टैंडर्ड को तैयार नेटवर्क मानने के बजाय API क्षमता, क्रेडेंशियल इकोसिस्टम और बिज़नेस परिणामों को अलग-अलग समझना।
- प्रेज़ेंटेशन और जारी करने (issuance) की जर्नी तथा उनके अलग-अलग पार्टनर्स व जोखिमों में अंतर करना।
- कवरेज, पूर्णता (completion), मैन्युअल-रिव्यू लागत, फ्रॉड से नुकसान और रिकवरी पाथ को संख्यात्मक रूप में मापना।
- डेटा मिनिमाइज़ेशन, सहमति, विकल्पों और रोक की शर्तों (stop conditions) को निर्णय में शामिल करना।
स्पष्टीकरण के लिए प्रश्न
- क्या लक्ष्य लॉगिन, आयु सत्यापन, खाता खोलना या नया क्रेडेंशियल जारी करना है?
- लक्षित उपयोगकर्ताओं के पास कौन से वॉलेट, क्रेडेंशियल फ़ॉर्मैट और डिवाइस हैं, और कवरेज को कैसे मापा जाएगा?
- कौन से फ़ील्ड अनिवार्य हैं, और किनमें चयनात्मक प्रकटीकरण (selective disclosure) या मैन्युअल रिव्यू का उपयोग किया जा सकता है?
- जब सत्यापन विफल हो जाए, वॉलेट अनुपलब्ध हो, या क्रेडेंशियल समाप्त (expire) या निरस्त (revoke) हो जाए, तो यूज़र को प्रक्रिया जारी रखने की अनुमति कैसे मिलती है?
30-सेकंड उत्तर ढांचा
मैं पहचान के हर फ़्लो को बदलने के बजाय एक छोटे पायलट के रूप में उच्च-मूल्य, कम-नुकसान वाली प्रेज़ेंटेशन जर्नी से शुरुआत करूँगा। वॉलेट और क्रेडेंशियल कवरेज को मापते हुए पूर्णता (completion), समय, लागत और फ्रॉड के आधार पर API, मैन्युअल और वर्तमान पाथ की तुलना करें। डेटा मिनिमाइज़ेशन, स्पष्ट सहमति, इंटरऑपरेबिलिटी और फ़ॉलबैक पाथ लॉन्च के लिए अनिवार्य शर्तें (gates) हैं। केवल कवरेज, प्राइवेसी और ऑपरेशनल मेट्रिक्स पास होने के बाद ही मैं जारी करने (issuance) या व्यापक बाज़ारों का मूल्यांकन करूँगा।
चरण-दर-चरण विस्तृत विश्लेषण
1. प्रोडक्ट की सीमा निर्धारित करें
W3C का 1 June 2026 Working Draft डिजिटल क्रेडेंशियल प्रस्तुत करने और जारी करने के लिए यूज़र-एजेंट मध्यस्थता का वर्णन करता है। यह ब्राउज़र और क्रेडेंशियल इकोसिस्टम के बीच एक समन्वय परत (coordination layer) को परिभाषित करता है, न कि कोई सार्वभौमिक दस्तावेज़ फ़ॉर्मैट, वॉलेट नेटवर्क या कानूनी पहचान निष्कर्ष। प्रोडक्ट डिस्कवरी में "ब्राउज़र फ़्लो शुरू कर सकता है" और "बिज़नेस परिणाम पर भरोसा कर सकता है" का अलग-अलग परीक्षण किया जाना चाहिए।
2. प्रेज़ेंटेशन और जारी करने (issuance) को अलग करें
प्रेज़ेंटेशन उस क्रेडेंशियल की मांग करता है जो यूज़र के पास पहले से है; इसके जोखिम वॉलेट की उपलब्धता, यूज़र की पसंद, प्रकट किए गए फ़ील्ड और सत्यापन के इर्द-गिर्द होते हैं। जारी करने (issuance) के लिए अतिरिक्त रूप से जारीकर्ता की पात्रता, क्रेडेंशियल फ़ॉर्मैट, की-बाइंडिंग, लाइफ़साइकिल और निरस्तीकरण (revocation) की आवश्यकता होती है, जिससे अधिक पार्टनरशिप और कंप्लायंस का काम बढ़ जाता है। एक ही समय में जारीकर्ता नेटवर्क बनाने के बजाय मौजूदा क्रेडेंशियल का उपयोग करने वाले एकल परिदृश्य से शुरुआत करें।
3. मापने योग्य निर्णय मानक (gates) सेट करें
एक कंट्रोल ग्रुप का उपयोग करें और एंड-टू-एंड पूर्णता, P50/P95 समय, प्रति सत्यापन लागत, मैन्युअल हैंडऑफ़, फ्रॉड अस्वीकृति और सपोर्ट वॉल्यूम की तुलना करें। डिवाइस, वॉलेट, ब्राउज़र और यूज़र कोहोर्ट के अनुसार सेगमेंट बनाएं ताकि औसत डेटा में कमियां न छिपें। API विफलता, यूज़र रद्दीकरण, समाप्ति और निरस्तीकरण को अलग-अलग गिनें; तकनीकी सफलता का अर्थ बिज़नेस की सफलता नहीं है।
4. प्राइवेसी, ट्रस्ट और फ़ॉलबैक डिज़ाइन करें
केवल उद्देश्य के लिए आवश्यक फ़ील्ड का अनुरोध करें, सहमति और उद्देश्य नोटिस बनाए रखें, और लॉग में क्रेडेंशियल डेटा को प्रतिबंधित करें। सत्यापनकर्ता (verifier) क्लाइंट आउटपुट पर भरोसा करने के बजाय जारीकर्ता के ट्रस्ट, सिग्नेचर, वैधता और निरस्तीकरण की जांच करता है। असमर्थित डिवाइस, वॉलेट अस्वीकृति और नेटवर्क विफलता के मामले में मौजूदा मैन्युअल या दस्तावेज़ पाथ का उपयोग किया जाता है। प्राइवेसी की घटनाओं, शिकायतों या पूर्णता दर के लिए स्टॉप थ्रेशोल्ड निर्धारित करें और किसी भी महत्वपूर्ण सीमा के पार होने पर पायलट को रोक दें।
उच्च गुणवत्ता वाला नमूना उत्तर
मैं केवल इसलिए पहचान सत्यापन को नहीं बदलूँगा क्योंकि ब्राउज़र एक API उपलब्ध कराता है। मैं मौजूदा क्रेडेंशियल और सीमित विफलता लागत वाली एक प्रेज़ेंटेशन जर्नी चुनूँगा, वॉलेट और ब्राउज़र कवरेज को मापूँगा, और पूर्णता, समय, लागत, मैन्युअल हैंडऑफ़ व फ्रॉड की नियंत्रित तुलना करूँगा। प्रेज़ेंटेशन और जारी करना (issuance) अलग-अलग निर्णय हैं; जारी करने में जारीकर्ता पात्रता, फ़ॉर्मैट इंटरऑपरेबिलिटी और निरस्तीकरण लाइफ़साइकिल का काम जुड़ जाता है। प्रोडक्ट केवल आवश्यक फ़ील्ड का अनुरोध करता है, सहमति रिकॉर्ड करता है, और सर्वर जारीकर्ता, सिग्नेचर, वैधता व निरस्तीकरण की जांच करता है। असमर्थित, रद्द और समाप्त हो चुके फ़्लो मौजूदा पाथ पर लौट आते हैं। कवरेज, प्राइवेसी और शिकायत की स्टॉप लाइन पूरी होने के बाद, मैं बाज़ार का विस्तार करूँगा या जारी करने का मूल्यांकन करूँगा।
सामान्य गलतियाँ
- Working Draft को हर क्षेत्र, ब्राउज़र और वॉलेट द्वारा समर्थित एक सार्वभौमिक नेटवर्क मानना।
- प्रेज़ेंटेशन और जारी करने (issuance) को मिलाना तथा जारीकर्ता, फ़ॉर्मैट और निरस्तीकरण से जुड़ी पार्टनरशिप को कम आंकना।
- पूर्णता, मैन्युअल हैंडऑफ़ और फ्रॉड परिणामों के बजाय केवल API कॉल की सफलता को मापना।
- रॉ क्रेडेंशियल को लॉग करना या उद्देश्य से असंबद्ध पहचान फ़ील्ड का अनुरोध करना।
- कोई गैर-API फ़ॉलबैक न रखना, जिससे असमर्थित डिवाइस खाता न खोल सकें।
- कंट्रोल ग्रुप, मार्केट सेगमेंट या स्पष्ट स्टॉप लाइन के बिना पायलट चलाना।
फ़ॉलो-अप प्रश्न और उत्तर
प्रेज़ेंटेशन से शुरुआत क्यों करें?
यह मौजूदा क्रेडेंशियल और वॉलेट पर निर्भर करता है और इसका दायरा जारी करने वाले नेटवर्क की तुलना में छोटा होता है। यह एक अलग जारी करने की परियोजना से पहले यूज़र वैल्यू, कवरेज और सत्यापन गुणवत्ता को मान्य कर सकता है।
आप कैसे तय करते हैं कि कवरेज पर्याप्त है?
लक्षित डिवाइसों, ब्राउज़रों, वॉलेटों और यूज़र कोहोर्ट्स को सेगमेंट करें, फिर केवल एक कम्पैटिबिलिटी टेबल के बजाय वास्तविक फ़नल डेटा से न्यूनतम पूर्णता दर तय करें। कम कवरेज वाले उपयोगकर्ताओं के पास एक समान वैकल्पिक विकल्प होना चाहिए।
पायलट को कब रोका जाना चाहिए?
पूर्णता, प्राइवेसी घटनाओं, शिकायतों, फ्रॉड के नुकसान और मैन्युअल लागत के लिए पहले से थ्रेशोल्ड तय करें। यदि कोई महत्वपूर्ण मेट्रिक अपनी सीमा पार करता है, तो ट्रैफ़िक जोड़ना बंद करें, ऑडिट साक्ष्य सुरक्षित रखें, और यह तय करें कि इसे ठीक करना है या वापस लेना है।