डिजिटल पहचान और क्रेडेंशियल के बारे में अक्सर पूछे जाने वाले सवाल

इस पेज पर, डिजिटल पहचान और क्रेडेंशियल के लिए Google Wallet के साथ इंटिग्रेट करने के बारे में अक्सर पूछे जाने वाले सवालों के जवाब दिए गए हैं.

शामिल हों और शुरू करें

सवाल: किसी नए पार्टनर को Relying Party (RP) के तौर पर शामिल करने की चरण-दर-चरण प्रोसेस क्या है?

जवाब: Wallet Online से आईडी स्वीकार करना पर दिए गए निर्देशों को पढ़ें.

सवाल: आरपी के तौर पर रजिस्टर करने की प्रोसेस पूरी होने में आम तौर पर कितना समय लगता है?

जवाब: आम तौर पर, ऑनबोर्डिंग में तीन से पांच कामकाजी दिन लगते हैं.

सवाल: आवेदन सबमिट करने के बाद, हम अपने Relying Party (RP) आवेदन की स्थिति कैसे ट्रैक कर सकते हैं?

जवाब: अगर आपको पांच दिनों तक कोई जवाब नहीं मिलता है, तो कृपया wallet-identity-rp-support@google.com पर हमारी सहायता टीम से संपर्क करें.

सवाल: हमें आरपी का ऑनबोर्डिंग फ़ॉर्म और डेवलपर का आधिकारिक दस्तावेज़ कहां मिलेगा?

जवाब:

सवाल: हम जो जानकारी देते हैं (जैसे कि प्रॉडक्ट का नाम और लोगो), उसका इस्तेमाल प्रॉडक्ट के अनुभव में कैसे किया जाएगा?

जवाब: उपयोगकर्ता को दिखने वाली सहमति स्क्रीन पर, प्रॉडक्ट का नाम और लोगो दिखाया जाता है. इससे उपयोगकर्ताओं को यह पता चलता है कि कौनसी Relying Party उनके डिजिटल आईडी का अनुरोध कर रही है. प्रॉडक्ट के अनुभव में यूआरएल और नीति के लिंक भी दिखाए जा सकते हैं.

सवाल: अगर हमें सिर्फ़ डेवलपमेंट और टेस्टिंग के लिए सैंडबॉक्स एनवायरमेंट का इस्तेमाल करना है, तो क्या हमें सेवा की शर्तों पर हस्ताक्षर करने होंगे?

जवाब: नहीं, टेस्टिंग के लिए सेवा की शर्तें स्वीकार करना ज़रूरी नहीं है.

सवाल: शुरू करने के लिए, हमें रेफ़रंस के तौर पर लागू किया गया कोड, सैंपल कोड या डेमो ऐप्लिकेशन कहां मिलेगा?

जवाब:

पुष्टि करने वाले रजिस्ट्रार

सवाल: पुष्टि करने वाला रजिस्ट्रार क्या है और यह कैसे काम करता है?

जवाब: पुष्टि करने वाला रजिस्ट्रार, सर्टिफ़िकेट देने वाली संस्था के तौर पर काम करता है. यह डाउनस्ट्रीम क्लाइंट (एंड आरपी) को शामिल करता है. एंड आरपी, Google Wallet के साथ सीधे तौर पर इंटरैक्ट नहीं करता है.

सवाल: पुष्टि करने वाले रजिस्ट्रार और उनके डाउनस्ट्रीम क्लाइंट के लिए, ऑनबोर्डिंग की खास प्रोसेस क्या है?

जवाब: इसके लिए, पुष्टि करने वाले रजिस्ट्रार की गाइड में दिए गए निर्देशों का पालन करें.

सवाल: यह डायरेक्ट आरपी इंटिग्रेशन से कैसे अलग है?

जवाब: पुष्टि करने वाले रजिस्ट्रार, अपने क्लाइंट के लिए भरोसेमंद संबंध मैनेज करते हैं. साथ ही, वे अपने क्लाइंट की ओर से Google Wallet के साथ इंटिग्रेशन को मैनेज करते हैं. वहीं, सीधे तौर पर आरपी, Google के साथ अपने कॉन्फ़िगरेशन को मैनेज करते हैं.

