Digital Credentials API से क्रेडेंशियल जारी करने की सुविधा, Chrome 155 में उपलब्ध है

पब्लिश होने की तारीख: 23 अक्टूबर, 2026

Chrome 155 और इसके बाद के वर्शन में, Digital Credentials API से क्रेडेंशियल जारी करने की सुविधा डिफ़ॉल्ट रूप से चालू होती है. इसलिए, अब इसका इस्तेमाल करने के लिए, आपको ऑरिजिन ट्रायल टोकन या फ़्लैग की ज़रूरत नहीं है. Digital Credentials API एक ट्रांसपोर्ट लेयर है. इसकी मदद से, वेबसाइटें उपयोगकर्ता के मोबाइल डिवाइस पर इंस्टॉल किए गए वॉलेट ऐप्लिकेशन से कनेक्ट हो पाती हैं. इस सुविधा की मदद से, कार्ड जारी करने वाली कंपनियां, उपयोगकर्ता के Wallet ऐप्लिकेशन में सीधे तौर पर नए क्रेडेंशियल जोड़ सकती हैं. जैसे, डिजिटल आईडी.

बैकग्राउंड

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

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

डिजिटल क्रेडेंशियल जारी करने की सुविधा कैसे काम करती है

इस प्रोसेस को आसान बनाने के लिए, Chrome में W3C Digital Credentials API की मदद से क्रेडेंशियल जारी करने की सुविधा उपलब्ध है. यह प्रज़ेंटेशन की सुविधाओं को बेहतर बनाता है. जैसे, डिजिटल क्रेडेंशियल से चुनिंदा डेटा को पुष्टि करने वाले व्यक्ति के साथ शेयर करना. यह सुविधा Chrome 141 में लॉन्च की गई थी. जब जारी करने वाली कंपनी की वेबसाइट, navigator.credentials.create() को कॉल करती है और उसमें digital मेंबर शामिल होता है, जिसमें पास जारी करने का अनुरोध होता है, तो Chrome उस अनुरोध को ऑपरेटिंग सिस्टम (Android पर, Credential Manager) को भेजता है. इसके बाद, ऑपरेटिंग सिस्टम अपना इंटरफ़ेस दिखाता है, जहां उपयोगकर्ता कोई वॉलेट ऐप्लिकेशन चुनता है. यह एपीआई, इंडस्ट्री स्टैंडर्ड प्रोटोकॉल के साथ काम करता है. जैसे, OpenID for Verifiable Credential Issuance (OpenID4VCI). पासकी जारी करने के लिए, दो फ़्लो इस्तेमाल किए जा सकते हैं: Android पर एक ही डिवाइस वाला फ़्लो और क्रॉस-डिवाइस फ़्लो. क्रॉस-डिवाइस फ़्लो, डेस्कटॉप पर शुरू होता है और Android डिवाइस पर खत्म होता है.

Android पर एक ही डिवाइस से साइन इन करने का तरीका

Android पर, Chrome डिजिटल आईडी जारी करने का अनुरोध, Android Credential Manager को भेजता है. इसके बाद, Credential Manager डिवाइस पर मौजूद, वॉलेट के साथ काम करने वाले ऐप्लिकेशन की सूची दिखाता है. उपयोगकर्ता कोई वॉलेट चुनता है और क्रेडेंशियल जोड़ने की सहमति देता है. इसके बाद, वॉलेट ऐप्लिकेशन को क्रेडेंशियल जारी करने वाले प्रोटोकॉल का इस्तेमाल करके, क्रेडेंशियल जारी करने वाली इकाई से क्रेडेंशियल मिलता है. जैसे, OpenID4VCI.

डेस्कटॉप पर क्रॉस-डिवाइस फ़्लो

डेस्कटॉप पर, Chrome एक क्यूआर कोड दिखाता है. उपयोगकर्ता अपने Android डिवाइस से कोड को स्कैन करता है और उस डिवाइस पर फ़्लो को पूरा करता है. इसके बारे में पिछले सेक्शन में बताया गया है. डिवाइस, ब्लूटूथ का इस्तेमाल करके यह पुष्टि करते हैं कि वे एक-दूसरे के आस-पास हैं. इसलिए, अगर ब्लूटूथ बंद है, तो Chrome उपयोगकर्ता से उसे चालू करने के लिए कहता है. Chrome, Digital Credentials API प्रज़ेंटेशन के लिए, एक से दूसरे डिवाइस पर काम करने वाले इसी तरीके का इस्तेमाल करता है.

