डिजिटल क्रेडेंशियल्स API (2025): Chrome और Safari में लाइव सपोर्ट

अंतिम अपडेट: 30 अक्टूबर, 2025

प्रमुख ब्राउज़रों में डिजिटल क्रेडेंशियल्स API सपोर्ट का एक त्वरित अवलोकन:

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

Want to experience digital credentials in action?

Try Digital Credentials

जुलाई 2025 से क्या बदला है?

• शिप किया गया: Chrome 141 (30 सितंबर, 2025) और Safari 26 (15 सितंबर, 2025)।
• Chrome: प्रोटोकॉल-एग्नोस्टिक (OpenID4VP और ISO 18013-7 Annex C), CTAP पर डेस्कटॉप क्रॉस-डिवाइस।
• Safari: सिर्फ mdoc (org-iso-mdoc), CTAP के माध्यम से क्रॉस-डिवाइस फ्लो।
• API शेप: navigator.credentials.get(); requests/data नेमिंग; DigitalCredential फ़ीचर डिटेक्शन।

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

इस लेख में, हम डिजिटल क्रेडेंशियल्स API की वर्तमान स्थिति पर चर्चा करेंगे, जो एक महत्वपूर्ण विकास है और यह वेब पर पहचान संबंधी जानकारी के साथ हमारे इंटरैक्शन के तरीके को फिर से आकार देने का वादा करता है। हम इसके अंतर्निहित तंत्र, इसके द्वारा समर्थित प्रोटोकॉल, वर्तमान ब्राउज़र एडॉप्शन का पता लगाएंगे, और इस तेजी से विकसित हो रहे परिदृश्य में नेविगेट करने वाले रिलेइंग पार्टी और वॉलेट जारीकर्ताओं दोनों के लिए सिफारिशें देंगे।

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

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

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

डीपफेक, उन्नत AI-संचालित प्रतिरूपण तकनीकों, और तेजी से परिष्कृत फ़िशिंग हमलों के आगमन के साथ यह चुनौती नाटकीय रूप से बढ़ रही है। ये प्रौद्योगिकियाँ अत्यधिक यथार्थवादी लेकिन पूरी तरह से मनगढ़ंत वीडियो, ऑडियो और दस्तावेज़ साक्ष्य बना सकती हैं, जिससे पारंपरिक प्रणालियों और यहाँ तक कि AI-संचालित सत्यापन उपकरणों के लिए भी वास्तविक उपयोगकर्ताओं को धोखाधड़ी करने वालों से अलग करना अविश्वसनीय रूप से कठिन हो जाता है। सिंथेटिक पहचान बनाने या जाँचों को बायपास करने के लिए बायोमेट्रिक डेटा में हेरफेर करने की क्षमता एक गंभीर खतरा है, खासकर वित्तीय संस्थानों और किसी भी सेवा के लिए जिसे मजबूत 'अपने ग्राहक को जानें' (KYC) प्रक्रियाओं की आवश्यकता होती है। यह बढ़ता हुआ खतरा परिदृश्य अधिक सुरक्षित, क्रिप्टोग्राफ़िक रूप से सत्यापन योग्य ऑनलाइन पहचान और सत्यापन तंत्र की तत्काल आवश्यकता को रेखांकित करता है।

Want to experience digital credentials in action?

Try Digital Credentials

यह समझने के लिए कि डिजिटल क्रेडेंशियल्स कैसे काम करते हैं, इसमें शामिल प्रमुख खिलाड़ियों और उनकी कार्यक्षमता को सक्षम करने वाली विभिन्न तकनीकी परतों को देखना शामिल है।

इसके मूल में, डिजिटल क्रेडेंशियल्स की अवधारणा, विशेष रूप से नए वेब APIs के संदर्भ में, एक तीन-पक्षीय मॉडल के इर्द-गिर्द घूमती है:

1. जारीकर्ता (Issuer): एक इकाई (जैसे, सरकार, विश्वविद्यालय, नियोक्ता) जो किसी विषय के बारे में कुछ जानकारी के लिए आधिकारिक है और उस जानकारी को प्रमाणित करने वाला एक डिजिटल क्रेडेंशियल जारी कर सकती है।
2. धारक (Holder): जानकारी का विषय (यानी, यूज़र) जो जारीकर्ता से क्रेडेंशियल प्राप्त करता है और इसे एक डिजिटल वॉलेट में संग्रहीत करता है। धारक यह नियंत्रित करता है कि क्रेडेंशियल से कब और कौन सी जानकारी साझा की जाए।
3. सत्यापनकर्ता (Verifier) (या रिलेइंग पार्टी): एक इकाई (जैसे, एक वेबसाइट, एक ऑनलाइन सेवा) जिसे किसी सेवा या संसाधन तक पहुंच प्रदान करने के लिए धारक के बारे में कुछ जानकारी सत्यापित करने की आवश्यकता होती है। सत्यापनकर्ता धारक से आवश्यक जानकारी का अनुरोध करता है।

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

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

यह स्पष्टीकरण प्रोटोकॉल-न्यूट्रल है, क्योंकि क्रिप्टोग्राफ़िक चुनौतियों के माध्यम से जारी करने, धारण करने और सत्यापन के मूल सिद्धांत विभिन्न अंतर्निहित तकनीकों में समान हैं।

यह लेख डिजिटल क्रेडेंशियल्स के सत्यापन और सेलेक्टिव डिस्क्लोजर के सिद्धांत पर केंद्रित है, जो यूज़र्स को पूरे स्रोत दस्तावेज़ को प्रकट किए बिना विशिष्ट विशेषताओं (जैसे, "मैं 18 वर्ष से अधिक का हूँ," "मेरे पास एक वैध ड्राइवर का लाइसेंस है") को साबित करने में सक्षम बनाता है। जबकि डिजिटल क्रेडेंशियल्स के लिए अंतर्निहित प्रणालियाँ क्वालिफाइड इलेक्ट्रॉनिक सिग्नेचर (QES) और रिमोट साइनिंग क्षमताओं जैसी सुविधाओं का समर्थन कर सकती हैं (जैसा कि कानूनी रूप से बाध्यकारी हस्ताक्षरों के लिए EU डिजिटल पहचान वॉलेट जैसे व्यापक समाधानों में देखा गया है), यहाँ ध्यान, विशेष रूप से डिजिटल क्रेडेंशियल्स API के लिए, पहचान अभिकथन और ऑनलाइन इंटरैक्शन के लिए विशेषता सत्यापन पर है, न कि मुख्य रूप से इन व्यापक हस्ताक्षर कार्यात्मकताओं पर।

