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

आखरी अपडेट: 26 मार्च, 2026

प्रमुख ब्राउज़रों में Digital Credentials API के सपोर्ट का एक क्विक ओवरव्यू:

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

Want to experience digital credentials in action?

Try Digital Credentials

अक्टूबर 2025 से अब तक क्या बदला है?

• प्रोटोकॉल गवर्नेंस में बदलाव: W3C FedID WG ने TPAC (नवंबर 2025) में ओपन प्रोटोकॉल रजिस्ट्री को समाप्त कर दिया और अब सीधे स्पेक में समर्थित प्रोटोकॉल को हार्डकोड कर दिया है: OpenID4VP, OpenID4VCI, और ISO 18013-7 Annex C। अब यह API केवल एक "dumb pipe" नहीं रहा।
• Issuance का आगमन: Chrome 143 ने navigator.credentials.create() के माध्यम से क्रेडेंशियल issuance (जारी करने) के लिए एक Origin Trial लॉन्च किया, जिससे API का विस्तार केवल प्रेजेंटेशन तक सीमित नहीं रहा।
• Firefox का इंप्लीमेंटेशन: अपने negative standards position में बदलाव न होने के बावजूद, Mozilla ने Firefox 149 में बेसलाइन DC API कोड लैंड किया और UX पर काम जारी है।
• EU का सशर्त जनादेश: EUDI Architecture Reference Framework (Topic F) अब सभी सदस्य राज्यों के वॉलेट्स के लिए DC API सपोर्ट को सशर्त रूप से अनिवार्य करता है।
• वास्तविक दुनिया में अपनाना: कैलिफ़ोर्निया DMV ने अपने OpenCred प्लेटफ़ॉर्म (फरवरी 2026) में DC API सपोर्ट जोड़ा।

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

इस आर्टिकल में, हमारा उद्देश्य Digital Credentials API की मौजूदा स्थिति पर चर्चा करना है—यह एक महत्वपूर्ण विकास है जो वेब पर आइडेंटिटी की जानकारी के साथ हमारे इंटरैक्ट करने के तरीके को बदलने का वादा करता है। हम इसके अंतर्निहित तंत्र, इसके द्वारा समर्थित प्रोटोकॉल, वर्तमान ब्राउज़र अपनाने की स्थिति का पता लगाएंगे, और इस तेजी से बदलते परिदृश्य को नेविगेट करने वाले Relying Parties और Wallet Issuers (जारीकर्ताओं) दोनों के लिए सिफारिशें प्रदान करेंगे।

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

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

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

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

Want to experience digital credentials in action?

Try Digital Credentials

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

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

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

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

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

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

यह लेख digital credentials के सत्यापन (verification) और सेलेक्टिव डिस्क्लोज़र के सिद्धांत पर केंद्रित है, जिससे Users को पूरे स्रोत दस्तावेज़ को प्रकट किए बिना विशिष्ट विशेषताओं (जैसे, "मेरी उम्र 18 से अधिक है," "मेरे पास वैध ड्राइविंग लाइसेंस है") को साबित करने में सक्षम बनाया जा सके। जबकि digital credentials के लिए अंतर्निहित सिस्टम Qualified Electronic Signatures (QES) और रिमोट साइनिंग क्षमताओं जैसी सुविधाओं का समर्थन कर सकते हैं (जैसे कि कानूनी रूप से बाध्यकारी हस्ताक्षर के लिए EU डिजिटल आइडेंटिटी वॉलेट जैसे व्यापक समाधानों में देखा गया है), यहाँ फोकस, विशेष रूप से Digital Credentials API के लिए, ऑनलाइन इंटरैक्शन के लिए पहचान assertion और एट्रिब्यूट वेरिफिकेशन पर है, न कि मुख्य रूप से इन व्यापक साइनिंग कार्यक्षमताओं पर।

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

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

