--- url: 'https://www.corbado.com/fr/blog/digital-credentials-api' title: 'API Digital Credentials (2026) : Prise en charge par Chrome et Safari' description: 'Découvrez l''API Digital Credentials, sa prise en charge actuelle dans Chrome et Safari, et restez à jour sur les prochaines évolutions grâce à notre guide complet.' lang: 'fr' author: 'Vincent Delitz' date: '2025-07-25T07:00:37.370Z' lastModified: '2026-08-29T06:03:52.684Z' keywords: 'api digital credentials, api dc, identifiants numériques, identité numérique, mdoc, openid4vp, portefeuille numérique' category: 'Engineering' --- # API Digital Credentials (2026) : Prise en charge par Chrome et Safari ### API Digital Credentials : Aperçu de la prise en charge (Mars 2026) _Dernière mise à jour : 26 mars 2026_ Voici un aperçu rapide de la prise en charge de l'API [Digital Credentials](https://www.corbado.com/blog/digital-credentials-api) (identifiants numériques) dans les principaux navigateurs : | Navigateur | Statut de prise en charge (Mars 2026) | Version stable / Perspectives | | :-------------- | :-------------------------------------------------------------------------------------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Google Chrome | ✅ **Déployé (Stable)** — agnostique vis-à-vis du protocole (OpenID4VP **et** ISO 18013-7 Annexe C) | **Chrome 141** ([Stable depuis le **30 sept. 2025**](https://developer.chrome.com/blog/digital-credentials-api-shipped)); support cross-device sur desktop via CTAP/BLE. [Voir §6.1](#61-google-chrome-deploye-dans-la-v141-agnostique-aux-protocoles) | | Apple Safari | ✅ **Déployé (Stable)** — **mdoc uniquement** via `org-iso-mdoc` | **Safari 26** ([sorti le **15 sept. 2025**](https://webkit.org/blog/17431/online-identity-verification-with-the-digital-credentials-api/)); prend en charge Wallet et les fournisseurs de documents enregistrés. [Voir §6.2](#62-apple-safari-expedie-dans-la-v26-focus-mdoc-uniquement) | | Mozilla Firefox | 🔧 **En développement** — base intégrée dans Firefox 149 | La [position officielle défavorable](https://github.com/mozilla/standards-positions/issues/1003) reste inchangée, mais une [implémentation active est en cours](https://bugzilla.mozilla.org/show_bug.cgi?id=2004828). [Voir §6.3](#63-mozilla-firefox-d-une-position-negative-a-une-implementation-active) | | Microsoft Edge | ✅ **Déployé (Stable)** — basé sur Chromium, suit Chrome 141 | **Edge 141** (Stable début oct. 2025); hérite des capacités de Chromium 141. | ## Chronologie : Où en sont les identifiants numériques ? Le monde des [identifiants numériques](https://www.corbado.com/fr/blog/identifiants-numeriques-passkeys) évolue rapidement. Voici un résumé des développements clés et des projections : | **Icône** | **Date / Période** | **Événement** | **Description & Source** | | :-------- | :----------------- | :----------------------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 🚀🤖 | 20 août 2024 | Origin Trial Android | [Chrome 128 lance un Origin Trial pour l'API Digital Credentials sur Android](https://developer.chrome.com/release-notes/128), permettant les requêtes via le système IdentityCredential CredMan d'Android. | | 🚀🍏 | 27 fév. 2025 | Safari Technology Preview 214 | WebKit (inclus dans [Safari Technology Preview 214](https://www.webkit.org/blog/16512/release-notes-for-safari-technology-preview-214/)) ajoute un Feature Flag pour l'API. ([Pull Request](https://github.com/WebKit/WebKit/pull/40008)) | | 🚀🤖 | 4 mars 2025 | Origin Trial Chrome 134 Desktop | [Chrome 134 lance un Origin Trial sur Desktop](https://developer.chrome.com/origintrials/#/view_trial/3981410680008146945), permettant une communication sécurisée avec les portefeuilles Android. | | 🚀🍏 | 31 mars 2025 | Sortie de Safari 18.4 | [Safari 18.4](https://webkit.org/blog/16574/webkit-features-in-safari-18-4/) rend certaines parties de l'API testables via un Feature Flag. | | 💡 | Avril 2025 | Le W3C FedID WG prend les commandes | Le développement de l'API passe officiellement au [groupe de travail W3C Federated Identity](https://github.com/w3c-fedid/digital-credentials). | | 🚀🤖 | 30 avril 2025 | Annonce OT Cross-Device Chrome | Chrome annonce un [Origin Trial pour l'API Digital Credentials Cross-Device](https://developer.chrome.com/blog/digital-credentials-cross-device-ot) débutant avec Chrome 136. | | ⚠️🤖 | 2 mai 2025 | Changements majeurs API Chrome | Chrome décrit des changements cassants pour les versions 136 & 138 (ex: formats de requête, ajout de `navigator.credentials.create()` sous flag). | | 🚀🍏 | 10 juin 2025 | WWDC25 : Apple confirme le support | Apple annonce officiellement le support dans Safari lors de la WWDC25, confirmant le focus sur le protocole `org.iso.mdoc`. (Source : [Verify identity documents on the web](https://developer.apple.com/videos/play/wwdc2025/232/)) | | 🧭 | 15 sept. 2025 | Sortie de Safari 26 | [Safari/iOS 26 déploie l'API Digital Credentials](https://webkit.org/blog/17431/online-identity-verification-with-the-digital-credentials-api/) avec **`org-iso-mdoc`** (mdoc Annexe C). | | 🚀🤖 | 30 sept. 2025 | Chrome 141 Stable | [L'API Digital Credentials passe en **stable** dans Chrome 141](https://developer.chrome.com/blog/digital-credentials-api-shipped) (Android + desktop cross-device). | | 📣 | 3 oct. 2025 | Articles de lancement | [Chrome](https://developer.chrome.com/blog/digital-credentials-api-shipped) et [WebKit](https://webkit.org/blog/17431/online-identity-verification-with-the-digital-credentials-api/) publient leurs articles de lancement ; Chrome souligne le support **agnostique** ; WebKit détaille le modèle **mdoc-only**. | | ⚙️ | 14 nov. 2025 | TPAC : Fin du registre de protocoles | Le W3C FedID WG [atteint un consensus](https://github.com/w3c-fedid/digital-credentials/issues/396) pour abandonner le registre ouvert et **coder en dur les protocoles supportés** directement dans la spécification. | | 🦊 | _T1 2026_ | Firefox débute l'implémentation | Mozilla intègre [le support de base](https://bugzilla.mozilla.org/show_bug.cgi?id=2005077) dans **Firefox 149**, malgré une [position officielle toujours négative](https://github.com/mozilla/standards-positions/issues/1003). | | 🇺🇸 | 27 fév. 2026 | DMV de Californie ajoute l'API | La plateforme [OpenCred du DMV de Californie ajoute le support](https://github.com/stateofca/opencred/blob/main/CHANGELOG.md) en v10.0.0. | | 🚀🤖 | _T1 2026_ | Origin Trial Émission Chrome 143 | Chrome lance un [Origin Trial pour l'**émission** de justificatifs](https://developer.chrome.com/blog/digital-credentials-api-143-issuance-ot) via `navigator.credentials.create()` avec OpenID4VCI. | | 🇪🇺📅 | _Fin 2026 (Prévu)_ | Disponibilité Portefeuilles EUDI | Les États membres de l'UE devraient rendre disponibles les portefeuilles EUDI selon [eIDAS 2.0](https://www.corbado.com/blog/eudi-wallet-2026-deadline-rollout-eic-2026). Le [Sujet F de l'ARF](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/blob/main/docs/discussion-topics/f-digital-credential-api.md) exige conditionnellement le support de l'API DC. | **Quoi de neuf depuis octobre 2025 ?** - **Changement de gouvernance des protocoles** : Le W3C FedID WG a [supprimé le registre de protocoles ouvert](https://github.com/w3c-fedid/digital-credentials/issues/396) lors du TPAC (nov. 2025) et [code désormais en dur les protocoles supportés](https://github.com/w3c-fedid/digital-credentials/pull/401) directement dans la spécification : [OpenID4VP](https://www.corbado.com/glossary/open-id-4-vp), OpenID4VCI et [ISO 18013-7](https://www.corbado.com/glossary/iso-18013-7) Annexe C. L'API n'est plus un simple « tuyau neutre ». - **L'émission arrive** : Chrome 143 a lancé un [Origin Trial pour l'émission de justificatifs](https://developer.chrome.com/blog/digital-credentials-api-143-issuance-ot) via `navigator.credentials.create()`, étendant l'API au-delà de la simple présentation. - **Firefox s'y met** : Malgré une [position officielle défavorable](https://github.com/mozilla/standards-positions/issues/1003) inchangée, Mozilla a [intégré le code de base de l'API](https://bugzilla.mozilla.org/show_bug.cgi?id=2005077) dans Firefox 149, avec des travaux d'UX en cours. - **Mandat conditionnel de l'UE** : Le [Cadre de référence architectural EUDI (Sujet F)](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/blob/main/docs/discussion-topics/f-digital-credential-api.md) exige désormais conditionnellement le support de l'API DC pour tous les portefeuilles des États membres. - **Adoption réelle** : Le [DMV de Californie](https://github.com/stateofca/opencred/blob/main/CHANGELOG.md) a ajouté le support de l'API DC à sa plateforme OpenCred (fév. 2026). ## Key Facts - **Chrome 141** et **Safari 26** ont déployé le support stable de l'API Digital Credentials en septembre 2025 ; Firefox 149 intègre le code de base depuis le 1er trimestre 2026. - **Safari 26** ne supporte que `org-iso-mdoc` ; Chrome 141 supporte OpenID4VP et ISO 18013-7 Annexe C, obligeant les parties utilisatrices à construire des backends bi-protocolaires. - Le **groupe de travail W3C FedID** a éliminé le registre ouvert de protocoles au TPAC (novembre 2025), codant en dur OpenID4VP, OpenID4VCI et ISO 18013-7 Annexe C directement dans la spécification. - Le **Sujet F de l'ARF EUDI** exige conditionnellement le support de l'API DC pour tous les portefeuilles des États membres, à condition que la spécification atteigne le statut de recommandation W3C. - Malgré une **position officielle défavorable**, Mozilla a intégré le code de base de l'API dans Firefox 149 au T1 2026, signalant une couverture probable par les trois navigateurs majeurs à venir. ## 1. Introduction : API Digital Credentials Les [identifiants numériques](https://www.corbado.com/fr/blog/identifiants-numeriques-passkeys) (Digital Credentials) sont un sujet brûlant dans le domaine de l'identité en ce moment. Alors que nos vies sont de plus en plus connectées au domaine numérique, le besoin de moyens sécurisés, centrés sur l'utilisateur et respectueux de la vie privée pour affirmer notre identité et nos qualifications en ligne n'a jamais été aussi critique. Les méthodes traditionnelles montrent leurs limites, et la demande pour des solutions plus robustes est palpable. Dans cet article, nous allons discuter de l'état actuel de l'API [Digital Credentials](https://www.corbado.com/blog/digital-credentials-api), une évolution majeure qui promet de remodeler la façon dont nous interagissons avec les informations d'identité sur le Web. Nous explorerons ses mécanismes sous-jacents, les protocoles qu'elle supporte, son adoption actuelle par les navigateurs, et offrirons des recommandations tant pour les parties utilisatrices (relying parties) que pour les [émetteurs](https://www.corbado.com/glossary/issuer) de [portefeuilles](https://www.corbado.com/blog/digital-wallet-assurance) qui naviguent dans ce paysage en évolution rapide. ## 2. Identité Numérique & Vérification Prouver son identité de manière fiable et sécurisée a été un défi persistant dans l'architecture du Web depuis de nombreuses [années](https://www.finextra.com/blogposting/27820/the-evolution-of-identity-verification-and-whats-next). Si Internet a facilité une connectivité et un échange d'informations sans précédent, il a également ouvert de nouvelles voies à la fausse représentation et à la fraude. Dans certains pays, des solutions ont émergé, principalement portées par des consortiums bancaires qui ont développé des services pour tirer parti des relations de confiance existantes pour l'identification en ligne. Les [gouvernements](https://www.corbado.com/passkeys-for-public-sector) sont également intervenus, imposant ou fournissant des [portefeuilles d'identité numérique](https://www.corbado.com/blog/digital-identity-guide) nationaux et des services associés. Cependant, ces solutions étaient souvent cloisonnées, géographiquement limitées et non universellement interopérables. Traditionnellement, la solution de repli pour la [vérification d'identité](https://www.corbado.com/blog/digital-identity-guide) dans de nombreuses régions impliquait des processus très contraignants. La vérification physique dans un bureau de poste, par exemple, introduit des délais et des désagréments importants. Les appels vidéo combinés au téléchargement de documents sont devenus une alternative plus numérique, suivis par la montée plus récente de la numérisation automatisée de documents et des [contrôles de présence (liveness checks)](https://www.identity.com/the-identity-verification-process-comprehensive-guide/). Malgré leurs avancées, ces méthodes présentent des inconvénients majeurs. Elles peuvent être longues, sujettes à l'erreur humaine ou aux biais, et ont souvent été exposées comme vulnérables à des falsifications sophistiquées. Le défi s'intensifie considérablement avec l'avènement des « deepfakes », des techniques d'usurpation d'identité avancées pilotées par l'[IA](https://www.corbado.com/fr/blog/le-role-de-lia-dans-la-detection-des-cybermenaces) et des [attaques de phishing de plus en plus sophistiquées](https://www.identity.com/the-growing-threat-of-deepfakes-to-identity-verification-processes/). Ces technologies peuvent créer des preuves vidéo, audio et documentaires très réalistes mais entièrement fabriquées, rendant incroyablement difficile pour les systèmes traditionnels, et même pour les outils de vérification alimentés par l'[IA](https://www.corbado.com/fr/blog/le-role-de-lia-dans-la-detection-des-cybermenaces), de distinguer les utilisateurs authentiques des fraudeurs. Le potentiel de création d'identités synthétiques ou de manipulation de données biométriques pour contourner les contrôles est une menace grave, en particulier pour les institutions financières et tout service nécessitant des processus de [Know Your Customer (KYC)](https://www.identity.com/the-growing-threat-of-deepfakes-to-identity-verification-processes/) robustes. Ce paysage de menaces croissant souligne le besoin urgent de mécanismes d'identité et de vérification en ligne plus sûrs et cryptographiquement vérifiables. ## 3. Comment fonctionnent les identifiants numériques ? Pour comprendre le fonctionnement des [identifiants numériques](https://www.corbado.com/fr/blog/identifiants-numeriques-passkeys), il faut s'intéresser aux acteurs clés impliqués et aux différentes couches technologiques qui permettent leur fonctionnement. ### 3.1. Le modèle à trois parties À la base, le concept d'identifiants numériques, en particulier dans le contexte des nouvelles API Web, s'articule autour d'un modèle à trois parties : 1. **Émetteur (Issuer)** : Une entité (par ex. [gouvernement](https://www.corbado.com/passkeys-for-public-sector), université, employeur) qui fait autorité pour certaines informations concernant un sujet et peut émettre un identifiant numérique attestant de ces informations. 2. **Détenteur (Holder)** : Le sujet des informations (c'est-à-dire l'utilisateur) qui reçoit l'identifiant de l'[émetteur](https://www.corbado.com/glossary/issuer) et le stocke dans un [portefeuille numérique](https://www.corbado.com/fr/blog/identifiants-numeriques-passkeys). Le détenteur contrôle quand et quelles informations de l'identifiant sont partagées. 3. **Vérificateur** (ou [Partie Utilisatrice / Relying Party](https://www.corbado.com/glossary/relying-party)) : Une entité (par ex. un site web, un service en ligne) qui doit vérifier certaines informations sur le détenteur pour accorder l'accès à un service ou une ressource. Le vérificateur demande les informations nécessaires au détenteur. ![modèle à trois parties](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/three_party_model_5eedaec078.png) Ce modèle à trois parties est important car il vise à redonner à l'utilisateur (détenteur) le contrôle de ses propres données. Contrairement aux systèmes d'identité traditionnels où les données peuvent être stockées de manière centrale ou partagées entre les parties sans intermédiation directe de l'utilisateur, ce modèle met l'accent sur le consentement de l'utilisateur et la divulgation sélective. Le détenteur décide quels éléments d'information partager à partir d'un identifiant pour une transaction spécifique, plutôt que de révéler l'intégralité de l'identifiant. Un aspect fondamental de ces systèmes est l'implication de paires de clés cryptographiques. L'[émetteur](https://www.corbado.com/glossary/issuer) signe numériquement l'identifiant, garantissant son authenticité et son intégrité. Le détenteur, à son tour, utilise sa clé privée, souvent sécurisée au sein de son [portefeuille numérique](https://www.corbado.com/fr/blog/identifiants-numeriques-passkeys) (protégé par le matériel de l'appareil), pour prouver le contrôle sur l'identifiant et autoriser sa présentation à un vérificateur. Cela implique généralement que le vérificateur présente un défi (une donnée aléatoire) que le [portefeuille](https://www.corbado.com/fr/blog/garantie-portefeuille-numerique) du détenteur signe à l'aide de la clé privée associée à l'identifiant. Le vérificateur peut alors utiliser la clé publique correspondante pour confirmer la signature, authentifiant ainsi la présentation. Cette explication est neutre vis-à-vis du protocole, car les principes fondamentaux d'émission, de détention et de vérification par défis cryptographiques sont communs aux différentes technologies sous-jacentes. Cet article se concentre sur la **vérification** des identifiants numériques et le principe de **divulgation sélective**, permettant aux utilisateurs de prouver des attributs spécifiques (par ex. « j'ai plus de 18 ans », « je possède un permis de conduire valide ») sans révéler l'intégralité du document source. Bien que les systèmes sous-jacents puissent prendre en charge des fonctionnalités telles que les Signatures Électroniques Qualifiées (QES) et les capacités de signature à distance (comme on le voit dans des solutions complètes telles que le [Portefeuille](https://www.corbado.com/fr/blog/garantie-portefeuille-numerique) d'[Identité Numérique](https://www.corbado.com/fr/glossary/openid-4-vp) de l'UE pour les signatures juridiquement contraignantes), l'accent ici, en particulier pour l'API [Digital Credentials](https://www.corbado.com/blog/digital-credentials-api), est mis sur l'[assertion](https://www.corbado.com/glossary/assertion) d'identité et la vérification d'attributs pour les interactions en ligne. ### 3.2. Les couches des identifiants numériques Pour comprendre comment fonctionnent les identifiants numériques, il est utile de visualiser un modèle en couches. Chaque couche traite un aspect différent de l'écosystème, du format des données lui-même à la manière dont il est présenté à un utilisateur dans un navigateur web. Cet article se concentre principalement sur l'**API Digital Credentials**, qui opère au niveau de la couche de présentation. ![Couches des identifiants numériques](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/digital_credential_layers_26eaf37952.png) **Terminologie clé :** - **Identifiant numérique (Digital credential) :** Tout justificatif lisible par machine (PDF avec code-barres, ISO [mDL](https://www.corbado.com/blog/mobile-drivers-license), W3C VC, SD-[JWT](https://www.corbado.com/fr/glossary/jwks), etc.). Le terme « numérique » ne dit rien sur la vérifiabilité cryptographique. - **Justificatif Vérifiable (Verifiable Credential - VC) :** Un type d'identifiant numérique, défini par le modèle de données W3C VC. Il ajoute une preuve d'intégrité (tamper-evidence) et une preuve cryptographique, et vit toujours dans un monde à trois parties : [émetteur](https://www.corbado.com/glossary/issuer) → détenteur → vérificateur. - **[Verifiable Credential API](https://w3c-ccg.github.io/vc-api/) :** Une interface de service REST/HTTP pour émettre, stocker, présenter et vérifier des VCs entre des systèmes back-end (émetteurs, [portefeuilles](https://www.corbado.com/blog/digital-wallet-assurance), vérificateurs). - **[Digital Credentials API (DC API)](https://github.com/w3c-fedid/digital-credentials) :** Une API navigateur / système d'exploitation (JavaScript + tuyauterie native) qui permet à un site web de demander au [portefeuille](https://www.corbado.com/fr/blog/garantie-portefeuille-numerique) côté appareil de l'utilisateur de présenter tout identifiant numérique supporté (VC, ISO [mDoc](https://www.corbado.com/glossary/mdoc), SD-[JWT](https://www.corbado.com/fr/glossary/jwks)…) de manière respectueuse de la vie privée. Pensez aux VCs comme à un modèle de données, à la VC API comme à une spécification back-end, et à la [DC API](https://www.corbado.com/blog/digital-credentials-api) comme à l'[implémentation](https://www.corbado.com/fr/blog/aide-memoire-cles-dacces) front-end qui présente les identifiants au Web. Tout ce qui se trouve au-dessus de la couche 1 (couche modèle de données) est agnostique au format ; tout ce qui est en dessous dépend du format de l'identifiant. **Flux de bout en bout (exemple : vérification de l'âge en ligne) :** Le diagramme suivant illustre comment ces couches fonctionnent ensemble dans un scénario réel. Notez que les données sont un VC, le transport sur le Web est la [DC API](https://www.corbado.com/blog/digital-credentials-api), le protocole d'échange sous-jacent est [OpenID4VP](https://www.corbado.com/glossary/open-id-4-vp), et la vérification côté serveur utilise la VC API. **Pourquoi cette séparation existe-t-elle ?** - **Modèle de données interopérable (preuves crypto, divulgation sélective) :** Résolu par le modèle de données VC (et autres formats). - **Endpoints REST standard pour les systèmes back-end :** Résolu par la VC API. - **Poignée de main Portefeuille ↔ Site Web respectueuse de la vie privée :** Résolu par la [DC API](https://www.corbado.com/blog/digital-credentials-api). - **Différents niveaux de confiance / types de documents (ID gouvernemental vs certificat de cours) :** Résolu en utilisant le bon format (ISO [mDoc](https://www.corbado.com/glossary/mdoc) pour les IDs haute assurance ; W3C VC pour les affirmations générales) sous la DC API. **Points clés à retenir :** 1. « Identifiant numérique » est le terme générique. 2. [Justificatif Vérifiable (VC)](https://www.corbado.com/glossary/verifiable-credential) est un type d'identifiant numérique avec vérifiabilité cryptographique intégrée. 3. VC API est la tuyauterie serveur-à-serveur pour les opérations de cycle de vie sur les VCs. 4. [Digital Credentials API](https://www.corbado.com/blog/digital-credentials-api) est le pont navigateur-à-portefeuille qui permet enfin à ces identifiants de circuler fluidement dans les applications Web, quel que soit leur format concret. 5. Les trois pièces sont complémentaires, pas concurrentes — elles se situent à différentes couches de la même pile et permettent ensemble une identité sécurisée et centrée sur l'utilisateur sur le Web ouvert. Après avoir exploré les participants et l'architecture en couches globale des identifiants numériques, cet article va maintenant approfondir la couche de présentation, en se concentrant spécifiquement sur l'API Digital Credentials et son état actuel. ## 4. Comment fonctionne l'API Digital Credentials ? En tant que composant crucial de la couche de présentation, l'API Digital Credentials est un standard web actuellement développé pour fournir un moyen sécurisé et standardisé aux sites web de demander et recevoir des informations d'[identité numérique](https://www.corbado.com/fr/glossary/openid-4-vp) depuis les [portefeuilles](https://www.corbado.com/blog/digital-wallet-assurance) des utilisateurs. Cet effort est principalement hébergé au sein du Federated Identity Working Group (FedID WG) du W3C, après avoir migré du FedID Community Group en avril 2025. La spécification officielle brouillon peut être trouvée ici : [https://w3c-fedid.github.io/digital-credentials/](https://w3c-fedid.github.io/digital-credentials/). En octobre 2025, l'API a été **déployée en version stable** dans Chrome 141 (30 sept. 2025) et Safari 26 (15 sept. 2025). L'[implémentation](https://www.corbado.com/fr/blog/aide-memoire-cles-dacces) de Chrome supporte à la fois [OpenID4VP](https://www.corbado.com/glossary/open-id-4-vp) et [ISO 18013-7](https://www.corbado.com/glossary/iso-18013-7) Annexe C, tandis que Safari supporte exclusivement le protocole `org-iso-mdoc`. **Important (Mise à jour Mars 2026) :** La relation de l'API avec les protocoles a fondamentalement changé. Au TPAC en novembre 2025, le W3C FedID WG a [atteint un consensus](https://github.com/w3c-fedid/digital-credentials/issues/396) pour **éliminer le registre de protocoles ouvert** et à la place [coder en dur une liste finie de protocoles supportés](https://github.com/w3c-fedid/digital-credentials/pull/401) directement dans la spécification : `openid4vp-v1-unsigned`, `openid4vp-v1-signed`, `openid4vp-v1-multisigned`, `org-iso-mdoc` (pour la présentation), et `openid4vci-v1` (pour l'émission). Les agents utilisateurs (navigateurs) sont censés rejeter les protocoles non listés. Cela fait du groupe de travail un gardien de facto pour les futurs ajouts de protocoles — un compromis délibéré pour permettre une revue holistique de la sécurité et de la confidentialité de tout ce qui transite par l'API. La spécification couvre désormais également **l'émission de justificatifs** via `navigator.credentials.create()`. Chrome 143 a lancé un [Origin Trial](https://developer.chrome.com/blog/digital-credentials-api-143-issuance-ot) pour cela, permettant aux sites web de déclencher des flux de provisionnement de portefeuille utilisant OpenID4VCI. Cependant, une [vulnérabilité de liaison de sélection de portefeuille](https://github.com/w3c-fedid/digital-credentials/issues/382) — où une application de portefeuille malveillante peut intercepter les codes de pré-autorisation d'émission — reste une préoccupation ouverte. Les émetteurs gouvernementaux ont indiqué qu'ils n'adopteraient pas l'émission par navigateur tant que cela ne serait pas résolu. Chrome supporte la présentation nativement sur [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android) via son [système Credential Manager](https://android-developers.googleblog.com/2025/04/announcing-android-support-of-digital-credentials.html) et supporte également l'[API Digital Credentials Cross-Device](https://developer.chrome.com/blog/digital-credentials-cross-device-ot) sur desktop via un transfert [QR code](https://www.corbado.com/blog/qr-code-login-authentication) basé sur [CTAP](https://www.corbado.com/fr/glossary/ctap)/BLE. L'API étend l'[API Credential Management](https://www.w3.org/TR/credential-management-1/) existante en permettant des demandes d'identifiants numériques via `navigator.credentials.get()`. Selon l'explainer du W3C FedID WG ([https://github.com/w3c-fedid/digital-credentials/blob/main/explainer.md](https://github.com/w3c-fedid/digital-credentials/blob/main/explainer.md)), l'API est revenue à l'utilisation de cette interface établie plutôt que la proposition précédente `navigator.identity`. Un site web demande un identifiant numérique en appelant `navigator.credentials.get()` avec des paramètres spécifiques. Voici un exemple illustratif de la façon dont un site web pourrait appeler l'API pour demander un identifiant utilisant OpenID4VP : ```javascript async function requestCredential() { // Vérifier le support de l'API Digital Credentials if (typeof window.DigitalCredential !== "undefined") { try { // Ces paramètres sont généralement récupérés depuis le backend. // Définis statiquement ici à des fins d'illustration de l'extensibilité du protocole. const oid4vp = { protocol: "oid4vp", // Un exemple de requête OpenID4VP aux portefeuilles. data: { nonce: "n-0S6_WzA2Mj", presentation_definition: { // Requête Presentation Exchange, omise pour la concision }, }, }; // créer un Abort Controller const controller = new AbortController(); // Appeler l'API Digital Credentials en utilisant la requête de présentation du backend let dcResponse = await navigator.credentials.get({ signal: controller.signal, mediation: "required", digital: { requests: [oid4vp], }, }); // Envoyer la réponse chiffrée au backend pour déchiffrement et vérification // Omis pour la concision } catch (error) { console.error("Erreur :", error); } } else { // scénario de repli, illustratif seulement alert("L'API Digital Credentials n'est pas supportée dans ce navigateur."); } } ``` Cet exemple est tiré d'[ici](https://github.com/w3c-fedid/digital-credentials/blob/main/explainer.md). L'API Digital Credentials agit essentiellement comme une enveloppe sécurisée ou un intermédiaire. Elle permet au navigateur de arbitrer la demande d'informations d'identité, en tirant parti des capacités du système d'exploitation sous-jacent pour découvrir les portefeuilles et les identifiants disponibles correspondant à la [demande](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/discussions/361). Le navigateur et l'OS peuvent alors présenter une interface utilisateur cohérente pour sélectionner l'identifiant et autoriser sa communication, améliorant la sécurité et la confidentialité en garantissant le consentement de l'utilisateur et en empêchant les sites web d'accéder silencieusement à des [données](https://w3c-fedid.github.io/digital-credentials/) sensibles. Les données réelles de l'identifiant dans la réponse sont destinées à être opaques (chiffrées) pour le navigateur lui-même, le déchiffrement et l'interprétation étant gérés par la [partie utilisatrice](https://www.corbado.com/glossary/relying-party) et le portefeuille/[détenteur](https://w3c-fedid.github.io/digital-credentials/). ## 5. Protocoles sous-jacents L'API Digital Credentials était initialement conçue pour être totalement agnostique vis-à-vis des protocoles, agissant comme un « tuyau neutre » avec un registre ouvert pour que n'importe quel protocole puisse s'inscrire. Cependant, depuis janvier 2026, la spécification [nomme désormais explicitement](https://github.com/w3c-fedid/digital-credentials/pull/401) les protocoles qu'elle supporte — les agents utilisateurs sont censés rejeter ceux non listés. Les deux principales familles de protocoles actuellement codées en dur dans la spécification sont : org.iso.[mdoc](https://www.corbado.com/glossary/mdoc) (dérivé de [ISO 18013-5](https://www.corbado.com/glossary/iso-18013-5) et son extension [ISO 18013-7](https://www.corbado.com/glossary/iso-18013-7) « Annexe C ») et les spécifications de l'OpenID Foundation pour OpenID for Verifiable Presentations (OpenID4VP) et OpenID for [Verifiable Credential](https://www.corbado.com/glossary/verifiable-credential) Issuance (OpenID4VCI). ### 5.1. org.iso.mdoc - **Origine et Standardisation** : org.iso.mdoc fait référence au format de données et au modèle d'interaction pour les documents mobiles, principalement les permis de conduire mobiles (mDL), standardisés par l'Organisation internationale de normalisation (ISO) et la Commission électrotechnique internationale (IEC). La norme fondamentale est [ISO/IEC 18013-5](https://www.iso.org/standard/69084.html), qui définit l'application [mDL](https://www.corbado.com/blog/mobile-drivers-license), la structure des données et les protocoles pour la présentation en personne (proximité) utilisant des technologies comme le NFC, le Bluetooth ou les codes [QR](https://sphericalcowconsulting.com/2024/01/03/verifiable-credentials-and-mdocs-a-tale-of-two-protocols/). [ISO/IEC 18013-7](https://www.iso.org/standard/82772.html) étend cela pour permettre la présentation en ligne/à distance des mDLs. La chaîne de protocole « org.iso.mdoc » est spécifiquement définie dans l'ISO/IEC TS 18013-7 (Annexe C) pour une utilisation avec des API comme l'API Digital Credentials. - **Modèle de données** : Les mdocs ont une structure de données strictement définie basée sur [CBOR](https://www.corbado.com/glossary/cbor) (Concise Binary Object Representation) pour la compacité et l'efficacité. Elle spécifie des espaces de noms et des éléments de données pour les attributs courants de permis de conduire et supporte des fonctionnalités de sécurité cryptographique fortes, y compris l'[authentification](https://www.corbado.com/fr/blog/webauthn-relying-party-id-rpid-passkeys) de l'émetteur, la liaison à l'appareil, l'[authentification](https://www.corbado.com/fr/blog/webauthn-relying-party-id-rpid-passkeys) du détenteur (via portrait), le chiffrement de session et la divulgation sélective. - **Cas d'usage typiques** : Principalement des documents d'identité émis par le [gouvernement](https://www.corbado.com/passkeys-for-public-sector) comme les permis de conduire et les cartes d'identité nationales. Il est conçu pour des scénarios de haute assurance, tant en personne (ex: contrôles routiers, vérification de l'âge pour des produits restreints) qu'en ligne (ex: accès aux services [gouvernementaux](https://www.corbado.com/passkeys-for-public-sector), [vérification d'identité](https://www.corbado.com/blog/digital-identity-guide) à distance pour l'[ouverture de compte](https://www.corbado.com/fr/blog/verification-identite-numerique) bancaire). ### 5.2. OpenID4VP et OpenID4VCI - **Origine et Standardisation** : OpenID4VP (pour la présentation) et [OpenID4VCI](https://www.corbado.com/glossary/openid4vci) (pour l'émission) sont des spécifications développées par l'OpenID Foundation. Elles étendent [OAuth 2.0](https://www.corbado.com/glossary/oauth2) pour supporter l'échange de [justificatifs vérifiables](https://www.corbado.com/glossary/microcredentials). Ce sont des standards ouverts visant une large interopérabilité pour divers types de justificatifs, pas seulement gouvernementaux. Début 2025, OpenID4VP est à un stade de brouillon avancé. [OpenID4VCI](https://www.corbado.com/glossary/openid4vci) mûrit également. - **Modèle de données** : OpenID4VP/VCI sont conçus pour être agnostiques vis-à-vis du format des justificatifs. Ils peuvent transporter des [Justificatifs Vérifiables](https://www.corbado.com/glossary/microcredentials) W3C (VCs) aux formats JSON/[JSON-LD](https://www.corbado.com/glossary/json-ld) ou [JWT](https://www.corbado.com/fr/glossary/jwks), des mdocs, des SD-JWTs et d'autres formats. Le modèle d'interaction implique une demande d'autorisation du Vérificateur (RP) et une réponse du Portefeuille du Détenteur contenant un vp_token (Verifiable Presentation Token). La divulgation sélective est généralement gérée à l'aide de langages de requête comme Presentation Exchange (DIF PE) ou le plus récent Digital Credentials Query Language (DCQL). - **Cas d'usage typiques** : Large gamme d'applications, incluant la [vérification d'identité](https://www.corbado.com/blog/digital-identity-guide), la fourniture de preuves de qualifications (ex: diplômes éducatifs, certifications professionnelles), les attestations d'adhésion, et plus encore. Ils sont bien adaptés aux interactions en ligne où une [partie utilisatrice](https://www.corbado.com/glossary/relying-party) doit vérifier des affirmations provenant de divers [émetteurs](https://www.corbado.com/glossary/issuer). ### 5.3. Comparaison de org.iso.mdoc et OpenID4VP/VCI | Fonctionnalité | org.iso.mdoc (ISO 18013-5/7) | OpenID4VP / OpenID4VCI | | :------------------------------- | :---------------------------------------------------------------------------------------- | :----------------------------------------------------------------------------------------------------- | | **Organisme de standardisation** | ISO/IEC | OpenID Foundation | | **Focus principal** | Permis de conduire mobiles (mDLs) & IDs officiels | Échange général de justificatifs vérifiables (tous types) | | **Format de données** | Basé sur CBOR, éléments de données strictement définis | Agnostique ; couramment [W3C VCs](https://www.w3.org/TR/vc-data-model-2.0/) (JSON/JWT), mdocs, SD-JWTs | | **Transport** | Défini pour la proximité (NFC, BLE, QR) & en ligne (18013-7) | Principalement basé sur OAuth 2.0 pour le ligne ; peut être initié via QR, deep links | | **Divulgation Sélective** | Intégrée via des claims hachés salés | Via des langages de requête comme Presentation Exchange ou DCQL | | **Maturité** | ISO 18013-5 : Norme publiée. ISO 18013-7 : TS publiée. Série ISO 23220 : En développement | OpenID4VP : Brouillon avancé (ex: draft 28). OpenID4VCI : Brouillon avancé | | **Émetteurs typiques** | Agences gouvernementales (Préfectures, DMV, etc.) | Gouvernements, institutions éducatives, employeurs, toute entité | | **Coût du standard** | Payant | Gratuit / Open Source | Il est important de reconnaître que ces protocoles ne sont pas toujours mutuellement exclusifs. OpenID4VP peut, par exemple, être utilisé pour demander et transporter un \[org.iso.mdoc]. Le choix dépend souvent du cas d'usage spécifique, du type de justificatif et des participants à l'écosystème. ### 5.4. Support du Portefeuille d'Identité Numérique de l'UE Le Portefeuille d'[Identité Numérique](https://www.corbado.com/fr/glossary/openid-4-vp) de l'Union Européenne (EUDI [Wallet](https://www.corbado.com/blog/digital-wallet-assurance)) est une initiative majeure visant à fournir à tous les citoyens et résidents de l'UE un [portefeuille numérique](https://www.corbado.com/fr/blog/identifiants-numeriques-passkeys) sécurisé pour les documents d'identité et les attestations. L'architecture et le cadre de référence du portefeuille EUDI prévoient explicitement de supporter à la fois le mdoc (particulièrement pour les permis de conduire mobiles) et les [Justificatifs Vérifiables](https://www.corbado.com/glossary/microcredentials) W3C, en utilisant OpenID4VP et [OpenID4VCI](https://www.corbado.com/glossary/openid4vci) pour les flux de présentation et d'émission. L'[implémentation](https://www.corbado.com/fr/blog/aide-memoire-cles-dacces) de référence inclut le support d'OpenID4VP transférant des mDocs et OpenID4VCI pour l'émission de PIDs et de mDLs aux formats mDoc et SD-JWT-VC. Ce double support par un projet d'une telle [envergure](https://www.corbado.com/blog/introducing-passkeys-large-scale-overview) souligne l'importance des deux familles de protocoles. **Mise à jour Mars 2026 :** L'engagement de l'UE envers l'API Digital Credentials est devenu plus concret. Le [Sujet F du Cadre de Référence Architectural (ARF)](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/blob/main/docs/discussion-topics/f-digital-credential-api.md) EUDI **exige désormais conditionnellement** que les unités de portefeuille EUDI et les Parties Utilisatrices supportent l'API DC pour la présentation à distance et les flux d'émission d'attestations. Les conditions incluent que l'API DC atteigne le statut de recommandation W3C et réponde aux attentes en matière de fonctionnalité, de neutralité navigateur/OS, de confidentialité et de protection contre le déni de service. Le [Consortium du Portefeuille Européen (EWC)](https://eudiwalletconsortium.org/) a intégré des cas de test de l'API DC dans son programme de test de conformité, et le [consortium NOBID](https://www.nobidconsortium.com/) a réalisé des pilotes de paiement utilisant OpenID4VP — le même protocole que l'API DC transporte désormais. Cependant, cette direction n'est pas sans critiques, certains observateurs notant que l'API Digital Credentials, fortement influencée par la « Bigtech US », pourrait s'incorporer profondément dans les spécifications finales du portefeuille EUDI. Des inquiétudes ont été soulevées quant à l'influence potentielle d'entités non-UE sur une pièce critique de l'infrastructure de l'UE, comme discuté dans des forums communautaires tels que [cette discussion GitHub](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/discussions/361). Séparément, la décision de [coder en dur la référence ISO 18013-7](https://github.com/w3c-fedid/digital-credentials/pull/401) dans la spécification a suscité une [objection de Ping Identity](https://github.com/w3c-fedid/digital-credentials/pull/401#discussion_r2721337228), arguant que référencer normativement une spécification payante entre en conflit avec les principes du web ouvert — une préoccupation qui pourrait refaire surface sous forme d'objection formelle lorsque la spécification passera en Candidate Recommendation. ## 6. Quel navigateur supporte l'API Digital Credential ? Le paysage des navigateurs pour l'API Digital Credentials a maintenant pris forme, avec **Chrome 141** et **Safari 26** expédiant un support stable en septembre 2025. Il existe des différences notables d'approche et de niveaux de support entre les navigateurs. ### 6.1. Google Chrome : Déployé dans la v141 ; Agnostique aux protocoles Chrome a **déployé** l'API Digital Credentials dans **Chrome 141** (30 sept. 2025). L'implémentation de Chrome est **agnostique vis-à-vis du protocole** : compatible avec **OpenID4VP** et **ISO 18013-7 Annexe C** (mdoc en ligne). Le desktop supporte la présentation **cross-device** depuis des portefeuilles mobiles via un canal **CTAP/BLE** (transfert QR), avec une réponse opaque pour le navigateur. La forme de l'API a évolué vers `navigator.credentials.get()` ; **paramètres renommés** : `providers` → `requests`, `request` → `data`. **Détection de fonctionnalité :** ```javascript if (typeof DigitalCredential !== "undefined") { // API Digital Credentials supportée } ``` Le Credential Manager d'[Android](https://www.corbado.com/blog/how-to-enable-passkeys-android) supporte nativement OpenID4VP pour la présentation et OpenID4VCI pour l'[émission](https://www.androidcentral.com/apps-software/android-os/google-enhances-digital-credentials-access-with-androids-open-standards-support), permettant aux applications [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android) d'agir comme détenteurs et vérificateurs de justificatifs en utilisant ces [standards](https://android-developers.googleblog.com/2025/04/announcing-android-support-of-digital-credentials.html). Google note un support croissant des portefeuilles ; **Google Wallet** est un adopteur précoce, avec **Samsung Wallet** et **1Password** annoncés. ### 6.2. Apple Safari : Expédié dans la v26 ; Focus mdoc uniquement (`org-iso-mdoc`) Dans les versions précédentes de cet article, nous prédisions que l'approche d'[Apple](https://www.corbado.com/fr/blog/comment-supprimer-cle-acces-apple-windows-android) divergerait de celle de Google en se concentrant sur le protocole `org.iso.mdoc`. Pour le contexte historique, notre raisonnement était le suivant : > Les preuves issues des trackers de bugs WebKit et des contributions aux standards > suggéraient que Safari choisirait de **se concentrer sur `org.iso.mdoc`** directement, > plutôt que de prioriser OpenID4VP comme couche de transport pour tous les types de > justificatifs. Cela était probablement motivé par des réserves techniques sur la > complexité d'OpenID4VP dans un contexte de navigateur et par l'investissement profond > d'[Apple](https://www.corbado.com/fr/blog/comment-supprimer-cle-acces-apple-windows-android) dans le > façonnement des normes ISO mdoc pour s'aligner sur le modèle de sécurité de leur > plateforme. Comme nous l'avions correctement anticipé, la [WWDC25](https://www.corbado.com/blog/wwdc25-passkeys-os26) a confirmé cette stratégie. Safari **26** (iOS/iPadOS/macOS) a **été publié** le 15 sept. 2025 avec le support de l'API Digital Credentials, confirmant que leur implémentation **supporte exclusivement le protocole `org-iso-mdoc`** (avec trait d'union) pour la présentation. Cela a été détaillé lors de la session [WWDC25](https://www.corbado.com/blog/wwdc25-passkeys-os26) [Verify identity documents on the web](https://developer.apple.com/videos/play/wwdc2025/232/). L'API permet aux sites web de demander des informations vérifiables à partir de documents d'identité, tels qu'un permis de conduire, stockés dans [Apple](https://www.corbado.com/fr/blog/comment-supprimer-cle-acces-apple-windows-android) [Wallet](https://www.corbado.com/blog/digital-wallet-assurance) ou dans des applications tierces de fournisseurs de documents. Points clés de l'implémentation d'Apple : - **MDOC-Only** : L'API utilise exclusivement la chaîne de protocole `"org-iso-mdoc"`, basée sur la norme ISO/IEC 18013-7 Annexe C. Il n'y a **aucun support pour OpenID4VP** dans l'implémentation Safari de l'API Digital Credentials. - **Présentation Uniquement** : L'API sert à la présentation (vérification) de justificatifs existants. L'émission dans Apple [Wallet](https://www.corbado.com/blog/digital-wallet-assurance) ou d'autres applications reste un processus séparé, hors navigateur. - **Centré Utilisateur & Sécurisé** : Le flux est initié par un geste de l'utilisateur et exploite un mécanisme de « requête partielle », où l'OS analyse et valide d'abord la requête dans un bac à sable avant de la passer à l'application portefeuille, renforçant la sécurité. - **Extensible aux Apps** : En plus d'Apple Wallet, les applications tierces peuvent agir comme fournisseurs de documents en implémentant le nouveau framework `IdentityDocumentServices` et une extension d'application. - **Support Cross-Device** : La présentation **cross-device** depuis des plateformes non-Apple utilise [CTAP](https://www.corbado.com/fr/glossary/ctap) pour la proximité après un transfert [QR code](https://www.corbado.com/blog/qr-code-login-authentication) ; la réponse JS reste chiffrée/opaque pour le navigateur. Apple a fourni un exemple de code clair pour l'utilisation de l'API par une partie utilisatrice : ```javascript async function verifyIdentity() { try { // Le serveur génère et signe cryptographiquement les données de la requête. const response = await fetch("drivers/license/data"); const data = await response.json(); // La requête spécifie le protocole 'org-iso-mdoc'. const request = { protocol: "org-iso-mdoc", // data contient la requête mdoc signée cryptographiquement. data, }; // L'API doit être appelée au sein d'un geste utilisateur. const credential = await navigator.credentials.get({ mediation: "required", digital: { requests: [request], }, }); // Envoyer la réponse chiffrée du portefeuille au serveur pour déchiffrement et validation. const verificationResponse = await fetch("/decrypt", { method: "POST", body: JSON.stringify(credential.data), headers: { "Content-Type": "application/json", }, }); // Afficher les détails vérifiés... const json = await verificationResponse.json(); presentDetails(json); } catch (err) { // Gérer les erreurs, ex: annulation par l'utilisateur. } } ``` Cette confirmation solidifie les stratégies divergentes sur le marché des navigateurs. Alors que Chrome s'appuie sur la couche de transport flexible OpenID4VP, Apple tire parti de son investissement profond dans l'écosystème ISO mdoc pour fournir une solution hautement intégrée et sécurisée, bien que moins flexible, adaptée aux documents d'identité officiels. ### 6.3. Mozilla Firefox : D'une position négative à une implémentation active Mozilla avait initialement exprimé une **position officielle défavorable** sur l'API Digital Credentials. Leurs préoccupations, [documentées en détail](https://github.com/mozilla/standards-positions/issues/1003), sont complètes et ancrées dans leur mission de protéger [la vie privée des utilisateurs](https://www.corbado.com/faq/ensure-gdpr-compliance-with-passkeys), leur libre arbitre, et d'assurer un web ouvert et équitable. Les principales préoccupations soulevées par Mozilla incluent : - **Risques pour la vie privée** : Potentiel d'augmentation du partage de données personnelles et réduction de l'anonymat en ligne si les demandes d'identifiants numériques deviennent courantes pour des interactions triviales. - **Exclusion des utilisateurs** : Risque que les personnes qui ne peuvent pas ou choisissent de ne pas utiliser d'identifiants numériques soient exclues des services et communautés en ligne. - **Problèmes d'interopérabilité** : Craintes d'une prolifération de formats de justificatifs menant à un écosystème fragmenté. - **Divulgation sélective** : Inquiétudes que les avantages de confidentialité de la divulgation sélective soient minés s'ils ne sont pas implémentés avec de fortes garanties de non-liaison. - **Centralisation de la confiance** : Craintes que l'API ne mène à une centralisation accrue de la confiance et une réduction du libre arbitre de l'utilisateur. Bien qu'un [Conseil du W3C ait rejeté une objection formelle](https://www.w3.org/2025/02/council-report-fedid-dig-cred.html) liée à ces préoccupations, le Conseil a recommandé que le groupe de travail œuvre activement pour atténuer ces dommages potentiels. **Mise à jour Mars 2026 — Implémentation en cours :** Malgré le maintien technique de sa position négative officielle, Mozilla a commencé à **implémenter activement** l'API Digital Credentials. Au premier trimestre 2026, [le support de base de l'API DC](https://bugzilla.mozilla.org/show_bug.cgi?id=2005077) a été intégré dans **Firefox 149** (derrière un flag de préférence). Le [code source](https://searchfox.org/mozilla-central/source/dom/credentialmanagement/digital/) est dans mozilla-central. Les travaux sur les invites de permission desktop et Android sont en cours. C'est un développement significatif : bien que Mozilla maintienne ses inquiétudes, elle choisit manifestement de façonner l'API de l'intérieur — à la fois par le travail sur les spécifications et l'implémentation — plutôt que de céder la conception aux autres éditeurs. Cela signale que l'API Digital Credentials est probablement en route vers un support par les trois navigateurs, bien que Mozilla pousse pour des garde-fous de confidentialité plus stricts (incluant une proposition de [journal de transparence](https://github.com/w3c-fedid/digital-credentials/issues/472) pour les demandes de justificatifs). ### 6.4. Tableau récapitulatif **Tableau 1 : Support navigateur pour l'API Digital Credentials & Protocoles (Mars 2026)** | Fonctionnalité / Navigateur | Google Chrome (Android & Desktop) | Apple Safari (iOS & macOS) | Mozilla Firefox | | :-------------------------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------- | :----------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------- | | **API Digital Credentials (`navigator.credentials.get`)** | ✅ **Stable** (141) | ✅ **Stable** (26) | 🔧 **En Dév** ([Firefox 149](https://bugzilla.mozilla.org/show_bug.cgi?id=2005077), derrière flag) | | **org.iso.mdoc via API** | ✅ **Oui** (via ISO 18013-7 Annexe C sous DC API) | ✅ **Oui** (**seulement** ; `protocol: "org-iso-mdoc"`) | 🔧 À définir (macOS pourrait utiliser les API OS ; mdoc-only initialement) | | **OpenID4VP via API** | ✅ **Oui** | ❌ **Non** (l'implémentation Safari est mdoc-only) | 🔧 À définir | | **Émission via Web API (OpenID4VCI)** | 🔧 [Origin Trial](https://developer.chrome.com/blog/digital-credentials-api-143-issuance-ot) (Chrome 143) via `credentials.create()` | ❌ API navigateur non destinée à l'émission (flux app native uniquement) | ❌ N/A | | **Flux Cross-device** | ✅ Desktop↔Mobile via transfert QR CTAP/BLE (opaque au navigateur) | ✅ Mac/iPad vers iPhone ; non-Apple via QR + CTAP sur iPhone | ❌ N/A | ## 7. Recommandations pour les Parties Utilisatrices Pour les organisations (Parties Utilisatrices ou RPs) qui ont l'intention de demander et vérifier des identifiants numériques, le paysage actuel nécessite une planification stratégique minutieuse. ### 7.1. Stratégie : Se préparer à un monde bi-protocolaire Étant donné que Safari (sorti le 15 sept. 2025) supporte exclusivement les interactions directes `org-iso-mdoc` (ISO 18013-7 Annexe C) via l'API, et que Chrome (sorti le 30 sept. 2025) est **agnostique**, supportant à la fois **OpenID4VP** et **ISO 18013-7 Annexe C** (mdoc), les RPs visant la portée la plus large doivent se préparer à supporter les interactions basées sur les deux approches. Cela signifie architecturer des systèmes capables de gérer les deux chemins de protocole, comme indiqué ci-dessous. Bien que cela ajoute de la complexité, tenter de forcer tous les utilisateurs sur un seul chemin de protocole exclura probablement une partie substantielle de la base d'utilisateurs, soit ceux sur [iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios), soit ceux sur Chrome/[Android](https://www.corbado.com/blog/how-to-enable-passkeys-android). Une approche pragmatique, bien que plus intensive en développement, est de construire la flexibilité pour gérer les deux. ### 7.2. Comprendre les différences de divulgation d'information Les Parties Utilisatrices doivent être extrêmement conscientes que même lorsqu'elles demandent le même élément logique d'information (ex: « l'utilisateur a-t-il plus de 21 ans ? »), la façon dont cela est défini dans une requête et retourné dans une réponse peut différer significativement entre une requête mdoc directe et une requête OpenID4VP (qui pourrait utiliser Presentation Exchange ou DCQL). - **Divulgation Sélective mdoc** : org.iso.mdoc a ses propres mécanismes de divulgation sélective, impliquant généralement que l'émetteur crée des hachages salés d'éléments de données individuels. Le portefeuille du détenteur ne révèle alors que les éléments demandés avec leurs sels, permettant au vérificateur de les confirmer sans voir les autres données. - **Divulgation Sélective OpenID4VP** : OpenID4VP utilise généralement un langage de requête comme Presentation Exchange (DIF PE) ou le plus récent Digital Credentials Query Language (DCQL) intégré dans la `presentation_definition` de la requête. Le portefeuille construit alors une [Présentation Vérifiable](https://www.corbado.com/glossary/verifiable-presentation) contenant uniquement les informations demandées. Les RPs doivent mapper leurs exigences de données spécifiques à ces structures de protocoles variées. Il est crucial de comprendre les nuances de l'implémentation de la divulgation sélective dans chaque protocole pour garantir que seules les données minimales nécessaires sont demandées et traitées, respectant ainsi les meilleures pratiques de confidentialité. ## 8. Recommandations pour les Émetteurs de Portefeuilles Pour les entités cherchant à émettre des identifiants numériques et fournir des applications de portefeuille, l'environnement du système d'exploitation joue un rôle crucial. ### 8.1. Considérations de plateforme : iOS vs Android Les [émetteurs](https://www.corbado.com/glossary/issuer) de portefeuilles font face à des paysages distinctement différents sur [iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios) et Android concernant la création de portefeuille, l'intégration système et l'interaction avec l'API Digital Credentials. ![Android Digital Credential](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/android_digital_credential_cfe8d92b1e.png) - **Android** : Offre généralement un écosystème plus ouvert. Le Credential Manager d'Android inclut une API Holder qui permet aux applications tierces de s'enregistrer comme détenteurs de justificatifs. Ces applications peuvent alors participer aux flux de présentation médiés par le système, répondant aux demandes de l'API Digital Credentials (via Chrome). Android supporte aussi explicitement OpenID4VCI pour l'émission. ![Apple Digital Credential](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/apple_digital_credential_f763cdaeb9.png) - **iOS** : Apple maintient un contrôle plus strict. Bien que les apps de portefeuille tierces puissent exister sur l'App Store, leur capacité à s'intégrer profondément comme détenteurs au niveau système pour des justificatifs de haute assurance (comme les mDLs destinés à Apple Wallet) est souvent soumise aux processus et droits spécifiques d'Apple. Pour l'API Digital Credentials dans Safari, les interactions seront probablement gérées de près, avec un focus primaire sur `org.iso.mdoc` présenté depuis des sources autorisées (Apple Wallet et fournisseurs tiers enregistrés). ### 8.2. Le jardin clos d'Apple pour la création de portefeuille L'approche « jardin clos » d'Apple est bien établie. Cependant, la [WWDC25](https://www.corbado.com/blog/wwdc25-passkeys-os26) a clarifié la voie pour la participation tierce. Bien qu'Apple Wallet soit le fournisseur principal intégré, Apple a introduit le **framework `IdentityDocumentServices`** pour les [applications natives](https://www.corbado.com/fr/blog/webauthn-relying-party-id-rpid-passkeys) [iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios). Cela permet aux [développeurs](https://www.corbado.com/fr/blog/aide-memoire-cles-dacces) tiers de construire des applications pouvant provisionner et présenter leurs propres documents d'identité. Pour participer au flux web, une app native doit : 1. **Enregistrer les documents** : Utiliser `IdentityDocumentProviderRegistrationStore` pour enregistrer les mdocs gérés par l'app auprès du système d'exploitation. 2. **Implémenter une extension d'app** : Ajouter une extension d'interface utilisateur « Identity Document Provider » au projet. Cette extension est responsable de l'affichage de l'interface d'autorisation à l'utilisateur lors d'un flux de vérification web. Cela signifie que pour créer un portefeuille entièrement intégré sur iOS, il faut construire une **application native** et utiliser les frameworks spécifiques d'Apple. Cela confirme que l'interaction avec l'API Digital Credentials dans Safari est gérée par l'OS, qui dépêche ensuite les requêtes vers Apple Wallet ou toute autre app fournisseur de documents enregistrée et autorisée. ## 9. Conclusion : De l'expédition à la gouvernance L'API Digital Credentials représente une avancée significative dans l'espace de l'identité numérique, offrant une approche plus sécurisée, centrée sur l'utilisateur et respectueuse de la vie privée pour la vérification d'identité. Avec **Chrome 141** et **Safari 26** ayant déployé le support stable, et **Firefox 149** portant désormais [le code d'implémentation de base](https://bugzilla.mozilla.org/show_bug.cgi?id=2005077), l'API est en route vers une couverture par les trois navigateurs. Nous tiendrons cet article à jour au fur et à mesure de l'évolution du paysage. La période depuis octobre 2025 a été définie par la **maturation de l'API, passant d'un tuyau expérimental à un standard gouverné**. L'[élimination du registre de protocoles ouvert](https://github.com/w3c-fedid/digital-credentials/issues/396) au TPAC (novembre 2025) est le signal le plus clair : le W3C FedID WG nomme et gouverne désormais explicitement les protocoles que l'API supporte. Cela permet une revue complète de la sécurité, mais fait aussi du groupe de travail un gardien. Parallèlement, l'API **s'étend de la présentation au cycle de vie complet** : l'[Origin Trial d'émission](https://developer.chrome.com/blog/digital-credentials-api-143-issuance-ot) de Chrome 143 permet aux sites de déclencher le provisionnement de portefeuilles. Mais une [vulnérabilité de liaison de sélection](https://github.com/w3c-fedid/digital-credentials/issues/382) bloque l'adoption gouvernementale de cette fonctionnalité. Sur le front réglementaire, le [Sujet F de l'ARF](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/blob/main/docs/discussion-topics/f-digital-credential-api.md) de l'UE exige conditionnellement le support de l'API DC pour tous les portefeuilles EUDI, en attendant que la spécification atteigne la Recommandation W3C. Des défis subsistent. La réalité bi-protocolaire (Chrome vs Safari) persiste pour les parties utilisatrices. La question de savoir si [les navigateurs doivent supporter tous les protocoles listés ou juste un seul](https://github.com/w3c-fedid/digital-credentials/issues/439) n'est pas résolue. Et les considérations de confidentialité restent le [plus grand fossé](https://github.com/w3c-fedid/digital-credentials/issues/255) empêchant la progression vers la Candidate Recommendation. La spécification est estimée être à 1 ou 2 ans de la Recommandation W3C.