यह समझने के लिए कि डिजिटल क्रेडेंशियल्स कैसे काम करते हैं, एक स्तरित मॉडल की कल्पना करना सहायक होता है। प्रत्येक परत पारिस्थितिकी तंत्र के एक अलग पहलू को संबोधित करती है, डेटा प्रारूप से लेकर इसे वेब ब्राउज़र में यूज़र को कैसे प्रस्तुत किया जाता है। यह लेख मुख्य रूप से डिजिटल क्रेडेंशियल्स API पर केंद्रित है, जो प्रेजेंटेशन लेयर पर काम करता है।

मुख्य शब्दावली:

• डिजिटल क्रेडेंशियल: कोई भी मशीन-पठनीय क्रेडेंशियल (बारकोड के साथ PDF, ISO mDL, W3C VC, SD-JWT, आदि)। "डिजिटल" क्रिप्टोग्राफ़िक सत्यापन के बारे में कुछ नहीं कहता है।
• वेरिफ़ाएबल क्रेडेंशियल: एक प्रकार का डिजिटल क्रेडेंशियल, जो W3C VC डेटा मॉडल द्वारा परिभाषित है। यह छेड़छाड़-सबूत और क्रिप्टोग्राफ़िक प्रमाण जोड़ता है, और यह हमेशा तीन-पक्षीय दुनिया में रहता है: जारीकर्ता → धारक → सत्यापनकर्ता।
• वेरिफ़ाएबल क्रेडेंशियल API: बैक-एंड सिस्टम (जारीकर्ता, वॉलेट, सत्यापनकर्ता) के बीच VCs को जारी करने, संग्रहीत करने, प्रस्तुत करने और सत्यापित करने के लिए एक REST/HTTP सेवा इंटरफ़ेस।
• डिजिटल क्रेडेंशियल्स API (DC API): एक ब्राउज़र / ऑपरेटिंग-सिस्टम API (जावास्क्रिप्ट + नेटिव प्लंबिंग) जो एक वेब साइट को यूज़र के डिवाइस-साइड वॉलेट से किसी भी समर्थित डिजिटल क्रेडेंशियल (VC, ISO mDoc, SD-JWT…) को प्राइवेसी-रिस्पेक्टिंग तरीके से प्रस्तुत करने के लिए कहने देता है।

VCs को एक डेटा मॉडल के रूप में, VC API को एक बैक-एंड स्पेक के रूप में, और DC API को फ्रंट-एंड कार्यान्वयन के रूप में सोचें जो क्रेडेंशियल्स को वेब पर प्रस्तुत करता है। लेयर 1 (डेटा-मॉडल लेयर) से ऊपर सब कुछ प्रारूप-एग्नोस्टिक है; नीचे सब कुछ क्रेडेंशियल प्रारूप पर निर्भर करता है।

एंड-टू-एंड फ्लो (उदाहरण: ऑनलाइन आयु सत्यापन):

1. जारी करना (VC API - जारीकर्ता ↔ वॉलेट): राज्य DMV एक वेरिफ़ाएबल क्रेडेंशियल जारी करता है जो कहता है "धारक 18 से अधिक है"।
2. स्टोर करना (वॉलेट ऐप - OS): क्रेडेंशियल यूज़र के वॉलेट में अपने क्रिप्टो प्रूफ के साथ रहता है।
3. अनुरोध (navigator.credentials.get() DC API के माध्यम से - वेबसाइट → ब्राउज़र): बीयर-शॉप वेबसाइट पूछती है: "मुझे प्रमाण दिखाएं कि यूज़र ≥18 है।"
4. प्रस्तुत करना (DC API वॉलेट को डिस्पैच करता है → OpenID4VP (प्रोटोकॉल) → VC पेलोड): वॉलेट एक सहमति UI दिखाता है, यूज़र मंजूरी देता है, वॉलेट एक वेरिफ़ाएबल प्रेजेंटेशन वापस भेजता है।
5. सत्यापित करना (VC API - बीयर शॉप बैक-एंड): साइट का बैक-एंड हस्ताक्षर और जारीकर्ता के DID/सार्वजनिक कुंजी को सत्यापित करता है; पहुंच प्रदान करता है।

ध्यान दें कि डेटा एक VC है, वेब पर ट्रांसपोर्ट DC API है, नीचे एक्सचेंज प्रोटोकॉल OpenID4VP है, और सर्वर-साइड चेक VC API का उपयोग करता है।

यह विभाजन क्यों मौजूद है:

• इंटरऑपरेबल डेटा मॉडल (क्रिप्टोग्राफ़िक प्रूफ, सेलेक्टिव डिस्क्लोजर): VC डेटा मॉडल (और अन्य प्रारूपों) द्वारा हल किया गया।
• बैक-एंड सिस्टम के लिए मानक REST एंडपॉइंट: VC API द्वारा हल किया गया।
• वॉलेट ↔ वेब-साइट हैंडशेक जो प्राइवेसी-प्रिज़र्विंग है: DC API द्वारा हल किया गया।
• विभिन्न विश्वास स्तर / दस्तावेज़ प्रकार (सरकारी आईडी बनाम पाठ्यक्रम प्रमाण पत्र): DC API के तहत सही प्रारूप (उच्च-आश्वासन आईडी के लिए ISO mDoc; सामान्य दावों के लिए W3C VC) का उपयोग करके हल किया गया।

