L'émission de l'API Digital Credentials est disponible dans Chrome 155

Natalia Markoborodova

Publié le 23 octobre 2026

Dans Chrome 155 et versions ultérieures, l'émission de l'API Digital Credentials est activée par défaut. Vous n'avez donc plus besoin d'un jeton d'essai Origin Trial ni d'un flag pour l'utiliser. L'API Digital Credentials est une couche de transport qui permet aux sites Web de se connecter aux applications de portefeuille installées sur l'appareil mobile de l'utilisateur. Grâce à l'émission, les émetteurs peuvent ajouter de nouveaux justificatifs (comme des pièces d'identité numériques) directement dans l'application de portefeuille d'un utilisateur.

Arrière-plan

L'écosystème d'identité numérique se compose de trois parties : les émetteurs, les vérificateurs (également appelés parties de confiance) et les titulaires (applications de portefeuille). Les utilisateurs ajoutent souvent une pièce d'identité numérique à leur application de portefeuille via le provisionnement push, où l'utilisateur lance l'émission depuis le site Web ou l'application de l'émetteur. Par exemple, un étudiant sur le site Web de son université (émetteur) peut enregistrer sa carte d'étudiant numérique dans son application de portefeuille préférée (titulaire).

Pour que ce modèle fonctionne, l'émetteur doit disposer d'un moyen sécurisé et fiable d'appeler l'application de portefeuille pour émettre la pièce d'identité. Avant cette API, chaque émetteur devait créer sa propre méthode pour ouvrir les applications de portefeuille avec lesquelles il était partenaire, généralement à l'aide de schémas d'URI personnalisés. Les émetteurs devaient gérer un mécanisme distinct pour chaque application de portefeuille, et les utilisateurs n'avaient pas de moyen cohérent de choisir une application de portefeuille.

Fonctionnement de l'émission d'identifiants numériques

Pour simplifier ce processus, Chrome est compatible avec l'émission à l'aide de l'API Digital Credentials du W3C. Cette fonctionnalité s'ajoute aux fonctionnalités de présentation (partage de données sélectives demandées à partir d'un identifiant numérique avec un vérificateur), qui ont été lancées dans Chrome 141. Lorsqu'un site Web émetteur appelle navigator.credentials.create() avec un membre digital contenant une demande d'émission, Chrome transmet la demande au système d'exploitation (sur Android, Credential Manager). Le système d'exploitation affiche ensuite sa propre interface, dans laquelle l'utilisateur choisit une application de portefeuille. L'API fonctionne avec des protocoles standards du secteur, tels que OpenID for Verifiable Credential Issuance (OpenID4VCI). L'émission accepte deux flux : un flux sur le même appareil sur Android et un flux multi-appareil qui commence sur un ordinateur et se termine sur un appareil Android.

Parcours sur le même appareil sur Android

Sur Android, Chrome transmet la demande d'émission au Gestionnaire d'identifiants Android, qui affiche la liste des applications de portefeuille compatibles sur l'appareil. L'utilisateur sélectionne un portefeuille et accepte d'ajouter l'identifiant. L'application de portefeuille récupère ensuite l'identifiant auprès de l'émetteur à l'aide du protocole d'émission, tel que OpenID4VCI.

Flux multi-appareil sur ordinateur

Sur ordinateur, Chrome affiche un QR code. L'utilisateur scanne le code avec son appareil Android et suit la procédure sur cet appareil, comme décrit dans la section précédente. Les appareils utilisent le Bluetooth pour confirmer qu'ils sont proches les uns des autres. Chrome demande donc à l'utilisateur d'activer le Bluetooth s'il est désactivé. Chrome utilise le même mécanisme multi-appareil pour la présentation de l'API Digital Credentials.

Implémenter l'émission à l'aide de l'API

Pour lancer le flux d'émission, appelez navigator.credentials.create() et transmettez vos demandes d'émission dans un membre digital. Effectuez cet appel à partir d'un gestionnaire de clics ou d'un autre gestionnaire de gestes de l'utilisateur, car l'appel nécessite une activation temporaire de l'utilisateur. L'exemple suivant utilise une offre d'identifiants OpenID4VCI avec le flux de code préautorisé :

// 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);
});

Dans cet exemple, showAlternativeIssuanceFlow() et showIssuanceStatus() représentent la logique de votre propre application.

Pour appeler create() à partir d'un iFrame interorigine, la page d'intégration doit autoriser la fonctionnalité de règle d'autorisation digital-credentials-create. Sinon, l'appel est rejeté avec un NotAllowedError :

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

Modifications depuis l'essai Origin Trial

Les méthodes et paramètres de l'API n'ont pas changé depuis l'essai Origin Trial. Toutefois, les modifications suivantes ont été apportées entre Chrome 143 et Chrome 155, et certaines d'entre elles peuvent nécessiter la mise à jour de votre code. Le tableau suivant récapitule les modifications, et les sections suivantes les expliquent.

Région Essai Origin Trial (Chrome 143) Chrome 155
Disponibilité Jeton d'essai Origin Trial ou option chrome://flags/#web-identity-digital-credentials-creation Activé par défaut
Activation de l'utilisateur Obligatoire, mais non consommé Obligatoire et consommé par chaque appel create() (Chrome 146)
Erreurs d'annulation NetworkError NotAllowedError (Chrome 148)
Identifiants de protocole Chrome transmet un identifiant au système d'exploitation. Les identifiants non reconnus déclenchent un avertissement d'abandon (Chrome 151)
Origines opaques Autorisé Bloqué avec NotAllowedError (Chrome 151)
Tests automatiques Pas de compatibilité intégrée Portefeuille virtuel dans le protocole Chrome DevTools (Chrome 152)

