डिजिटल क्रेडेंशियल्स API (2025): Chrome और Safari (WWDC25)

अंतिम अपडेट: 15 जुलाई, 2025 (WWDC25 के बाद)

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

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

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

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

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

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

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

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

Want to try digital credentials yourself in a demo?

Try Digital Credentials

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

मुख्य बातें:

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

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

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

2025 तक, API को अभी भी महत्वपूर्ण परिवर्तनों से गुजरने के रूप में वर्णित किया गया है। यह इसके सक्रिय विकास चरण को उजागर करता है। इसके बावजूद, इसकी क्षमता महत्वपूर्ण है। Chrome ने अपने ओरिजिन ट्रायल के साथ सार्वजनिक रूप से कुछ शिप करने वाला पहला ब्राउज़र रहा है, जिससे डेवलपर्स को इसकी क्षमताओं के साथ प्रयोग करने की अनुमति मिलती है। Chrome इसे अपने क्रेडेंशियल मैनेजर सिस्टम के माध्यम से Android पर मूल रूप से भी समर्थन करता है और हाल ही में डेस्कटॉप पर क्रॉस-डिवाइस डिजिटल क्रेडेंशियल्स API उपयोग के लिए भी समर्थन प्रकाशित किया है।

API मौजूदा क्रेडेंशियल मैनेजमेंट API का विस्तार navigator.credentials.get() के माध्यम से डिजिटल क्रेडेंशियल्स के लिए अनुरोधों को सक्षम करके करता है। 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 तब क्रेडेंशियल का चयन करने और इसकी रिलीज़ को अधिकृत करने के लिए एक सुसंगत उपयोगकर्ता इंटरफ़ेस प्रस्तुत कर सकते हैं, जिससे उपयोगकर्ता की सहमति सुनिश्चित करके और वेबसाइटों को चुपचाप संवेदनशील डेटा तक पहुँचने से रोककर सुरक्षा और गोपनीयता बढ़ जाती है। प्रतिक्रिया में वास्तविक क्रेडेंशियल डेटा का उद्देश्य ब्राउज़र के लिए अपारदर्शी (एन्क्रिप्टेड) होना है, जिसमें डिक्रिप्शन और व्याख्या relying party और wallet/holder द्वारा नियंत्रित की जाती है।

डिजिटल क्रेडेंशियल्स API को प्रोटोकॉल-अज्ञेयवादी होने के लिए डिज़ाइन किया गया है, जिसका अर्थ है कि यह क्रेडेंशियल exchange के लिए विभिन्न अंतर्निहित प्रोटोकॉल का समर्थन कर सकता है। हालाँकि, प्रोटोकॉल के दो मुख्य परिवार वर्तमान कार्यान्वयन और चर्चाओं के केंद्र में हैं: org.iso.mDoc (ISO 18013-5 और इसके विस्तार ISO 18013-7 "अनुलग्नक C" से व्युत्पन्न) और ओपनआईडी फाउंडेशन के वेरिफ़िएबल प्रेजेंटेशन्स के लिए ओपनआईडी (OpenID4VP) और वेरिफ़िएबल क्रेडेंशियल जारी करने के लिए ओपनआईडी (OpenID4VCI) विनिर्देश।

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

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

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

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

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

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

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

Google Chrome, विशेष रूप से Android पर, डिजिटल क्रेडेंशियल्स API का एक प्रारंभिक अपनाने वाला और कार्यान्वयनकर्ता रहा है। उन्होंने ओरिजिन ट्रायल चलाए हैं और इसे Android के मूल क्रेडेंशियल मैनेजर के साथ एकीकृत किया है। Chrome का कार्यान्वयन मुख्य रूप से navigator.credentials.get() API कॉल के माध्यम से क्रेडेंशियल्स का अनुरोध करने के लिए प्रोटोकॉल के रूप में OpenID4VP का लाभ उठाता है। जबकि OpenID4VP स्वयं प्रारूप-अज्ञेयवादी है और पेलोड के रूप में org.iso.mdoc या W3C वेरिफ़िएबल क्रेडेंशियल्स ले जा सकता है, Google से व्यावहारिक जोर परिवहन तंत्र के रूप में OpenID4VP प्रवाह पर प्रतीत होता है। Android का क्रेडेंशियल मैनेजर प्रस्तुति के लिए OpenID4VP और issuance के लिए OpenID4VCI का भी मूल रूप से समर्थन करता है। यह Android ऐप्स को इन मानकों का उपयोग करके क्रेडेंशियल धारकों और सत्यापनकर्ताओं के रूप में कार्य करने की अनुमति देता है।

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

जैसा कि हमने सही अनुमान लगाया था, WWDC25 ने इस रणनीति की पुष्टि की। सम्मेलन में, Apple ने आधिकारिक तौर पर Safari 26 (जो पतझड़ 2025 में iOS 26 और अन्य OS अपडेट के साथ शिपिंग होगा) में API के लिए समर्थन की घोषणा की, यह पुष्टि करते हुए कि उनका कार्यान्वयन प्रस्तुति के लिए विशेष रूप से org.iso.mdoc प्रोटोकॉल का समर्थन करता है।

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

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

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

Apple ने एक स्पष्ट कोड उदाहरण प्रदान किया कि कैसे एक Relying Party 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 प्रस्ताव पर "नकारात्मक" स्थिति व्यक्त की है जैसा कि यह वर्तमान में है। उनकी चिंताएँ व्यापक हैं और user privacy, एजेंसी की रक्षा करने और एक खुले, न्यायसंगत web को सुनिश्चित करने के उनके मिशन में निहित हैं।

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

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

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

तालिका 1: डिजिटल क्रेडेंशियल्स API और प्रोटोकॉल के लिए ब्राउज़र समर्थन

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

यह देखते हुए कि Safari, अपने महत्वपूर्ण बाज़ार हिस्से के साथ, डिजिटल क्रेडेंशियल्स API के माध्यम से सीधे org.iso.mdoc इंटरैक्शन को प्राथमिकता देने की संभावना है, और Chrome/Android OpenID4VP पर जोर दे रहे हैं (जो mdocs या अन्य वेरिफ़िएबल क्रेडेंशियल प्रारूप ले जा सकता है), व्यापक संभव पहुँच का लक्ष्य रखने वाले RPs को दोनों दृष्टिकोणों पर आधारित इंटरैक्शन का समर्थन करने के लिए तैयार रहना चाहिए।

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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