एपीआई का इस्तेमाल करके, पास जारी करने की सुविधा लागू करना

कार्ड जारी करने की प्रोसेस शुरू करने के लिए, navigator.credentials.create() को कॉल करें और digital मेंबर में कार्ड जारी करने के अनुरोध पास करें. इस कॉल को क्लिक हैंडलर या किसी अन्य उपयोगकर्ता के जेस्चर हैंडलर से करें. ऐसा इसलिए, क्योंकि कॉल के लिए उपयोगकर्ता को कुछ समय के लिए चालू करना ज़रूरी है. यहां दिए गए उदाहरण में, पहले से अनुमति वाले कोड फ़्लो के साथ OpenID4VCI क्रेडेंशियल ऑफ़र का इस्तेमाल किया गया है:

// Call this function from a user gesture handler, for example, a button's
// click handler. The pre-authorized code is a short-lived, single-use code
// that your server generates for the signed-in user.
async function issueDigitalCredential(preAuthorizedCode) {
  // Check for Digital Credentials API and protocol support.
  if (!window.DigitalCredential ||
      !DigitalCredential.userAgentAllowsProtocol('openid4vci-v1')) {
    // Provide an alternative issuance method.
    showAlternativeIssuanceFlow();
    return;
  }

  // Construct a credential offer according to the OpenID4VCI
  // specification. This example uses the format that the
  // demo CMWallet supports.
  const credentialOffer = {
    credential_issuer: 'https://issuer.example',
    credential_configuration_ids: ['org.iso.18013.5.1.mDL'],
    grants: {
      'urn:ietf:params:oauth:grant-type:pre-authorized_code': {
        'pre-authorized_code': preAuthorizedCode
      }
    },
    // Metadata that the wallet uses to request and display the credential.
    credential_issuer_metadata: {
      credential_issuer: 'https://issuer.example',
      credential_endpoint: 'https://issuer.example/openid4vci/credential',
      nonce_endpoint: 'https://issuer.example/openid4vci/nonce',
      credential_configurations_supported: {
        'org.iso.18013.5.1.mDL': {
          format: 'mso_mdoc',
          doctype: 'org.iso.18013.5.1.mDL',
          // Bind the credential to a key that the wallet generates.
          cryptographic_binding_methods_supported: ['cose_key'],
          proof_types_supported: {
            jwt: { proof_signing_alg_values_supported: ['ES256'] }
          },
          credential_metadata: {
            display: [{ name: 'Mobile driving license', locale: 'en-US' }],
            // The claims that this credential contains. For a full list of
            // standard mDL claims, see the ISO/IEC 18013-5 specification.
            claims: [{
              path: ['org.iso.18013.5.1', 'family_name'],
              display: [{ name: 'Family name', locale: 'en-US' }]
            }
            // ... Add any other claims for your credential here.
            ]
          }
        }
      }
    },
    // Metadata of the authorization server that issues access tokens.
    authorization_server_metadata: {
      issuer: 'https://issuer.example',
      token_endpoint: 'https://issuer.example/openid4vci/token'
    }
  };

  try {
    const credential = await navigator.credentials.create({
      digital: {
        requests: [{
          // The protocol identifier for OpenID4VCI 1.0.
          protocol: 'openid4vci-v1',
          // Pass the offer as an object, not as a JSON string.
          data: credentialOffer
        }]
      }
    });

    // The wallet handled the request. credential.data is an object that
    // contains the wallet's protocol-specific response. It is not the issued
    // credential, and it does not necessarily mean that issuance is complete.
    // Your server knows when the wallet retrieves the credential from your
    // credential endpoint.
    // Implement your custom logic here as needed.
    showIssuanceStatus(credential);
  } catch (error) {
    switch (error.name) {
      case 'NotAllowedError':
        // The user canceled the flow, no wallet can handle the request, or
        // the call does not have transient user activation.
        break;
      case 'NotSupportedError':
        // The browser does not support Digital Credentials API issuance.
        // Fall back to your custom alternative flow logic.
        showAlternativeIssuanceFlow();
        break;
      case 'TypeError':
        // The request is malformed, for example, data is not an object.
        console.error('Invalid issuance request:', error);
        break;
      default:
        // For example, AbortError or NetworkError.
        console.error('Credential issuance failed:', error);
    }
  }
}