• Digital credential: कोई भी मशीन-पठनीय (machine-readable) क्रेडेंशियल (बारकोड के साथ PDF, ISO mDL, W3C VC, SD-JWT, आदि)। "Digital" शब्द क्रिप्टोग्राफिक सत्यापन के बारे में कुछ नहीं कहता है।
• Verifiable Credential: एक प्रकार का digital credential, जिसे W3C VC डेटा मॉडल द्वारा परिभाषित किया गया है। यह टैम्पर-एविडेंस (छेड़छाड़ के सबूत) और क्रिप्टोग्राफिक प्रूफ जोड़ता है, और यह हमेशा तीन-पक्षीय दुनिया में रहता है: Issuer → Holder → Verifier।
• Verifiable Credential API: बैक-एंड सिस्टम (Issuers, Wallets, Verifiers) के बीच VC जारी करने, संग्रहीत करने, प्रस्तुत करने और सत्यापित करने के लिए एक REST/HTTP सेवा इंटरफ़ेस।
• Digital Credentials API (DC API): एक ब्राउज़र / ऑपरेटिंग-सिस्टम API (JavaScript + native plumbing) जो एक वेबसाइट को उपयोगकर्ता के डिवाइस-साइड वॉलेट से किसी भी समर्थित digital credential (VC, ISO mDoc, SD-JWT…) को गोपनीयता का सम्मान करते हुए प्रस्तुत करने के लिए कहने की अनुमति देता है।

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

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

निम्नलिखित आरेख दिखाता है कि ये परतें वास्तविक दुनिया के परिदृश्य में एक साथ कैसे काम करती हैं।

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

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

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

मुख्य बातें:

1. "Digital credential" एक व्यापक शब्द है।
2. Verifiable Credential एक प्रकार का digital credential है जिसमें बिल्ट-इन क्रिप्टोग्राफिक सत्यापन क्षमता होती है।
3. VC API VCs पर जीवन-चक्र संचालन (life-cycle operations) के लिए सर्वर-टू-सर्वर प्लंबिंग है।
4. Digital Credentials API ब्राउज़र-टू-वॉलेट ब्रिज है जो अंततः उन credentials को वेब-ऐप्स में सुचारू रूप से प्रवाहित करने देता है, चाहे वे किसी भी ठोस प्रारूप में हों।
5. ये तीन टुकड़े पूरक हैं, प्रतिस्पर्धी नहीं—वे एक ही स्टैक की विभिन्न परतों पर बैठते हैं और एक साथ ओपन वेब पर सुरक्षित, यूजर-सेंट्रिक आइडेंटिटी को सक्षम करते हैं।

प्रतिभागियों और digital credentials के समग्र स्तरित आर्किटेक्चर का पता लगाने के बाद, यह लेख अब प्रेजेंटेशन लेयर (presentation layer) में गहराई से जाएगा, विशेष रूप से Digital Credentials API और इसकी वर्तमान स्थिति पर ध्यान केंद्रित करेगा।

प्रेजेंटेशन लेयर पर महत्वपूर्ण घटक के रूप में, Digital Credentials API एक वेब मानक है जिसे वर्तमान में वेबसाइटों को उपयोगकर्ताओं के डिजिटल वॉलेट्स से डिजिटल आइडेंटिटी की जानकारी का अनुरोध करने और प्राप्त करने के लिए एक सुरक्षित और मानकीकृत तरीका प्रदान करने के लिए विकसित किया जा रहा है। यह प्रयास मुख्य रूप से W3C के Federated Identity Working Group (FedID WG) के भीतर है, जो अप्रैल 2025 में FedID Community Group से माइग्रेट हुआ था। आधिकारिक ड्राफ्ट स्पेसिफिकेशन यहां पाया जा सकता है: 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 प्रोटोकॉल का समर्थन करता है।