सवाल: वेरिफ़ायर रजिस्ट्रार के मामले में, Google के कॉन्फ़िगरेशन में किसे अनुमति वाली सूची में शामिल किया जाता है: वेरिफ़ायर रजिस्ट्रार, एंड आरपी या दोनों?

जवाब: Google, पुष्टि करने वाले रजिस्ट्रार के रूट सीए सर्टिफ़िकेट को अनुमति देता है. इसके बाद, पुष्टि करने वाला रजिस्ट्रार, डाउनस्ट्रीम के हर एंड आरपी के लिए नए लीफ़ सर्टिफ़िकेट जारी करता है.

सवाल: एंड आरपी, पुष्टि करने वाला रजिस्ट्रार, और Google Wallet के बीच डेटा कैसे ट्रांसफ़र होता है?

जवाब: पुष्टि करने वाला रजिस्ट्रार, एंड आरपी के लिए Google Wallet को एपीआई अनुरोध भेजता है. Google Wallet, क्रेडेंशियल के एन्क्रिप्ट (सुरक्षित) किए गए डेटा को Verifier Registrar को भेजता है. इसके बाद, Verifier Registrar इस डेटा को प्रोसेस करता है और End RP को फ़ाइनल सिग्नल भेजता है.

जवाब: नहीं. पुष्टि करने वाला रजिस्ट्रार, अपनी जानकारी न दिखाने का विकल्प चुन सकता है.

सवाल: रूट सीए और आरपी सर्टिफ़िकेट के लिए, अनुमति वाले मुख्य टाइप और कर्व कौनसे हैं?

जवाब: सर्टिफ़िकेट, P-256 / ECDSA का इस्तेमाल करके जनरेट किए जाने चाहिए.

Q: क्या हम अपने रूट सीए और आरपी के लीफ़ सर्टिफ़िकेट के बीच, इंटरमीडिएट हस्ताक्षर करने वाले सर्टिफ़िकेट का इस्तेमाल कर सकते हैं?

जवाब: हां. लंबे समय तक इस्तेमाल किए जा सकने वाले रूट सर्टिफ़िकेट को सुरक्षित तरीके से स्टोर किया जा सकता है.उदाहरण के लिए, एचएसएम में. इससे, ऑपरेशनल इंटरमीडिएट सर्टिफ़िकेट पर कभी-कभी हस्ताक्षर किए जा सकते हैं. इसके बाद, उन इंटरमीडिएट सर्टिफ़िकेट का इस्तेमाल, एंड-आरपी लीफ़ सर्टिफ़िकेट पर हस्ताक्षर करने के लिए किया जा सकता है. इससे उल्लंघन होने पर, रूट पर असर डाले बिना आसानी से रोटेशन किया जा सकता है.

सवाल: सर्टिफ़िकेट की मान्य अवधि कितनी होनी चाहिए?

जवाब: रूट CA सर्टिफ़िकेट के लिए, 10 साल की अवधि मान्य है. आम तौर पर, एंड-आरपी लीफ़ सर्टिफ़िकेट को एक साल के अंदर रिन्यू कर लेना चाहिए. इससे यह पक्का किया जा सकता है कि अगर कोई समस्या आती है, तो उन्हें आसानी से बदला जा सके.

सवाल: क्या हमें हर Relying Party (RP) ग्राहक के लिए, अलग-अलग लीफ़ सर्टिफ़िकेट मैनेज करने होंगे?

जवाब: हां. लॉन्च की शुरुआती अवधि के दौरान, एग्रीगेटर को हर डाउनस्ट्रीम आरपी के लिए अलग-अलग सर्टिफ़िकेट मैनेज करने होंगे. इससे हर आरपी के हिसाब से डिसप्ले कॉन्फ़िगरेशन और गलत इस्तेमाल की सटीक ट्रैकिंग की जा सकती है. हालांकि, इससे बड़े पैमाने पर ऑपरेशनल ओवरहेड बढ़ जाता है, लेकिन हम शुरुआती रोलआउट के बाद संभावित विकल्पों (जैसे कि आरपी मेटाडेटा हैश का इस्तेमाल करना) पर फिर से विचार करेंगे.

सवाल: क्या पार्टनर को एक साथ कई चालू सर्टिफ़िकेट रखने की अनुमति है?