const addButton = document.querySelector('#add-to-wallet');
addButton.addEventListener('click', () => {
  // Your server adds a pre-authorized code for the signed-in user
  // to the button's data-pre-authorized-code attribute.
  issueDigitalCredential(addButton.dataset.preAuthorizedCode);
});

इस उदाहरण में, showAlternativeIssuanceFlow() और showIssuanceStatus() आपके ऐप्लिकेशन के लॉजिक को दिखाते हैं.

क्रॉस-ऑरिजिन iframe से create() को कॉल करने के लिए, एम्बेड किए गए पेज को digital-credentials-create अनुमतियों की नीति की सुविधा को अनुमति देनी होगी. ऐसा न होने पर, कॉल को NotAllowedError के साथ अस्वीकार कर दिया जाता है:

<iframe src="https://issuer.example" allow="digital-credentials-create">
</iframe>

ऑरिजिन ट्रायल के बाद हुए बदलाव

ऑरिजिन ट्रायल के बाद से, एपीआई के तरीकों और पैरामीटर में कोई बदलाव नहीं हुआ है. हालांकि, Chrome 143 और Chrome 155 के बीच ये बदलाव किए गए हैं. इनमें से कुछ बदलावों के लिए, आपको अपना कोड अपडेट करना पड़ सकता है. नीचे दी गई टेबल में, इन बदलावों की खास जानकारी दी गई है. इसके बाद के सेक्शन में, हर बदलाव के बारे में बताया गया है.

क्षेत्र ऑरिजिन ट्रायल (Chrome 143) Chrome 155
उपलब्धता ऑरिजिन ट्रायल टोकन या chrome://flags/#web-identity-digital-credentials-creation फ़्लैग डिफ़ॉल्ट रूप से चालू है
उपयोगकर्ता की ओर से की गई कार्रवाई ज़रूरी है, लेकिन इस्तेमाल नहीं किया गया हर create() कॉल के लिए ज़रूरी और इस्तेमाल किया गया (Chrome 146)
रद्द करने से जुड़ी गड़बड़ियां NetworkError NotAllowedError (Chrome 148)
प्रोटोकॉल आइडेंटिफ़ायर Chrome, ऑपरेटिंग सिस्टम को कोई आइडेंटिफ़ायर पास करता है पहचान न किए जा सकने वाले आइडेंटिफ़ायर, बंद होने की चेतावनी ट्रिगर करते हैं (Chrome 151)
ओपेक ऑरिजिन अनुमति है NotAllowedError (Chrome 151) की मदद से ब्लॉक किया गया
ऑटोमेटेड टेस्टिंग पहले से मौजूद सहायता उपलब्ध नहीं है Chrome DevTools Protocol में वर्चुअल वॉलेट (Chrome 152)

यूज़र ऐक्टिवेशन का इस्तेमाल किया गया है

Chrome 146 से, digital सदस्य के साथ create() कॉल करने पर, कुछ समय के लिए उपयोगकर्ता की गतिविधि का इस्तेमाल होता है. ऐसा स्पेसिफ़िकेशन के मुताबिक ज़रूरी है. ऑरिजिन ट्रायल के दौरान, Chrome ने उपयोगकर्ता की गतिविधि की जांच की, लेकिन उसे इस्तेमाल नहीं किया.

इसलिए, हर create() कॉल के लिए उपयोगकर्ता के जेस्चर की ज़रूरत होती है. उदाहरण के लिए, बटन पर क्लिक करना. उपयोगकर्ता की गतिविधि के बिना, प्रॉमिस को NotAllowedError के साथ अस्वीकार कर दिया जाता है. कॉल के बाद, window.open() और अन्य एपीआई के लिए, उपयोगकर्ता की ओर से की गई कार्रवाई की ज़रूरत होती है. इसलिए, वे उसी जेस्चर का इस्तेमाल नहीं कर सकते.