महत्वपूर्ण (मार्च 2026 अपडेट): प्रोटोकॉल के साथ API का संबंध मौलिक रूप से बदल गया है। नवंबर 2025 में TPAC में, W3C FedID WG सहमति पर पहुंचा कि ओपन प्रोटोकॉल रजिस्ट्री को समाप्त कर दिया जाए और इसके बजाय सीधे स्पेक में समर्थित प्रोटोकॉल की एक सीमित सूची को हार्डकोड किया जाए: openid4vp-v1-unsigned, openid4vp-v1-signed, openid4vp-v1-multisigned, org-iso-mdoc (प्रेजेंटेशन के लिए), और openid4vci-v1 (issuance के लिए)। User agents से अपेक्षा की जाती है कि वे गैर-सूचीबद्ध प्रोटोकॉल को अस्वीकार कर दें। यह वर्किंग ग्रुप को भविष्य के प्रोटोकॉल को जोड़ने के लिए एक वास्तविक गेटकीपर बनाता है — एक जानबूझकर किया गया समझौता ताकि API के माध्यम से प्रवाहित होने वाली हर चीज की समग्र सुरक्षा और गोपनीयता समीक्षा को सक्षम किया जा सके (वर्तमान वर्किंग ड्राफ्ट देखें)।

स्पेक अब navigator.credentials.create() के माध्यम से credential issuance (क्रेडेंशियल जारी करने) को भी कवर करता है। Chrome 143 ने इसके लिए एक Origin Trial लॉन्च किया, जिससे वेबसाइटें OpenID4VCI का उपयोग करके वॉलेट प्रोविज़निंग फ्लो को ट्रिगर कर सकती हैं। हालांकि, एक वॉलेट सिलेक्शन बाइंडिंग भेद्यता (wallet selection binding vulnerability) — जहां एक दुर्भावनापूर्ण वॉलेट ऐप issuance प्री-ऑथोराइजेशन कोड को इंटरसेप्ट कर सकता है — एक खुली चिंता बनी हुई है। सरकारी जारीकर्ताओं ने संकेत दिया है कि जब तक इसका समाधान नहीं हो जाता, वे ब्राउज़र-मध्यस्थता (browser-mediated) issuance को नहीं अपनाएंगे।

Chrome अपने Credential Manager सिस्टम के माध्यम से Android पर प्रेजेंटेशन को मूल रूप से (natively) सपोर्ट करता है और डेस्कटॉप पर CTAP/BLE-बैक्ड QR हैंडऑफ के माध्यम से क्रॉस-डिवाइस Digital Credentials API का भी समर्थन करता है।

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

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

async function requestCredential() {
    // Digital Credentials API सपोर्ट की जांच करें
    if (typeof window.DigitalCredential !== "undefined") {
        try {
            // ये पैरामीटर आमतौर पर बैकएंड से प्राप्त किए जाते हैं।
            // प्रोटोकॉल एक्स्टेंसिबिलिटी समझाने के लिए यहाँ स्थिर रूप से परिभाषित किया गया है।
            const oid4vp = {
                protocol: "oid4vp", // वॉलेट्स के लिए OpenID4VP अनुरोध का एक उदाहरण। // Based on https://github.com/openid/OpenID4VP/issues/125
                data: {
                    nonce: "n-0S6_WzA2Mj",
                    presentation_definition: {
                        //Presentation Exchange अनुरोध, संक्षेप के लिए छोड़ दिया गया
                    },
                },
            };
 
            // Abort Controller बनाएं
            const controller = new AbortController();
 
            // बैकएंड से प्रेजेंटेशन अनुरोध का उपयोग करके Digital Credentials API को कॉल करें
            let dcResponse = await navigator.credentials.get({
                signal: controller.signal,
                mediation: "required",
                digital: {
                    requests: [oid4vp],
                },
            });
 
            // डिक्रिप्शन और वेरिफिकेशन के लिए एन्क्रिप्टेड प्रतिक्रिया बैकएंड को भेजें
            // संक्षेप के लिए छोड़ दिया गया
        } catch (error) {
            console.error("Error:", error);
        }
    } else {
        // फ़ॉलबैक परिदृश्य, केवल उदाहरणात्मक
        alert("The Digital Credentials API is not supported in this browser.");
    }
}

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

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