जवाब: हां, कॉन्फ़िगरेशन में हर आरपी या एग्रीगेटर के लिए, चालू सर्टिफ़िकेट की संख्या तय नहीं की गई है. यह उन पार्टनर के लिए फ़ायदेमंद है जो अलग-अलग कारोबारी नामों से काम करते हैं.

सवाल: डिसटिंग्विश्ड नेम (सब्जेक्ट) को किस फ़ॉर्मैट में होना चाहिए?

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

सवाल: डोमेन बाइंडिंग कैसे काम करती है? क्या सर्टिफ़िकेट में ओरिजिन एम्बेड करना ज़रूरी है?

जवाब: डोमेन को सीधे तौर पर सर्टिफ़िकेट में एम्बेड करने की ज़रूरत नहीं होती. इसके बजाय, एपीआई कॉल में expected origins पैरामीटर का इस्तेमाल करके डोमेन की पुष्टि की जाती है. इसके अलावा, एक ही सर्टिफ़िकेट को कई डोमेन से आसानी से जोड़ा जा सकता है. बिना हस्ताक्षर वाले अनुरोधों के लिए, डोमेन या ऐप्लिकेशन पैकेज के नाम के साथ-साथ फ़िंगरप्रिंट का इस्तेमाल करके बाइंडिंग की जाती है.

सवाल: क्या वाइट लेबल वाले अनुभव के लिए, पुष्टि करने वाले यूज़र इंटरफ़ेस (यूआई) से एग्रीगेटर की जानकारी हटाई जा सकती है?

जवाब: हां, पुष्टि करने वाले व्यक्ति या कंपनी के मेटाडेटा में एग्रीगेटर की जानकारी (जैसे कि नाम, लोगो, यूआरएल, और निजता नीति) देना ज़रूरी नहीं है. इससे पूरी तरह से वाइट-लेबल वाला समाधान मिलता है. इसमें उपयोगकर्ता को सिर्फ़ असली आरपी की जानकारी दिखती है.

सवाल: हमें Sandbox एनवायरमेंट में टेस्टिंग शुरू करने के लिए क्या जानकारी देनी होगी?

जवाब: तकनीकी तौर पर, आपको सिर्फ़ अपना सैंडबॉक्स रूट सर्टिफ़िकेट देना होगा. सैंडबॉक्स को प्रोडक्शन एनवायरमेंट की तरह ही बनाया गया है.

सवाल: पुष्टि करने वाले रजिस्ट्रार (एग्रीगेटर) के लिए, सीधे तौर पर आरपी की तुलना में शामिल होने की प्रोसेस कैसे अलग होती है?

जवाब: एग्रीगेटर के लिए, प्रोसेस में थोड़ा बदलाव किया गया है. पुष्टि करने वाले रजिस्ट्रार के लिए सेवा की खास शर्तों को लागू करने के बाद, आवेदन को दो हिस्सों में बांटा जाता है: पहला, पुष्टि करने वाले रजिस्ट्रार के तौर पर आपकी स्थिति की पुष्टि करने के लिए मुख्य फ़ॉर्म. इसके बाद, हर उस व्यक्ति के लिए ज़रूरी फ़ॉर्म जिसे आपने आरपी के तौर पर शामिल किया है. आम तौर पर, हर आरपी सबमिशन के लिए इंटिग्रेशन की वीडियो रिकॉर्डिंग की ज़रूरत होती है. साथ ही, समीक्षा की प्रक्रिया में आम तौर पर दो से तीन कामकाजी दिन लगते हैं.

सवाल: क्या हम ऐसे ग्राहकों को शामिल कर सकते हैं जो मध्यस्थ के तौर पर काम करना चाहते हैं या सत्यापन की सेवाओं को अन्य इकाइयों को फिर से बेचना चाहते हैं?

जवाब: नहीं. Google का मौजूदा मॉडल और प्राथमिकता, नेस्ट किए गए रीसेलर या इंटरमीडियरी मॉडल के बजाय, सीधे तौर पर पुष्टि करने वाले रजिस्ट्रार (एग्रीगेटर) और उनके सीधे तौर पर काम करने वाले एंड-आरपी के साथ काम करना है.

टेक्निकल इंटिग्रेशन और एपीआई

सवाल: अनुरोधों के लिए बुनियादी प्रोटोकॉल क्या है? किन वर्शन पर यह सुविधा काम करती है?

