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

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

जवाब: Choose Your Path पर जाकर, सिलसिलेवार निर्देशों का पालन करें.

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

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

सवाल: सबमिट करने के बाद, हम अपने रिलाइंग पार्टी (आरपी) ऐप्लिकेशन की स्थिति को कैसे ट्रैक कर सकते हैं?

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

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

जवाब:

• Onboarding Form: Google Wallet Identity Relying Partners Contact Form
• डेवलपर का दस्तावेज़: डिजिटल आइडेंटिटी के बारे में खास जानकारी

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

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

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

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

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

जवाब:

• GitHub रिपॉज़िटरी: Identity Reference Implementation.
• जांच करने के लिए वेबसाइट: verifier.multipaz.org

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Q: Can aggregator details be omitted from the verification UI for a white-labeled experience?

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

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

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

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

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

सवाल: क्या हम उन ग्राहकों को शामिल कर सकते हैं जो बिचौलिए के तौर पर काम करना चाहते हैं या पुष्टि करने की सेवाओं को अन्य इकाइयों को फिर से बेचना चाहते हैं?

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

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

जवाब: मुख्य प्रोटोकॉल, OpenID for Verifiable Presentations (OpenID4VP) का वर्शन 1.0 है.

सवाल: Google, mDL प्रज़ेंटेशन के लिए ISO 18013-7 के किन एनेक्स (जैसे, एनेक्स बी, सी, डी) के साथ काम करता है?

जवाब: Google, Annex D [फ़िलहाल ड्राफ़्ट में है] (डीसी एपीआई का इस्तेमाल करके OpenID4VP) के साथ काम करता है.

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

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

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

जवाब: नहीं.

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

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

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

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

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

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

सवाल: वेब और Android ऐप्लिकेशन के लिए, इंटिग्रेशन की सुझाई गई रणनीति क्या है?

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

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

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

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

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

सवाल: नए देशों या इलाकों के क्रेडेंशियल कब से स्वीकार किए जाएंगे?

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

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

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

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

जवाब: सैंडबॉक्स मोड यहां उपलब्ध है: सैंडबॉक्स मोड.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

सवाल: ज़ीरो नॉलेज सर्किट के अलग-अलग वर्शन कैसे मैनेज किए जाते हैं?

जवाब: आरपी को उपलब्ध नए सर्किट का अनुरोध करने के लिए, ज़ीरो नॉलेज (ZK) की मदद से पुष्टि करने वाली सेवाएं लागू करनी होंगी.

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

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

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

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

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

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

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

जवाब: हमारा सुझाव है कि हर साल रोटेशन करें.

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

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

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

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

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

जवाब: ब्राउज़र से जुड़ी सहायता की जानकारी यहां देखी जा सकती है: https://digitalcredentials.dev/ecosystem-support

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

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

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

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