NotAllowedError के साथ रद्द करने के अनुरोध अस्वीकार किए गए

Chrome 148 से, create() से मिलने वाला प्रॉमिस, NotAllowedError के साथ अस्वीकार हो जाता है. ऐसा तब होता है, जब उपयोगकर्ता फ़्लो को रद्द कर देता है. उदाहरण के लिए, Android पर वॉलेट सिलेक्टर को खारिज करके या डेस्कटॉप पर क्यूआर कोड डायलॉग को बंद करके. जब कोई वॉलेट ऐप्लिकेशन अनुरोध को हैंडल नहीं कर पाता, तब भी प्रॉमिस NotAllowedError के साथ अस्वीकार हो जाता है. ऑरिजिन ट्रायल के दौरान, इन मामलों को NetworkError के साथ अस्वीकार कर दिया गया था.

अगर आपका कोड, सदस्यता रद्द होने का पता लगाने के लिए NetworkError की जांच करता है, तो इसे अपडेट करें, ताकि यह NotAllowedError की जांच करे.

प्रोटोकॉल के ऐसे आइडेंटिफ़ायर जिनकी पहचान नहीं हो पाती है वे चेतावनी ट्रिगर करते हैं

इस स्पेसिफ़िकेशन में, OpenID4VCI 1.0 के लिए एक ही जारी करने वाले प्रोटोकॉल आइडेंटिफ़ायर, openid4vci-v1 को तय किया गया है. Chrome 155, openid4vci-v1 और openid4vci को पहचानता है. openid4vci, खास जानकारी का हिस्सा नहीं है. इसलिए, हमारा सुझाव है कि आप openid4vci-v1 का इस्तेमाल करें.

Chrome, किसी भी प्रोटोकॉल आइडेंटिफ़ायर वाले अनुरोधों को प्लैटफ़ॉर्म पर भेजता है. हालांकि, Chrome के वर्शन 151 से, DevTools में बंद होने की चेतावनी दिखती है. ऐसा तब होता है, जब कोई पेज किसी ऐसे प्रोटोकॉल आइडेंटिफ़ायर के साथ create() को कॉल करता है जिसकी पहचान नहीं की जा सकी. Chrome, ऐसे अनुरोधों को ब्लॉक करना चाहता है जिनमें प्रोटोकॉल आइडेंटिफ़ायर की पहचान नहीं हो पाती. स्टेटस देखने के लिए, Digital Credential API में ज़्यादा सटीक तरीके से प्रोटोकॉल को फ़िल्टर करने की सुविधा पर जाएं.

इस सुविधा को आज़माने के लिए, chrome://flags/#enable-experimental-web-platform-features को चालू करें. इस फ़्लैग के चालू होने पर, create() उन अनुरोधों को अनदेखा कर देता है जिनमें प्रोटोकॉल आइडेंटिफ़ायर की पहचान नहीं की जा सकती. साथ ही, अगर कोई अनुरोध नहीं बचता है, तो वह TypeError के साथ अनुरोधों को अस्वीकार कर देता है. साथ ही, DigitalCredential.userAgentAllowsProtocol() सिर्फ़ पहचाने गए प्रोटोकॉल के लिए true दिखाता है. फ़्लैग के बिना, यह सिर्फ़ यह जांच करता है कि आइडेंटिफ़ायर सही तरीके से बना है या नहीं. इसलिए, सुविधा का पता लगाने के लिए सिर्फ़ userAgentAllowsProtocol() पर भरोसा न करें. NotSupportedError को हैंडल करें, जैसा कि उदाहरण में दिखाया गया है.

ओपेक ऑरिजिन ब्लॉक किए गए हैं

Chrome के वर्शन 151 से, create() को NotAllowedError के साथ अस्वीकार कर दिया जाएगा. ऐसा तब होगा, जब ओपेक ऑरिजिन वाला कोई दस्तावेज़ इसे कॉल करेगा. जैसे, allow-same-origin टोकन के बिना सैंडबॉक्स किया गया iframe. ऑरिजिन ट्रायल के दौरान, Chrome ने इन कॉल को ब्लॉक नहीं किया.