जवाब: पुष्टि किए जा सकने वाले प्रज़ेंटेशन (OpenID4VP) के लिए मुख्य प्रोटोकॉल, OpenID वर्शन 1.0 है.

सवाल: Google, mDL प्रज़ेंटेशन के लिए ISO 18013-7 के किन अनुलग्नकों (जैसे, अनुलग्नक B, C, D) का इस्तेमाल करता है?

जवाब: Google, Annex D [currently in draft] (OpenID4VP using DC API) के साथ काम करता है.

सवाल: हम किसी उपयोगकर्ता के एक ही प्रज़ेंटेशन में, एक से ज़्यादा क्रेडेंशियल का अनुरोध करने के लिए, एपीआई अनुरोध को सही तरीके से कैसे स्ट्रक्चर करें?

जवाब: दोनों तरह के क्रेडेंशियल के लिए, एक ही JSON अनुरोध में dcql क्वेरी ऑब्जेक्ट के अंदर अनुरोध किया जाना चाहिए.

सवाल: क्या एपीआई, हर तरह के क्रेडेंशियल टाइप की सूची बनाए बिना, सामान्य क्रेडेंशियल का अनुरोध करने की अनुमति देता है?

जवाब: नहीं.

सवाल: एपीआई, उम्र की पुष्टि कैसे करता है? क्या हम जन्म की सटीक तारीख का अनुरोध कर सकते हैं या सिर्फ़ "X साल से ज़्यादा" सिग्नल का अनुरोध कर सकते हैं?

जवाब: हां, दोनों का इस्तेमाल किया जा सकता है. birth_date, age_in_years या निजता बनाए रखने से जुड़े "X से ज़्यादा" सिग्नल का अनुरोध किया जा सकता है. सही/गलत सिग्नल के लिए, ज़ीरो-नॉलेज प्रूफ़ (ज़ेडकेपी) का भी इस्तेमाल किया जा सकता है.

सवाल: हमारे पीकेआई इन्फ़्रास्ट्रक्चर के लिए क्या ज़रूरी शर्तें हैं?

जवाब: आरपी को अनुरोधों पर हस्ताक्षर करने के लिए पीकेआई की ज़रूरत होती है. पुष्टि करने वाले रजिस्ट्रार, अपने CA के तौर पर काम करते हैं.

स: क्या हम अपने मौजूदा सर्टिफ़िकेट का इस्तेमाल कर सकते हैं या हमें Google से साइन किया गया नया सर्टिफ़िकेट लेना होगा?

जवाब: आरपी को Google या Verifier Registrar से साइन किया गया नया सर्टिफ़िकेट चाहिए. पुष्टि करने वाले रजिस्ट्रार के लिए, Google आपके रूट सर्टिफ़िकेट पर भरोसा करेगा. इसके लिए, आपको दस्तावेज़ में दिए गए "भरोसा कायम करना" सेक्शन में बताए गए चरणों का पालन करना होगा.

जवाब: पूरा अनुरोध सर्वर-साइड पर जनरेट होना चाहिए. Android पर, Credman API का इस्तेमाल करें. वेब पर, Digital Credentials (DC) API का इस्तेमाल करें.

सवाल: डेवलपर के लिए, डीबग करने, लॉग करने, और निगरानी रखने के लिए कौनसे टूल उपलब्ध हैं?

जवाब: पार्टनर, wallet-identity-rp-support@google.com सहायता के लिए उपलब्ध ईमेल पते का इस्तेमाल कर सकते हैं. कोई खास लॉगिंग या ऑब्ज़र्वेबिलिटी टूल उपलब्ध नहीं कराए जाते.

क्रेडेंशियल और डेटा

सवाल: देश और इलाके के हिसाब से, कौनसे डिजिटल आईडी, जारी करने वाली संस्थाएं, और क्रेडेंशियल इस्तेमाल किए जा सकते हैं?

जवाब: जिन देशों/इलाकों में यह सुविधा उपलब्ध है उनकी जानकारी यहां देखें: सर्टिफ़िकेट जारी करने वाले बैंक/वित्तीय संस्थान और सर्टिफ़िकेट.

सवाल: नए देशों या इलाकों के क्रेडेंशियल इस्तेमाल करने की सुविधा कब उपलब्ध कराई जाएगी?