मुख्य बातें:

1. "डिजिटल क्रेडेंशियल" एक अम्ब्रेला टर्म है।
2. वेरिफ़ाएबल क्रेडेंशियल एक प्रकार का डिजिटल क्रेडेंशियल है जिसमें अंतर्निहित क्रिप्टोग्राफ़िक सत्यापन क्षमता होती है।
3. VC API VCs पर जीवन-चक्र संचालन के लिए सर्वर-टू-सर्वर प्लंबिंग है।
4. डिजिटल क्रेडेंशियल्स API ब्राउज़र-टू-वॉलेट ब्रिज है जो अंततः उन क्रेडेंशियल्स को वेब-ऐप्स में सुचारू रूप से प्रवाहित करने देता है, चाहे वे किसी भी ठोस प्रारूप में हों।
5. तीनों टुकड़े पूरक हैं, प्रतिस्पर्धी नहीं—वे एक ही स्टैक की विभिन्न परतों पर बैठते हैं और साथ में खुले वेब पर सुरक्षित, यूज़र-सेंट्रिक पहचान को सक्षम करते हैं।

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

प्रेजेंटेशन लेयर पर महत्वपूर्ण घटक के रूप में, डिजिटल क्रेडेंशियल्स API एक वेब मानक है जिसे वर्तमान में वेबसाइटों को यूज़र्स के डिजिटल वॉलेट से डिजिटल पहचान जानकारी का अनुरोध करने और प्राप्त करने का एक सुरक्षित और मानकीकृत तरीका प्रदान करने के लिए विकसित किया जा रहा है। यह प्रयास मुख्य रूप से W3C के Federated Identity Working Group (FedID WG) के भीतर रखा गया है, जो अप्रैल 2025 में FedID कम्युनिटी ग्रुप से माइग्रेट हुआ था। आधिकारिक ड्राफ्ट स्पेसिफिकेशन यहाँ पाया जा सकता है: https://w3c-fedid.github.io/digital-credentials/।

अक्टूबर 2025 तक, API Chrome 141 (30 सितंबर, 2025) और Safari 26 (15 सितंबर, 2025) दोनों के स्टेबल वर्ज़न में शिप हो चुका है। Chrome का कार्यान्वयन प्रोटोकॉल-एग्नोस्टिक है, जो OpenID4VP और ISO 18013-7 Annex C दोनों को सपोर्ट करता है, जबकि Safari विशेष रूप से org-iso-mdoc प्रोटोकॉल को सपोर्ट करता है। Chrome इसे Android पर अपने क्रेडेंशियल मैनेजर सिस्टम के माध्यम से नेटिव रूप से सपोर्ट करता है और डेस्कटॉप पर CTAP/BLE-समर्थित QR हैंडऑफ के माध्यम से क्रॉस-डिवाइस डिजिटल क्रेडेंशियल्स API का भी समर्थन करता है।