वर्चुअल वॉलेट से टेस्ट करना

Chrome 152 से, Android डिवाइस या वॉलेट ऐप्लिकेशन के बिना भी, क्रेडेंशियल जारी करने की प्रोसेस को टेस्ट किया जा सकता है. Chrome DevTools Protocol (CDP) में मौजूद, एक्सपेरिमेंट के तौर पर उपलब्ध DigitalCredentials.setVirtualWalletBehavior कमांड, वर्चुअल वॉलेट को लागू करता है. इसे ऑटोमेटेड टेस्टिंग के लिए तय की गई खास शर्तों के मुताबिक बनाया गया है. वर्चुअल वॉलेट, आपके दिए गए डेटा के साथ जवाब दे सकता है. साथ ही, अनुरोधों को अस्वीकार कर सकता है, जैसे कि उपयोगकर्ता ने फ़्लो को रद्द कर दिया हो. इसके अलावा, टाइम आउट और रद्द करने की प्रोसेस की जांच करने के लिए, अनुरोधों को 'मंज़ूरी बाकी है' के तौर पर छोड़ सकता है.

यहां दिए गए Puppeteer टेस्ट में, वर्चुअल वॉलेट को openid4vci-v1 अनुरोधों का जवाब देने के लिए सेट किया गया है. इसके बाद, पास जारी करने की प्रोसेस शुरू करने वाले बटन पर क्लिक किया गया है:

const client = await page.createCDPSession();
await client.send('DigitalCredentials.setVirtualWalletBehavior', {
  action: 'respond',
  protocol: 'openid4vci-v1',
  response: {}
});

// Clicking the button provides the user activation that create() requires.
await page.click('#add-to-wallet');

इंडस्ट्री में इसका इस्तेमाल

हम देख रहे हैं कि Digital Credentials API का इस्तेमाल करके क्रेडेंशियल जारी करने की सुविधा को अपनाया जा रहा है. उदाहरण के लिए, जर्मनी का वित्तीय संस्थान Sparkasse, Digital Credentials API का इस्तेमाल करता है, ताकि खाता मालिक, उम्र की पुष्टि करने वाले क्रेडेंशियल को Google Wallet में सेव कर सकें. इसके बाद, खाता मालिक इन क्रेडेंशियल का इस्तेमाल करके, ऑनलाइन और व्यक्तिगत तौर पर अपनी उम्र की पुष्टि कर सकते हैं.

इसे आज़माएं

Digital Credentials API से क्रेडेंशियल जारी करने की सुविधा को टेस्ट करने से पहले, पक्का करें कि आपके पास ये चीज़ें हों:

  • Chrome को 155 या इसके बाद के वर्शन पर अपडेट करें.
  • अपने Android डिवाइस पर, वॉलेट की सुविधा देने वाला कोई ऐप्लिकेशन इंस्टॉल करें. उदाहरण के लिए, demo CMWallet.
  • दोनों डिवाइसों पर ब्लूटूथ चालू हो (सिर्फ़ क्रॉस-डिवाइस फ़्लो के लिए).

क्रॉस-डिवाइस फ़्लो की जांच करने के लिए:

  1. अपने कंप्यूटर पर, डेमो जारी करने वाली साइट खोलें.
  2. जोड़ें बटन पर क्लिक करें.
  3. अपने Android डिवाइस से क्यूआर कोड स्कैन करें और स्क्रीन पर दिए गए निर्देशों का पालन करें.

एक ही डिवाइस पर फ़्लो को टेस्ट करने के लिए, अपने Android डिवाइस पर Chrome में, कार्ड जारी करने वाले बैंक या कंपनी की डेमो साइट खोलें.

डेवलपर के लिए संसाधन

अपनी वेबसाइट पर Digital Credentials API को इंटिग्रेट करने के लिए, इन संसाधनों का इस्तेमाल करें:

सुझाव/राय दें या शिकायत करें

किसी गड़बड़ी की शिकायत करने या किसी सुविधा का अनुरोध करने के लिए, Chromium बग ट्रैकर में समस्या दर्ज करें.