Digital Credentials API को मूल रूप से पूरी तरह से प्रोटोकॉल-एग्नोस्टिक (protocol-agnostic) होने के लिए डिज़ाइन किया गया था, जो किसी भी प्रोटोकॉल को रजिस्टर करने के लिए एक खुली रजिस्ट्री के साथ "dumb pipe" के रूप में कार्य करता है। हालांकि, जनवरी 2026 तक, स्पेक अब स्पष्ट रूप से उन प्रोटोकॉल को नाम देता है जिनका वह समर्थन करता है — User agents से गैर-सूचीबद्ध लोगों को अस्वीकार करने की अपेक्षा की जाती है। स्पेक में वर्तमान में हार्डकोड किए गए प्रोटोकॉल के दो मुख्य परिवार हैं: 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, Bluetooth, या QR कोड्स जैसी तकनीकों का उपयोग करके व्यक्तिगत (निकटता) प्रस्तुति के लिए mDL एप्लिकेशन, डेटा संरचना और प्रोटोकॉल को परिभाषित करता है। ISO/IEC 18013-7 इसे mDLs की ऑनलाइन/रिमोट प्रस्तुति को सक्षम करने के लिए विस्तारित करता है। प्रोटोकॉल स्ट्रिंग "org.iso.mdoc" को विशेष रूप से ISO/IEC TS 18013-7 (Annex C) में Digital Credentials API जैसे API के साथ उपयोग के लिए परिभाषित किया गया है।

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

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

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

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

यूरोपीय संघ डिजिटल आइडेंटिटी (EUDI) वॉलेट एक प्रमुख पहल है जिसका उद्देश्य सभी यूरोपीय संघ के नागरिकों और निवासियों को पहचान दस्तावेजों और attestations के लिए एक सुरक्षित डिजिटल वॉलेट प्रदान करना है। EUDI वॉलेट आर्किटेक्चर और रेफरेन्स फ्रेमवर्क स्पष्ट रूप से mdoc (विशेष रूप से मोबाइल ड्राइविंग लाइसेंस के लिए) और W3C Verifiable Credentials दोनों का समर्थन करने की योजना बना रहे हैं, जो प्रेजेंटेशन और जारी करने के प्रवाह के लिए OpenID4VP और OpenID4VCI का उपयोग करते हैं। रेफरेन्स इम्प्लीमेंटेशन में mDocs स्थानांतरित करने वाले OpenID4VP और mDoc तथा SD-JWT-VC प्रारूपों में PIDs और mDLs जारी करने के लिए OpenID4VCI का समर्थन शामिल है। ऐसे बड़े पैमाने के प्रोजेक्ट द्वारा यह दोहरा समर्थन (dual support) दोनों प्रोटोकॉल परिवारों के महत्व को रेखांकित करता है।

मार्च 2026 अपडेट: Digital Credentials API के प्रति EU की प्रतिबद्धता और अधिक ठोस हो गई है। EUDI Architecture Reference Framework (ARF) Topic F अब सशर्त रूप से अनिवार्य करता है कि EUDI वॉलेट यूनिट्स और Relying Parties रिमोट प्रेजेंटेशन और अटेस्टेशन जारी करने के प्रवाह के लिए DC API का समर्थन करें। शर्तों में DC API का W3C Recommendation स्टेटस तक पहुंचना और कार्यक्षमता, ब्राउज़र/OS तटस्थता, गोपनीयता और डिनायल-ऑफ-सर्विस सुरक्षा के आसपास की उम्मीदों को पूरा करना शामिल है। European Wallet Consortium (EWC) ने DC API टेस्ट केसेस को अपने कन्फॉरमेंस टेस्टिंग प्रोग्राम में शामिल किया है, और NOBID consortium ने OpenID4VP का उपयोग करके भुगतान पायलट पूरे किए — वही प्रोटोकॉल जिसे DC API अब कैरी करता है।