जवाब: हम लगातार नए देश/इलाके जोड़ रहे हैं. अपडेट के लिए, स्वीकार किए जाने वाले कार्ड जारी करने वालों का पेज देखें.

सवाल: जब क्रेडेंशियल जारी करने वाला व्यक्ति या कंपनी, क्रेडेंशियल को अपडेट करती है, तो क्या उपयोगकर्ता को इसकी सूचना मिलती है?

जवाब: हां, उपयोगकर्ता को सूचना दी जाती है और अपडेट अपने-आप लागू हो जाता है.

सवाल: Google अपने सर्वर पर क्रेडेंशियल का कौनसा डेटा सेव करता है? खास तौर पर, जीडीपीआर के संदर्भ में?

जवाब: Google, क्रेडेंशियल से जुड़ा डेटा अपने सर्वर पर सेव नहीं करता. यह डेटा, उपयोगकर्ता के डिवाइस पर स्थानीय तौर पर और सुरक्षित तरीके से सेव किया जाता है.

टेस्टिंग और एनवायरमेंट

सवाल: हम शुरू से आखिर तक के पूरे फ़्लो की जांच करने के लिए, सैंडबॉक्स एनवायरमेंट का ऐक्सेस कैसे पाएं?

जवाब: सैंडबॉक्स यहां खुला है: सैंडबॉक्स मोड.

सवाल: जिन पार्टनर के देश/इलाके में यह सुविधा आधिकारिक तौर पर लॉन्च नहीं हुई है उन्हें टेस्टिंग के लिए अनुमति वाली सूची में कैसे जोड़ा जाएगा?

जवाब: टेस्ट वॉलेट के Gmail आईडी, wallet-identity-rp-support@google.com को ईमेल करें.

सवाल: डेमो के लिए टेस्ट वेबसाइट या ऐप्लिकेशन को चालू करने की प्रोसेस क्या है, ताकि प्रोडक्शन क्रेडेंशियल वाला कोई भी व्यक्ति उसे दिखा सके?

जवाब: पार्टनर को स्टैंडर्ड आरपी ऑनबोर्डिंग की प्रोसेस पूरी करनी होगी. इसमें सैंडबॉक्स वीडियो का डेमो भी शामिल है.

उपयोगकर्ता अनुभव (यूएक्स)

सवाल: अगर किसी व्यक्ति के पास डिजिटल आईडी नहीं है या उसने Google Wallet ऐप्लिकेशन इंस्टॉल नहीं किया है, तो पुष्टि करने की प्रोसेस शुरू करने पर उसे कैसा अनुभव मिलेगा?

जवाब: जिन लोगों के पास ऐप्लिकेशन नहीं है उन्हें Play Store पर भेज दिया जाता है. जिनके पास आईडी नहीं है वे हाफ़-स्क्रीन यूज़र इंटरफ़ेस (यूआई) का इस्तेमाल करके, आईडी बना सकते हैं.

सवाल: क्या हम प्रोग्राम के ज़रिए यह पता लगा सकते हैं कि किसी व्यक्ति के Wallet में डिजिटल आईडी है या नहीं, ताकि उसे पुष्टि करने का विकल्प दिखाया जा सके?

जवाब: नहीं, निजता की सुरक्षा के लिए, एपीआई को उपयोगकर्ता के अनुरोध पर ही शुरू किया जाना चाहिए.

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

जवाब: उपयोगकर्ता की पुष्टि करने की सुविधा (बायोमेट्रिक, पिन या पैटर्न) डिफ़ॉल्ट रूप से चालू होती है और इसे बंद नहीं किया जा सकता.

जवाब: नहीं, Google Wallet उन्हें वर्णमाला के क्रम में फिर से लगाता है.

सुरक्षा और अनुपालन

सवाल: हमारे इस्तेमाल के उदाहरण में, उपयोगकर्ता के डेटा को तीसरे पक्षों के साथ फिर से शेयर करना शामिल है. क्या सेवा की शर्तों के तहत इसकी अनुमति है?

जवाब: हां, पाबंदियां लागू हो सकती हैं. ज़्यादा जानकारी के लिए, सेवा की शर्तें देखें.

सवाल: नियमों का पालन करने के मकसद से, डिजिटल पहचान से जुड़े समाधानों की सुरक्षा, भरोसेमंद होने, और सुलभता के बारे में कौनसे दस्तावेज़ उपलब्ध हैं?