API navigator.credentials.get() के माध्यम से डिजिटल क्रेडेंशियल्स के लिए अनुरोधों को सक्षम करके मौजूदा क्रेडेंशियल मैनेजमेंट API का विस्तार करता है। W3C FedID WG डिजिटल क्रेडेंशियल्स एक्सप्लेनर (https://github.com/w3c-fedid/digital-credentials/blob/main/explainer.md) के अनुसार, API पहले प्रस्तावित navigator.identity के बजाय इस स्थापित इंटरफ़ेस का उपयोग करने के लिए वापस आ गया है। एक वेबसाइट डिजिटल क्रेडेंशियल्स के लिए विशिष्ट मापदंडों के साथ navigator.credentials.get() को कॉल करके एक डिजिटल क्रेडेंशियल का अनुरोध करती है।

यहाँ एक उदाहरण है कि कैसे एक वेबसाइट OpenID4VP का उपयोग करके क्रेडेंशियल का अनुरोध करने के लिए API को कॉल कर सकती है:

async function requestCredential() {
    // Check for Digital Credentials API support
    if (typeof window.DigitalCredential !== "undefined") {
        try {
            // These parameters are typically fetched from the backend.
            // Statically defined here for protocol extensibility illustration purposes.
            const oid4vp = {
                protocol: "oid4vp", // An example of an OpenID4VP request to wallets. // Based on https://github.com/openid/OpenID4VP/issues/125
                data: {
                    nonce: "n-0S6_WzA2Mj",
                    presentation_definition: {
                        //Presentation Exchange request, omitted for brevity
                    },
                },
            };
 
            // create an Abort Controller
            const controller = new AbortController();
 
            // Call the Digital Credentials API using the presentation request from the backend
            let dcResponse = await navigator.credentials.get({
                signal: controller.signal,
                mediation: "required",
                digital: {
                    requests: [oid4vp],
                },
            });
 
            // Send the encrypted response to the backend for decryption and verification
            // Ommitted for brevity
        } catch (error) {
            console.error("Error:", error);
        }
    } else {
        // fallback scenario, illustrative only
        alert("The Digital Credentials API is not supported in this browser.");
    }
}

यह उदाहरण यहाँ से लिया गया है।

डिजिटल क्रेडेंशियल्स API अनिवार्य रूप से एक सुरक्षित रैपर या मध्यस्थ के रूप में कार्य करता है। यह ब्राउज़र को पहचान जानकारी के लिए अनुरोध की मध्यस्थता करने की अनुमति देता है, अंतर्निहित ऑपरेटिंग सिस्टम की क्षमताओं का लाभ उठाते हुए उपलब्ध वॉलेट और अनुरोध से मेल खाने वाले क्रेडेंशियल्स की खोज करता है। ब्राउज़र और OS फिर क्रेडेंशियल का चयन करने और इसकी रिलीज़ को अधिकृत करने के लिए एक सुसंगत यूज़र इंटरफ़ेस प्रस्तुत कर सकते हैं, जिससे यूज़र की सहमति सुनिश्चित करके और वेबसाइटों को संवेदनशील डेटा तक चुपचाप पहुंचने से रोककर सुरक्षा और प्राइवेसी को बढ़ाया जा सकता है। प्रतिक्रिया में वास्तविक क्रेडेंशियल डेटा का उद्देश्य ब्राउज़र के लिए अपारदर्शी (एन्क्रिप्टेड) होना है, जिसमें डिक्रिप्शन और व्याख्या रिलेइंग पार्टी और वॉलेट/धारक द्वारा नियंत्रित की जाती है।

डिजिटल क्रेडेंशियल्स API को प्रोटोकॉल-एग्नोस्टिक होने के लिए डिज़ाइन किया गया है, जिसका अर्थ है कि यह क्रेडेंशियल एक्सचेंज के लिए विभिन्न अंतर्निहित प्रोटोकॉल का समर्थन कर सकता है। हालाँकि, प्रोटोकॉल के दो मुख्य परिवार वर्तमान कार्यान्वयन और चर्चाओं के केंद्र में हैं: org.iso.mdoc (ISO 18013-5 और इसके विस्तार ISO 18013-7 "Annex C" से व्युत्पन्न) और OpenID Foundation के OpenID for Verifiable Presentations (OpenID4VP) और OpenID for Verifiable Credential Issuance (OpenID4VCI) स्पेसिफिकेशन्स।

• उत्पत्ति और मानकीकरण: org.iso.mdoc मोबाइल दस्तावेज़ों के लिए डेटा प्रारूप और इंटरैक्शन मॉडल को संदर्भित करता है, मुख्य रूप से मोबाइल ड्राइविंग लाइसेंस (mDLs), जो अंतर्राष्ट्रीय मानकीकरण संगठन (ISO) और अंतर्राष्ट्रीय इलेक्ट्रोटेक्निकल (IEC) द्वारा मानकीकृत है। मूलभूत मानक ISO/IEC 18013-5 है, जो NFC, ब्लूटूथ, या QR कोड जैसी तकनीकों का उपयोग करके व्यक्तिगत (निकटता) प्रस्तुति के लिए mDL एप्लिकेशन, डेटा संरचना और प्रोटोकॉल को परिभाषित करता है। ISO/IEC 18013-7 इसे mDLs की ऑनलाइन/रिमोट प्रस्तुति को सक्षम करने के लिए विस्तारित करता है। प्रोटोकॉल स्ट्रिंग "org.iso.mdoc" विशेष रूप से ISO/IEC TS 18013-7 (Annex C) में डिजिटल क्रेडेंशियल्स API जैसे APIs के साथ उपयोग के लिए परिभाषित है।

• डेटा मॉडल: mdocs में CBOR (Concise Binary Object Representation) पर आधारित एक सख्ती से परिभाषित डेटा संरचना होती है जो सघनता और दक्षता के लिए होती है। यह सामान्य ड्राइविंग लाइसेंस विशेषताओं के लिए नेमस्पेस और डेटा तत्वों को निर्दिष्ट करता है और मजबूत क्रिप्टोग्राफ़िक सुरक्षा सुविधाओं का समर्थन करता है, जिसमें जारीकर्ता प्रमाणीकरण, डिवाइस बाइंडिंग, धारक प्रमाणीकरण (पोर्ट्रेट के माध्यम से), सत्र एन्क्रिप्शन और सेलेक्टिव डिस्क्लोजर शामिल हैं।

• विशिष्ट उपयोग के मामले: मुख्य रूप से सरकार द्वारा जारी पहचान दस्तावेज़ जैसे ड्राइविंग लाइसेंस और राष्ट्रीय आईडी। यह उच्च-आश्वासन परिदृश्यों के लिए डिज़ाइन किया गया है, दोनों व्यक्तिगत रूप से (जैसे, ट्रैफ़िक स्टॉप, प्रतिबंधित वस्तुओं के लिए आयु सत्यापन) और ऑनलाइन (जैसे, सरकारी सेवाओं तक पहुँचना, बैंक खाता खोलने के लिए दूरस्थ पहचान सत्यापन)।

• उत्पत्ति और मानकीकरण: OpenID4VP (प्रस्तुति के लिए) और OpenID4VCI (जारी करने के लिए) OpenID Foundation द्वारा विकसित स्पेसिफिकेशन्स हैं। वे वेरिफ़ाएबल क्रेडेंशियल्स के आदान-प्रदान का समर्थन करने के लिए OAuth 2.0 का विस्तार करते हैं। ये खुले मानक हैं जिनका उद्देश्य विभिन्न क्रेडेंशियल प्रकारों के लिए व्यापक इंटरऑपरेबिलिटी है, न कि केवल सरकारी। 2025 की शुरुआत तक, OpenID4VP उन्नत ड्राफ्ट चरणों में है (जैसे, अप्रैल तक ड्राफ्ट 28)। OpenID4VCI भी परिपक्व हो रहा है।
• डेटा मॉडल: OpenID4VP/VCI को क्रेडेंशियल प्रारूप-एग्नोस्टिक होने के लिए डिज़ाइन किया गया है। वे JSON/JSON-LD या JWT प्रारूपों में W3C वेरिफ़ाएबल क्रेडेंशियल्स (VCs), mdocs, SD-JWTs और अन्य प्रारूपों को ले जा सकते हैं। इंटरैक्शन मॉडल में सत्यापनकर्ता (RP) से एक प्राधिकरण अनुरोध और धारक के वॉलेट से एक प्रतिक्रिया शामिल होती है जिसमें एक vp_token (वेरिफ़ाएबल प्रेजेंटेशन टोकन) होता है। सेलेक्टिव डिस्क्लोजर को आमतौर पर प्रेजेंटेशन एक्सचेंज (DIF PE) या नए डिजिटल क्रेडेंशियल्स क्वेरी लैंग्वेज DCQL जैसी क्वेरी भाषाओं का उपयोग करके प्रबंधित किया जाता है।
• विशिष्ट उपयोग के मामले: अनुप्रयोगों की विस्तृत श्रृंखला, जिसमें पहचान सत्यापन, योग्यताओं का प्रमाण प्रदान करना (जैसे, शैक्षिक डिप्लोमा, पेशेवर प्रमाणन), सदस्यता प्रमाणन, और बहुत कुछ शामिल है। वे ऑनलाइन इंटरैक्शन के लिए अच्छी तरह से अनुकूल हैं जहाँ एक रिलेइंग पार्टी को विभिन्न जारीकर्ताओं से दावों को सत्यापित करने की आवश्यकता होती है।

यह पहचानना महत्वपूर्ण है कि ये हमेशा परस्पर अनन्य नहीं होते हैं। उदाहरण के लिए, OpenID4VP का उपयोग [org.iso.mdoc] का अनुरोध करने और परिवहन के लिए किया जा सकता है। चुनाव अक्सर विशिष्ट उपयोग के मामले, क्रेडेंशियल के प्रकार और पारिस्थितिकी तंत्र के प्रतिभागियों पर निर्भर करता है।

यूरोपीय संघ डिजिटल पहचान (EUDI) वॉलेट एक प्रमुख पहल है जिसका उद्देश्य सभी EU नागरिकों और निवासियों को पहचान दस्तावेज़ों और प्रमाणपत्रों के लिए एक सुरक्षित डिजिटल वॉलेट प्रदान करना है। EUDI वॉलेट आर्किटेक्चर और संदर्भ ढांचा स्पष्ट रूप से mdoc (विशेष रूप से मोबाइल ड्राइविंग लाइसेंस के लिए) और W3C वेरिफ़ाएबल क्रेडेंशियल्स दोनों का समर्थन करने की योजना बनाता है, प्रस्तुति और जारी करने के प्रवाह के लिए OpenID4VP और OpenID4VCI का उपयोग करता है। संदर्भ कार्यान्वयन में mDocs को स्थानांतरित करने वाले OpenID4VP और mDoc और SD-JWT-VC प्रारूपों में PIDs और mDLs जारी करने के लिए OpenID4VCI का समर्थन शामिल है। इस तरह की बड़े पैमाने की परियोजना द्वारा यह दोहरा समर्थन दोनों प्रोटोकॉल परिवारों के महत्व को रेखांकित करता है। हालाँकि, यह दिशा आलोचना से रहित नहीं है, क्योंकि कुछ पर्यवेक्षकों का कहना है कि डिजिटल क्रेडेंशियल्स API, जो "यूएस बिगटेक" कंपनियों से बहुत अधिक प्रभावित है, अंतिम EUDI वॉलेट स्पेसिफिकेशन्स में गहराई से शामिल हो सकता है। EU के एक महत्वपूर्ण बुनियादी ढांचे पर गैर-EU संस्थाओं के संभावित प्रभाव के बारे में चिंताएँ उठाई गई हैं, जैसा कि सामुदायिक मंचों जैसे इस GitHub चर्चा में चर्चा की गई है।

डिजिटल क्रेडेंशियल्स API के लिए ब्राउज़र परिदृश्य अब आकार ले चुका है, जिसमें Chrome 141 और Safari 26 ने सितंबर 2025 में स्टेबल सपोर्ट शिप किया है। ब्राउज़रों के बीच दृष्टिकोण और समर्थन स्तरों में उल्लेखनीय अंतर हैं।

Chrome ने Chrome 141 (30 सितंबर, 2025) में डिजिटल क्रेडेंशियल्स API को शिप किया। Chrome का कार्यान्वयन प्रोटोकॉल-एग्नोस्टिक है: OpenID4VP और ISO 18013-7 Annex C (mdoc ऑनलाइन) के साथ संगत। डेस्कटॉप मोबाइल वॉलेट से क्रॉस-डिवाइस प्रस्तुति का समर्थन करता है एक CTAP/BLE-समर्थित चैनल (QR हैंडऑफ) के माध्यम से, जिसमें प्रतिक्रिया ब्राउज़र के लिए अपारदर्शी होती है। API का आकार navigator.credentials.get() में चला गया; पैरामीटर का नाम बदला गया: providers → requests, request → data।

फ़ीचर डिटेक्शन:

if (typeof DigitalCredential !== "undefined") {
    // Digital Credentials API supported
}

Android का क्रेडेंशियल मैनेजर प्रस्तुति के लिए OpenID4VP और जारी करने के लिए OpenID4VCI का नेटिव रूप से समर्थन करता है, जिससे Android ऐप्स इन मानकों का उपयोग करके क्रेडेंशियल धारक और सत्यापनकर्ता के रूप में कार्य कर सकते हैं। Google बढ़ते वॉलेट समर्थन पर ध्यान देता है; Google Wallet एक शुरुआती एडॉप्टर है, जिसमें Samsung Wallet और 1Password की घोषणा की गई है।

इस लेख के पिछले संस्करणों में, हमने भविष्यवाणी की थी कि Apple का दृष्टिकोण org.iso.mdoc प्रोटोकॉल पर ध्यान केंद्रित करके Google से अलग होगा। ऐतिहासिक संदर्भ के लिए, हमारा तर्क इस प्रकार था:

जैसा कि हमने सही अनुमान लगाया था, WWDC25 ने इस रणनीति की पुष्टि की। Safari 26 (iOS/iPadOS/macOS) 15 सितंबर, 2025 को डिजिटल क्रेडेंशियल्स API सपोर्ट के साथ शिप हुआ, यह पुष्टि करते हुए कि उनका कार्यान्वयन प्रस्तुति के लिए विशेष रूप से org-iso-mdoc प्रोटोकॉल (हाइफ़नेटेड) का समर्थन करता है।

इसका विवरण WWDC25 सत्र वेब पर पहचान दस्तावेज़ों को सत्यापित करें में दिया गया था। API वेबसाइटों को पहचान दस्तावेज़ों से सत्यापन योग्य जानकारी का अनुरोध करने की अनुमति देता है, जैसे कि ड्राइवर का लाइसेंस, जो Apple Wallet या तीसरे पक्ष के दस्तावेज़ प्रदाता ऐप्स में संग्रहीत है।

Apple के कार्यान्वयन से मुख्य बातें:

• सिर्फ MDOC: API विशेष रूप से प्रोटोकॉल स्ट्रिंग "org-iso-mdoc" का उपयोग करता है, जो ISO/IEC 18013-7 Annex C मानक पर आधारित है। Safari के डिजिटल क्रेडेंशियल्स API के कार्यान्वयन में OpenID4VP के लिए कोई समर्थन नहीं है।
• केवल प्रस्तुति: API मौजूदा क्रेडेंशियल्स की प्रस्तुति (सत्यापन) के लिए है। Apple Wallet या अन्य ऐप्स में जारी करना एक अलग, गैर-ब्राउज़र प्रक्रिया बनी हुई है।
• यूज़र-सेंट्रिक और सुरक्षित: प्रवाह एक यूज़र जेस्चर द्वारा शुरू किया जाता है और एक "आंशिक अनुरोध" तंत्र का लाभ उठाता है, जहाँ OS पहले वॉलेट एप्लिकेशन को पास करने से पहले एक सैंडबॉक्स में अनुरोध को पार्स और मान्य करता है, जिससे सुरक्षा बढ़ती है।
• ऐप्स के लिए विस्तार योग्य: Apple Wallet के अलावा, तीसरे पक्ष के ऐप्स नए IdentityDocumentServices फ्रेमवर्क और एक ऐप एक्सटेंशन को लागू करके दस्तावेज़ प्रदाताओं के रूप में कार्य कर सकते हैं।
• क्रॉस-डिवाइस सपोर्ट: गैर-Apple प्लेटफ़ॉर्म से क्रॉस-डिवाइस प्रस्तुति एक QR कोड हैंडऑफ के बाद निकटता के लिए CTAP का उपयोग करती है; JS प्रतिक्रिया ब्राउज़र के लिए एन्क्रिप्टेड/अपारदर्शी बनी रहती है।

Apple ने एक स्पष्ट कोड उदाहरण प्रदान किया कि कैसे एक रिलेइंग पार्टी API का उपयोग करेगी:

async function verifyIdentity() {
    try {
        // Server generates and cryptographically signs the request data.
        const response = await fetch("drivers/license/data");
        const data = await response.json();
 
        // The request specifies the 'org-iso-mdoc' protocol.
        const request = {
            protocol: "org-iso-mdoc",
            // data contains the cryptographically signed mdoc request.
            data,
        };
 
        // The API must be called from within a user gesture.
        const credential = await navigator.credentials.get({
            mediation: "required",
            digital: {
                requests: [request],
            },
        });
 
        // Send the encrypted response from the wallet to the server for decryption and validation.
        const verificationResponse = await fetch("/decrypt", {
            method: "POST",
            body: JSON.stringify(credential.data),
            headers: {
                "Content-Type": "application/json",
            },
        });
 
        // Display the verified details...
        const json = await verificationResponse.json();
        presentDetails(json);
    } catch (err) {
        // Handle errors, e.g., user cancellation.
    }
}

यह पुष्टि ब्राउज़र बाजार में अलग-अलग रणनीतियों को मजबूत करती है। जबकि Chrome लचीले OpenID4VP ट्रांसपोर्ट लेयर पर आधारित है, Apple ISO mdoc पारिस्थितिकी तंत्र में अपने गहरे निवेश का लाभ उठाकर एक अत्यधिक एकीकृत और सुरक्षित, यद्यपि कम लचीला, समाधान प्रदान कर रहा है जो आधिकारिक पहचान दस्तावेज़ों के लिए अनुकूलित है।

Mozilla ने औपचारिक रूप से डिजिटल क्रेडेंशियल्स API पर नकारात्मक मानक स्थिति व्यक्त की है जैसा कि यह वर्तमान में है। उनकी चिंताएँ व्यापक हैं और यूज़र की प्राइवेसी, एजेंसी की रक्षा करने और एक खुले, समान वेब को सुनिश्चित करने के उनके मिशन में निहित हैं।

Mozilla द्वारा उठाई गई प्रमुख चिंताओं में शामिल हैं:

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

Mozilla स्वीकार करता है कि ऐसा API क्रेडेंशियल प्रस्तुति के लिए मौजूदा तदर्थ तरीकों पर उपयोगिता प्रदान कर सकता है, लेकिन इस बात पर जोर देता है कि नई वेब प्लेटफ़ॉर्म सुविधाओं को वेब को समग्र रूप से बेहतर बनाना चाहिए और यूज़र्स के हितों को प्राथमिकता देनी चाहिए। जबकि एक W3C परिषद ने इन चिंताओं से संबंधित एक औपचारिक आपत्ति को खारिज कर दिया (काम को W3C के भीतर आगे बढ़ने की अनुमति देने के लिए, संभावित रूप से कम पारदर्शी स्थानों के बजाय), परिषद ने सिफारिश की कि वर्किंग ग्रुप इन संभावित नुकसानों को कम करने के लिए सक्रिय रूप से काम करे।

तालिका 1: डिजिटल क्रेडेंशियल्स API और प्रोटोकॉल के लिए ब्राउज़र सपोर्ट (अक्टूबर 2025)

उन संगठनों (रिलेइंग पार्टीज़ या RPs) के लिए जो यूज़र्स से डिजिटल क्रेडेंशियल्स का अनुरोध और सत्यापन करने का इरादा रखते हैं, वर्तमान परिदृश्य में सावधानीपूर्वक रणनीतिक योजना की आवश्यकता है।

यह देखते हुए कि Safari (15 सितंबर, 2025 को शिप किया गया) डिजिटल क्रेडेंशियल्स API के माध्यम से विशेष रूप से प्रत्यक्ष org-iso-mdoc इंटरैक्शन (ISO 18013-7 Annex C) का समर्थन करता है, और Chrome (30 सितंबर, 2025 को शिप किया गया) प्रोटोकॉल-एग्नोस्टिक है जो OpenID4VP और ISO 18013-7 Annex C (mdoc) दोनों का समर्थन करता है, RPs को व्यापक संभव पहुंच के लिए दोनों दृष्टिकोणों पर आधारित इंटरैक्शन का समर्थन करने के लिए तैयार रहना चाहिए।

इसका मतलब है कि ऐसी प्रणालियों का आर्किटेक्चर करना जो कर सकती हैं:

1. navigator.credentials.get() API के माध्यम से क्रेडेंशियल अनुरोध शुरू करें, ब्राउज़र डिटेक्शन या यूज़र एजेंट क्षमताओं के आधार पर विभिन्न प्रोटोकॉल पैरामीटर ("org-iso-mdoc" Safari के लिए या "openid4vp" Chrome/OID4VP फ्लो के लिए) निर्दिष्ट करें।
2. उन प्रतिक्रियाओं को प्रोसेस करें जो सीधे mdoc प्रारूप (ISO 18013-7 Annex C) में आ सकती हैं या OpenID4VP के माध्यम से vp_token के रूप में आ सकती हैं, जिसे फिर अंतर्निहित क्रेडेंशियल (जो स्वयं एक mdoc या कोई अन्य VC प्रारूप हो सकता है) निकालने के लिए पार्स करने की आवश्यकता होती है।

जबकि यह जटिलता जोड़ता है, सभी यूज़र्स को एक ही प्रोटोकॉल पथ पर मजबूर करने का प्रयास करने से यूज़र बेस का एक बड़ा हिस्सा बाहर हो सकता है, या तो वे जो iOS पर हैं या वे जो Chrome/Android पर हैं, चुने हुए पथ के आधार पर। एक व्यावहारिक, यद्यपि अधिक विकास-गहन, दृष्टिकोण दोनों को संभालने के लिए लचीलापन बनाना है।

रिलेइंग पार्टीज़ को इस बात से पूरी तरह अवगत होना चाहिए कि एक ही तार्किक जानकारी का अनुरोध करते समय भी (जैसे, "क्या यूज़र 21 से अधिक है?"), इसे अनुरोध में कैसे परिभाषित किया जाता है और प्रतिक्रिया में कैसे लौटाया जाता है, यह एक प्रत्यक्ष mdoc क्वेरी और एक OpenID4VP क्वेरी (जो प्रेजेंटेशन एक्सचेंज या DCQL का उपयोग कर सकती है) के बीच काफी भिन्न हो सकता है।

• mdoc सेलेक्टिव डिस्क्लोजर: org.iso.mdoc में सेलेक्टिव डिस्क्लोजर के लिए अपने स्वयं के तंत्र हैं, जिसमें आमतौर पर जारीकर्ता व्यक्तिगत डेटा तत्वों के साल्टेड हैश बनाता है। धारक का वॉलेट फिर केवल अनुरोधित तत्वों को उनके साल्ट के साथ प्रकट करता है, जिससे सत्यापनकर्ता उन्हें अन्य डेटा देखे बिना हैश के खिलाफ पुष्टि कर सकता है। विशिष्ट तत्वों के लिए अनुरोध mdoc मानक के भीतर पूर्वनिर्धारित नेमस्पेस और डेटा तत्व पहचानकर्ताओं से जुड़ा होता है।
• OpenID4VP सेलेक्टिव डिस्क्लोजर: OpenID4VP आमतौर पर प्रेजेंटेशन एक्सचेंज (DIF PE) या नए डिजिटल क्रेडेंशियल्स क्वेरी लैंग्वेज (DCQL) जैसी क्वेरी भाषा का उपयोग करता है जो अनुरोध के presentation_definition के भीतर एम्बेडेड होता है। यह RPs को उनके लिए आवश्यक क्रेडेंशियल प्रकारों और व्यक्तिगत दावों को निर्दिष्ट करने की अनुमति देता है। वॉलेट फिर एक वेरिफ़ाएबल प्रेजेंटेशन का निर्माण करता है जिसमें केवल अनुरोधित जानकारी होती है, यदि क्रेडेंशियल प्रारूप और वॉलेट द्वारा समर्थित हो।

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

डिजिटल क्रेडेंशियल्स जारी करने और धारकों के लिए वॉलेट एप्लिकेशन प्रदान करने की तलाश में संस्थाओं के लिए, ऑपरेटिंग सिस्टम वातावरण एक महत्वपूर्ण भूमिका निभाता है।

वॉलेट जारीकर्ताओं को iOS और Android पर वॉलेट निर्माण, सिस्टम एकीकरण और डिजिटल क्रेडेंशियल्स API के साथ इंटरैक्शन के संबंध में अलग-अलग परिदृश्यों का सामना करना पड़ता है।

• Android: आम तौर पर एक अधिक खुला पारिस्थितिकी तंत्र प्रदान करता है। Android क्रेडेंशियल मैनेजर में एक होल्डर API शामिल है जो तीसरे पक्ष के नेटिव अनुप्रयोगों को क्रेडेंशियल धारकों के रूप में पंजीकृत करने की अनुमति देता है। ये पंजीकृत धारक ऐप्स फिर सिस्टम द्वारा मध्यस्थता वाले क्रेडेंशियल प्रस्तुति प्रवाह में भाग ले सकते हैं, डिजिटल क्रेडेंशियल्स API (Chrome के माध्यम से) या नेटिव ऐप सत्यापनकर्ताओं से अनुरोधों का जवाब दे सकते हैं। Android क्रेडेंशियल जारी करने के लिए OpenID4VCI का भी स्पष्ट रूप से समर्थन करता है, जिससे यूज़र्स को नए जारी किए गए क्रेडेंशियल्स प्राप्त करने के लिए एक संगत तीसरे पक्ष के वॉलेट का चयन करने की अनुमति मिलती है। जबकि नेटिव ऐप्स पूर्ण क्रेडेंशियल धारक क्षमताओं के लिए प्राथमिक फ़ोकस हैं, सिस्टम व्यापक भागीदारी के लिए डिज़ाइन किया गया है।

• iOS: Apple अपने पारिस्थितिकी तंत्र पर कड़ा नियंत्रण रखता है। जबकि तीसरे पक्ष के वॉलेट ऐप्स ऐप स्टोर पर मौजूद हो सकते हैं, उच्च-आश्वासन क्रेडेंशियल्स (जैसे Apple वॉलेट के लिए अभिप्रेत mDLs) के लिए सिस्टम-स्तरीय क्रेडेंशियल धारकों के रूप में गहराई से एकीकृत करने की उनकी क्षमता अक्सर Apple की विशिष्ट प्रक्रियाओं और अधिकारों के अधीन होती है। उदाहरण के लिए, Apple वॉलेट में एक आईडी जोड़ना, राज्य जारी करने वाले अधिकारियों और Apple की सत्यापन प्रक्रिया को शामिल करने वाला एक नियंत्रित प्रवाह है। Safari में डिजिटल क्रेडेंशियल्स API के लिए, इंटरैक्शन को निकटता से प्रबंधित किए जाने की संभावना है, जिसमें प्राथमिक ध्यान अधिकृत स्रोतों, अर्थात् Apple वॉलेट और पंजीकृत तीसरे पक्ष के दस्तावेज़ प्रदाता ऐप्स से प्रस्तुत org.iso.mdoc पर होगा।

Apple का "वॉल्ड गार्डन" दृष्टिकोण अच्छी तरह से स्थापित है, और डिजिटल क्रेडेंशियल्स का उनका कार्यान्वयन कोई अपवाद नहीं है। हालाँकि, WWDC25 ने तीसरे पक्ष की भागीदारी के लिए मार्ग स्पष्ट किया।

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

वेब फ्लो में भाग लेने के लिए, एक नेटिव ऐप को यह करना होगा:

1. दस्तावेज़ पंजीकृत करें: IdentityDocumentProviderRegistrationStore का उपयोग करके ऐप द्वारा प्रबंधित mdocs को ऑपरेटिंग सिस्टम के साथ पंजीकृत करें। इस पंजीकरण में दस्तावेज़ प्रकार और अनुरोध पर हस्ताक्षर के लिए विश्वसनीय प्रमाणपत्र प्राधिकरण शामिल हैं।
2. एक ऐप एक्सटेंशन लागू करें: प्रोजेक्ट में एक "आइडेंटिटी डॉक्यूमेंट प्रोवाइडर" UI ऐप एक्सटेंशन जोड़ें। यह एक्सटेंशन वेब-आधारित सत्यापन प्रवाह के दौरान ऐप का चयन होने पर यूज़र को प्राधिकरण UI प्रदर्शित करने के लिए जिम्मेदार है।

इसका मतलब है कि जबकि iOS पर एक पूरी तरह से एकीकृत वॉलेट बनाने के लिए एक नेटिव एप्लिकेशन बनाने और Apple के विशिष्ट फ्रेमवर्क का उपयोग करने की आवश्यकता होती है—न कि PWA जैसी वेब तकनीकों की—तीसरे पक्ष के ऐप्स के लिए Apple वॉलेट के साथ दस्तावेज़ प्रदाताओं के रूप में कार्य करने के लिए एक स्पष्ट, यद्यपि कसकर नियंत्रित, तंत्र है। यह पुष्टि करता है कि Safari में डिजिटल क्रेडेंशियल्स API के साथ इंटरैक्शन OS द्वारा प्रबंधित किया जाता है, जो फिर अनुरोधों को Apple वॉलेट या किसी अन्य पंजीकृत और अधिकृत दस्तावेज़ प्रदाता ऐप को भेजता है।

डिजिटल क्रेडेंशियल्स API डिजिटल पहचान के क्षेत्र में एक महत्वपूर्ण प्रगति का प्रतिनिधित्व करता है, जो पहचान सत्यापन और क्रेडेंशियल प्रस्तुति के लिए एक अधिक सुरक्षित, यूज़र-सेंट्रिक और प्राइवेसी-प्रिज़र्विंग दृष्टिकोण प्रदान करता है। Chrome 141 (30 सितंबर, 2025) और Safari 26 (15 सितंबर, 2025) के अब स्टेबल सपोर्ट शिप करने के साथ, API प्रायोगिक से उत्पादन-तैयार हो गया है। जैसे-जैसे पारिस्थितिकी तंत्र विकसित होता जा रहा है, रिलेइंग पार्टी और वॉलेट जारीकर्ताओं दोनों के लिए इस नई तकनीक की क्षमता को अपनाना और अनुकूलित करना महत्वपूर्ण है। हम इस लेख को परिदृश्य में बदलाव के साथ अद्यतन रखेंगे।

हालांकि, चुनौतियां बनी हुई हैं। विभिन्न क्रेडेंशियल प्रारूपों, प्रोटोकॉल और वॉलेट कार्यान्वयन के बीच सच्ची वैश्विक इंटरऑपरेबिलिटी प्राप्त करना एक महत्वपूर्ण उपक्रम है। Mozilla जैसे संगठनों द्वारा प्राइवेसी, बहिष्करण और यूज़र एजेंसी के संबंध में उठाई गई वैध चिंताओं को संबोधित करना यह सुनिश्चित करने के लिए सर्वोपरि है कि ये प्रौद्योगिकियां मानवता की सेवा करें। अलग-अलग दृष्टिकोण—Chrome का प्रोटोकॉल-एग्नोस्टिक कार्यान्वयन बनाम Safari का सिर्फ mdoc फ़ोकस—का मतलब है कि रिलेइंग पार्टी और वॉलेट जारीकर्ताओं को निकट भविष्य के लिए एक दोहरे-प्रोटोकॉल परिदृश्य में नेविगेट करना होगा।