L'activation de l'utilisateur est consommée

À partir de Chrome 146, un appel create() avec un membre digital consomme l'activation temporaire de l'utilisateur, comme l'exige la spécification. Pendant l'essai Origin Trial, Chrome vérifiait l'activation de l'utilisateur, mais ne la consommait pas.

Par conséquent, chaque appel create() nécessite son propre geste de l'utilisateur, par exemple un clic sur un bouton. Sans activation de l'utilisateur, la promesse est rejetée avec une erreur NotAllowedError. Après l'appel, window.open() et les autres API nécessitant l'activation de l'utilisateur ne peuvent pas utiliser le même geste.

Rejets d'annulation avec NotAllowedError

À partir de Chrome 148, la promesse renvoyée par create() est rejetée avec une NotAllowedError lorsque l'utilisateur annule le flux, par exemple en fermant le sélecteur de portefeuille sur Android ou en fermant la boîte de dialogue du code QR sur ordinateur. La promesse est également rejetée avec un NotAllowedError lorsqu'aucune application de portefeuille ne peut traiter la requête. Pendant l'essai Origin Trial, ces cas ont été rejetés avec un NetworkError.

Si votre code recherche un NetworkError pour détecter une annulation, modifiez-le pour qu'il recherche un NotAllowedError à la place.

Les identifiants de protocole non reconnus déclenchent un avertissement

La spécification définit un seul identifiant de protocole d'émission, openid4vci-v1, pour OpenID4VCI 1.0. Chrome 155 reconnaît openid4vci-v1, ainsi que openid4vci. Étant donné que openid4vci ne fait pas partie de la spécification, nous vous recommandons d'utiliser openid4vci-v1.

Chrome transmet à la plate-forme les requêtes contenant n'importe quel identifiant de protocole. Toutefois, à partir de Chrome 151, les outils de développement affichent un avertissement d'abandon lorsqu'une page appelle create() avec un identifiant de protocole non reconnu. Chrome prévoit de bloquer les requêtes comportant des identifiants de protocole non reconnus. Pour connaître l'état, consultez l'entrée Filtrage de protocole plus spécifique dans l'API Digital Credential.

Pour tester ce comportement, activez chrome://flags/#enable-experimental-web-platform-features. Lorsque cette option est activée, create() ignore les requêtes comportant des identifiants de protocole non reconnus et les rejette avec un code TypeError s'il ne reste aucune requête. De plus, DigitalCredential.userAgentAllowsProtocol() ne renvoie true que pour les protocoles reconnus. Sans l'option, il vérifie uniquement que l'identifiant est bien formé. Par conséquent, ne vous fiez pas uniquement à userAgentAllowsProtocol() pour la détection des fonctionnalités. Gérez NotSupportedError comme indiqué dans l'exemple.

Les origines opaques sont bloquées

À partir de Chrome 151, create() rejette avec un NotAllowedError lorsqu'un document avec une origine opaque l'appelle, comme un iframe en bac à sable sans le jeton allow-same-origin. Pendant l'essai Origin Trial, Chrome n'a pas bloqué ces appels.

Tester avec un portefeuille virtuel

À partir de Chrome 152, vous pouvez tester votre flux d'émission sans appareil Android ni application de portefeuille. La commande expérimentale DigitalCredentials.setVirtualWalletBehavior du protocole Chrome DevTools (CDP) implémente le portefeuille virtuel défini par la spécification pour les tests automatisés. Le portefeuille virtuel peut répondre avec les données que vous fournissez, refuser les requêtes comme si l'utilisateur avait annulé le flux, ou laisser les requêtes en attente pour tester les délais avant expiration et les abandons.

Le test Puppeteer suivant configure le portefeuille virtuel pour qu'il réponde aux requêtes openid4vci-v1, puis clique sur le bouton qui lance l'émission :

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');

Adoption par l'industrie

Nous constatons l'adoption de l'API Digital Credentials pour l'émission de justificatifs. Par exemple, l'institution financière allemande Sparkasse utilise l'API Digital Credentials pour permettre aux titulaires de compte d'enregistrer des justificatifs d'âge validés dans Google Wallet. Les titulaires du compte peuvent ensuite utiliser ces identifiants pour valider leur âge en ligne et en personne.

Essayer

Avant de tester l'émission de l'API Digital Credentials, assurez-vous de disposer des éléments suivants :

  • Mettez à jour Chrome vers la version 155 ou ultérieure.
  • Installez une application de portefeuille compatible sur votre appareil Android, par exemple la version de démonstration de CMWallet.
  • Le Bluetooth doit être activé sur les deux appareils (flux inter-appareils uniquement).

Pour tester le flux inter-appareils :

  1. Sur votre ordinateur, ouvrez le site de démonstration de l'émetteur.
  2. Cliquez sur le bouton Ajouter.
  3. Scannez le QR code avec votre appareil Android et suivez les instructions à l'écran.

Pour tester le flux sur le même appareil, ouvrez le site de l'émetteur de démonstration dans Chrome sur votre appareil Android.

Ressources pour les développeurs

Pour commencer à intégrer l'émission de l'API Digital Credentials à votre site Web, utilisez les ressources suivantes :

Envoyer des commentaires

Pour signaler un bug ou demander une fonctionnalité, signalez un problème dans l'outil de suivi des bugs Chromium.