जवाब: पार्टनर, Trail of Bits की सुरक्षा समीक्षाओं का हवाला दे सकते हैं.

ऐडवांस सुविधाएं और रोडमैप

सवाल: निजता की सुरक्षा के साथ उम्र की पुष्टि करने के लिए, ज़ीरो-नॉलेज प्रूफ़ (जेडकेपी) की क्या क्षमताएं हैं?

जवाब: ज़ीरो-नॉलेज प्रूफ़ (जेडकेपी) एक क्रिप्टोग्राफ़िक तरीका है. इसकी मदद से, कोई व्यक्ति (प्रूवर) पुष्टि करने वाले व्यक्ति को यह साबित कर सकता है कि उसके पास पहचान से जुड़ी कोई जानकारी है या वह किसी खास शर्त को पूरा करता है. जैसे, उसकी उम्र 18 साल से ज़्यादा है या उसके पास मान्य क्रेडेंशियल है. हालांकि, इसमें असल डेटा को ज़ाहिर नहीं किया जाता.

सवाल: ZK सर्किट के अलग-अलग वर्शन को कैसे मैनेज किया जाता है?

जवाब: आरपी को ZK वेरिफ़ायर सेवाओं को लागू करना होगा, ताकि वे उपलब्ध नए सर्किट का अनुरोध कर सकें.

सवाल: क्रेडेंशियल शेयर करने और मैनेज करने की सुविधा, फ़ोन और पहनने लायक डिवाइस जैसे कई डिवाइसों पर कैसे काम करती है?

जवाब: क्रेडेंशियल सिर्फ़ एक डिवाइस के लिए उपलब्ध कराए जाते हैं. इन्हें शेयर नहीं किया जा सकता.

अन्य

सवाल: अगर पासपोर्ट रद्द कर दिया जाता है, तो Google आईडी पास रद्द करने की प्रोसेस को कैसे मैनेज करता है?

जवाब: उपयोगकर्ता, Google खाते की सेटिंग में जाकर पास मिटा सकते हैं. क्रेडेंशियल रद्द करने के लिए, खोए हुए डिवाइसों की शिकायत की जा सकती है.

सवाल: mDL को रद्द करने की प्रोसेस कैसे पूरी की जाती है? क्या यह रीयलटाइम में अपडेट होता है?

जवाब: इसे उपयोगकर्ता ट्रिगर कर सकता है या इसे जारी करने वाली संस्था (डीएमवी) पुश कर सकती है. अगर डिवाइस ऑनलाइन है, तो यह रीयल-टाइम में काम करता है. अगर डिवाइस ऑनलाइन नहीं है, तो कम समय के लिए इस्तेमाल किए जाने वाले सुरक्षा ऑब्जेक्ट (एमएसओ) की समयसीमा खत्म हो जाएगी.

सवाल: आरपी के लिए, डेटा सुरक्षित करने वाली कुंजी का नया वर्शन अपने-आप बनाने की नीति क्या है?

जवाब: हमारा सुझाव है कि आप हर साल पासवर्ड बदलें.

सवाल: Digital Credentials API के लिए, कम से कम कौनसे Android वर्शन का इस्तेमाल किया जा सकता है?

जवाब: Android 9 (एपीआई लेवल 28) और इसके बाद के वर्शन.

सवाल: Digital Credentials API के साथ काम करने वाला Chrome का सबसे पुराना वर्शन कौन-सा है?

जवाब: Chrome 128 और उसके बाद के वर्शन.

सवाल: Digital Credentials API किन ब्राउज़र पर काम करता है?

जवाब: ब्राउज़र के साथ काम करने की जानकारी यहां दी गई है: https://digitalcredentials.dev/ecosystem-support

सवाल: जब कोई नया देश लॉन्च किया जाता है, तो कौनसे उपयोगकर्ता आईडी जोड़ने की सुविधा का इस्तेमाल कर पाएंगे?

जवाब: ऐक्सेस, Play Store में उपयोगकर्ता के देश की सेटिंग के आधार पर मिलता है.

सवाल: क्या Digital Credentials API, iOS के साथ काम करता है?

जवाब: हां, यह एपीआई Safari जैसे ब्राउज़र पर काम करता है. हालांकि, Apple पर OpenID4VP काम नहीं करता.