हालांकि, यह दिशा आलोचना से मुक्त नहीं है, क्योंकि कुछ पर्यवेक्षकों का मानना है कि Digital Credentials API, जो "US Bigtech" कंपनियों से काफी प्रभावित है, अंतिम EUDI वॉलेट विनिर्देशों में गहराई से शामिल हो सकता है। यूरोपीय संघ के बुनियादी ढांचे के एक महत्वपूर्ण हिस्से पर गैर-यूरोपीय संघ की संस्थाओं के संभावित प्रभाव के बारे में चिंताएं उठाई गई हैं, जैसा कि इस GitHub चर्चा जैसे सामुदायिक मंचों में चर्चा की गई है। इसके अलावा, स्पेक में ISO 18013-7 संदर्भ को हार्डकोड करने के निर्णय ने Ping Identity से आपत्ति खींची है, जिसमें तर्क दिया गया है कि पे-वॉल्ड स्पेसिफिकेशन (paywalled specification) को मानक रूप से संदर्भित करना ओपन वेब सिद्धांतों के साथ संघर्ष करता है — एक चिंता जो Candidate Recommendation के लिए स्पेक के संक्रमण के समय एक औपचारिक आपत्ति के रूप में सामने आ सकती है।

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

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

Feature Detection:

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

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

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

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

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

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

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

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

async function verifyIdentity() {
    try {
        // सर्वर अनुरोध डेटा उत्पन्न करता है और क्रिप्टोग्राफिक रूप से साइन करता है।
        const response = await fetch("drivers/license/data");
        const data = await response.json();
 
        // अनुरोध 'org-iso-mdoc' प्रोटोकॉल को निर्दिष्ट करता है।
        const request = {
            protocol: "org-iso-mdoc",
            // डेटा में क्रिप्टोग्राफिक रूप से साइन किया गया mdoc अनुरोध होता है।
            data,
        };
 
        // API को एक उपयोगकर्ता जेस्चर के भीतर से कॉल किया जाना चाहिए।
        const credential = await navigator.credentials.get({
            mediation: "required",
            digital: {
                requests: [request],
            },
        });
 
        // डिक्रिप्शन और वैलिडेशन के लिए वॉलेट से एन्क्रिप्टेड प्रतिक्रिया सर्वर को भेजें।
        const verificationResponse = await fetch("/decrypt", {
            method: "POST",
            body: JSON.stringify(credential.data),
            headers: {
                "Content-Type": "application/json",
            },
        });
 
        // सत्यापित विवरण प्रदर्शित करें...
        const json = await verificationResponse.json();
        presentDetails(json);
    } catch (err) {
        // त्रुटियों को संभालें, उदाहरण के लिए, उपयोगकर्ता द्वारा रद्दीकरण।
    }
}

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

Mozilla ने मूल रूप से Digital Credentials API पर एक negative standards position (नकारात्मक मानक स्थिति) व्यक्त की थी। उनकी चिंताएं, विस्तार से प्रलेखित, व्यापक हैं और उपयोगकर्ता की गोपनीयता, एजेंसी की रक्षा करने और एक खुले, समान वेब को सुनिश्चित करने के उनके मिशन में निहित हैं।

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

• गोपनीयता जोखिम (Privacy Risks): व्यक्तिगत डेटा साझा करने में वृद्धि और ऑनलाइन गुमनामी में कमी की संभावना यदि digital credentials के लिए अनुरोध तुच्छ बातचीत (trivial interactions) के लिए आम हो जाते हैं।
• उपयोगकर्ता बहिष्करण (User Exclusion): जोखिम है कि जो व्यक्ति digital credentials का उपयोग नहीं कर सकते या नहीं करना चाहते हैं, उन्हें ऑनलाइन सेवाओं और समुदायों से बाहर रखा जा सकता है। सरकार द्वारा जारी क्रेडेंशियल्स, एक प्राथमिक उपयोग का मामला, किसी व्यक्ति की पहचान प्रस्तुति की पसंद के साथ संरेखित नहीं हो सकता है।
• इंटरऑपरेबिलिटी समस्याएं: क्रेडेंशियल प्रारूपों के प्रसार के बारे में चिंताएं, जिससे सार्वभौमिक रूप से इंटरऑपरेबल होने के बजाय एक खंडित पारिस्थितिकी तंत्र (fragmented ecosystem) बन जाता है।
• सेलेक्टिव डिस्क्लोज़र: चिंता है कि सेलेक्टिव डिस्क्लोज़र के गोपनीयता लाभों को कम किया जा सकता है यदि इसे मज़बूत अनलिंकेबिलिटी गारंटी के साथ लागू नहीं किया जाता है, या यदि उपयोगकर्ता पूरी तरह से नहीं समझते हैं कि क्या साझा किया जा रहा है।
• विश्वास का केंद्रीकरण और उपयोगकर्ता एजेंसी: डर है कि API विश्वास के केंद्रीकरण में वृद्धि और उपयोगकर्ता एजेंसी में कमी का कारण बन सकता है, जिससे मौजूदा सामाजिक शक्ति असंतुलन कायम रह सकता है।

जबकि एक W3C Council ने इन चिंताओं से संबंधित औपचारिक आपत्ति को खारिज कर दिया (ताकि W3C के भीतर काम को आगे बढ़ने की अनुमति दी जा सके, बजाय संभावित रूप से कम पारदर्शी स्थानों के), काउंसिल ने सिफारिश की कि वर्किंग ग्रुप इन संभावित नुकसानों को कम करने के लिए सक्रिय रूप से काम करे।

मार्च 2026 अपडेट — कार्यान्वयन चल रहा है: औपचारिक नकारात्मक स्थिति तकनीकी रूप से अपरिवर्तित रहने के बावजूद, Mozilla ने Digital Credentials API को सक्रिय रूप से लागू करना शुरू कर दिया है। Q1 2026 में, बेसलाइन DC API सपोर्ट Firefox 149 (एक वरीयता फ्लैग के पीछे) में आ गया, जिसे meta bug 2004828 के तहत ट्रैक किया गया है। सोर्स कोड mozilla-central में DigitalCredential.cpp, WebIDL बाइंडिंग और IPC प्लंबिंग सहित मौजूद है। डेस्कटॉप और Android परमिशन प्रॉम्प्ट्स (bug 2010091, bug 2010093) पर काम चल रहा है।

तीन Mozilla इंजीनियर — John Schanck, Martin Thomson, और Benjamin VanderSloot — W3C FedID वर्किंग ग्रुप के सक्रिय सदस्य हैं, और Schanck credential presentation algorithm और request preparation algorithm सहित प्रमुख स्पेक PRs पर ठोस कार्यान्वयन-सूचित प्रतिक्रिया प्रदान कर रहे हैं।

यह एक महत्वपूर्ण विकास है: जबकि Mozilla API के दुरुपयोग की संभावना के बारे में अपनी चिंताओं को बनाए रखता है, यह स्पष्ट रूप से अन्य ब्राउज़र विक्रेताओं को डिज़ाइन सौंपने के बजाय भीतर से API को आकार देने का चयन कर रहा है — स्पेक कार्य और कार्यान्वयन दोनों के माध्यम से। यह संकेत देता है कि Digital Credentials API संभवतः तीन-ब्राउज़र समर्थन की ओर बढ़ रहा है, हालांकि Mozilla मज़बूत गोपनीयता गार्डरेल्स (क्रेडेंशियल अनुरोधों के लिए प्रस्तावित transparency log सहित) के लिए जोर दे रहा है।

तालिका 1: Digital Credentials API और प्रोटोकॉल के लिए ब्राउज़र सपोर्ट (मार्च 2026)