API Digital Credentials (2026) : Prise en charge par Chrome et Safari

Dernière mise à jour : 26 mars 2026

Voici un aperçu rapide de la prise en charge de l'API Digital Credentials (identifiants numériques) dans les principaux navigateurs :

Le monde des identifiants numériques évolue rapidement. Voici un résumé des développements clés et des projections :

Want to experience digital credentials in action?

Try Digital Credentials

Quoi de neuf depuis octobre 2025 ?

• Changement de gouvernance des protocoles : Le W3C FedID WG a supprimé le registre de protocoles ouvert lors du TPAC (nov. 2025) et code désormais en dur les protocoles supportés directement dans la spécification : OpenID4VP, OpenID4VCI et 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 via navigator.credentials.create(), étendant l'API au-delà de la simple présentation.
• Firefox s'y met : Malgré une position officielle défavorable inchangée, Mozilla a intégré le code de base de l'API 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) exige désormais conditionnellement le support de l'API DC pour tous les portefeuilles des États membres.
• Adoption réelle : Le DMV de Californie a ajouté le support de l'API DC à sa plateforme OpenCred (fév. 2026).

Les identifiants numériques (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, 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 de portefeuilles qui naviguent dans ce paysage en évolution rapide.

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. 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 sont également intervenus, imposant ou fournissant des portefeuilles d'identité numérique 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é 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). 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 et des attaques de phishing de plus en plus sophistiquées. 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, 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) 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.

Want to experience digital credentials in action?

Try Digital Credentials

Pour comprendre le fonctionnement des identifiants numériques, il faut s'intéresser aux acteurs clés impliqués et aux différentes couches technologiques qui permettent leur fonctionnement.

À 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, 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 et le stocke dans un portefeuille numérique. Le détenteur contrôle quand et quelles informations de l'identifiant sont partagées.
3. Vérificateur (ou Partie Utilisatrice / 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.

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 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 (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 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 d'Identité Numérique de l'UE pour les signatures juridiquement contraignantes), l'accent ici, en particulier pour l'API Digital Credentials, est mis sur l'assertion d'identité et la vérification d'attributs pour les interactions en ligne.

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.

Terminologie clé :

• Identifiant numérique (Digital credential) : Tout justificatif lisible par machine (PDF avec code-barres, ISO mDL, W3C VC, SD-JWT, 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 → détenteur → vérificateur.
• Verifiable Credential 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, vérificateurs).
• Digital Credentials API (DC API) : Une API navigateur / système d'exploitation (JavaScript + tuyauterie native) qui permet à un site web de demander au portefeuille côté appareil de l'utilisateur de présenter tout identifiant numérique supporté (VC, ISO mDoc, SD-JWT…) 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 comme à l'implémentation 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, le protocole d'échange sous-jacent est OpenID4VP, 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.
• Différents niveaux de confiance / types de documents (ID gouvernemental vs certificat de cours) : Résolu en utilisant le bon format (ISO 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) 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 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.

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 depuis les portefeuilles 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/.

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 de Chrome supporte à la fois OpenID4VP et 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 pour éliminer le registre de protocoles ouvert et à la place coder en dur une liste finie de protocoles supportés 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 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 — 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 via son système Credential Manager et supporte également l'API Digital Credentials Cross-Device sur desktop via un transfert QR code basé sur CTAP/BLE.

L'API étend l'API Credential Management 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), 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 :

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.

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. 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 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 et le portefeuille/détenteur.

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 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 (dérivé de ISO 18013-5 et son extension ISO 18013-7 « Annexe C ») et les spécifications de l'OpenID Foundation pour OpenID for Verifiable Presentations (OpenID4VP) et OpenID for Verifiable Credential Issuance (OpenID4VCI).

• 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, qui définit l'application mDL, 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. ISO/IEC 18013-7 é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 (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 de l'émetteur, la liaison à l'appareil, l'authentification 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 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, vérification d'identité à distance pour l'ouverture de compte bancaire).

• Origine et Standardisation : OpenID4VP (pour la présentation) et OpenID4VCI (pour l'émission) sont des spécifications développées par l'OpenID Foundation. Elles étendent OAuth 2.0 pour supporter l'échange de justificatifs vérifiables. 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 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 W3C (VCs) aux formats JSON/JSON-LD ou JWT, 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é, 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 doit vérifier des affirmations provenant de divers émetteurs.

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.

Le Portefeuille d'Identité Numérique de l'Union Européenne (EUDI Wallet) est une initiative majeure visant à fournir à tous les citoyens et résidents de l'UE un portefeuille numérique 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 W3C, en utilisant OpenID4VP et OpenID4VCI pour les flux de présentation et d'émission. L'implémentation 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 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) 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) a intégré des cas de test de l'API DC dans son programme de test de conformité, et le consortium NOBID 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. Séparément, la décision de coder en dur la référence ISO 18013-7 dans la spécification a suscité une objection de Ping Identity, 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.

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.

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é :

if (typeof DigitalCredential !== "undefined") {
    // API Digital Credentials supportée
}

Le Credential Manager d'Android supporte nativement OpenID4VP pour la présentation et OpenID4VCI pour l'émission, permettant aux applications Android d'agir comme détenteurs et vérificateurs de justificatifs en utilisant ces standards. Google note un support croissant des portefeuilles ; Google Wallet est un adopteur précoce, avec Samsung Wallet et 1Password annoncés.

Dans les versions précédentes de cet article, nous prédisions que l'approche d'Apple divergerait de celle de Google en se concentrant sur le protocole org.iso.mdoc. Pour le contexte historique, notre raisonnement était le suivant :

Comme nous l'avions correctement anticipé, la WWDC25 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 Verify identity documents on the web. 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 Wallet 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 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 pour la proximité après un transfert QR code ; 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 :

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.

Mozilla avait initialement exprimé une position officielle défavorable sur l'API Digital Credentials. Leurs préoccupations, documentées en détail, sont complètes et ancrées dans leur mission de protéger la vie privée des utilisateurs, 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 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 a été intégré dans Firefox 149 (derrière un flag de préférence). Le code source 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 pour les demandes de justificatifs).

Tableau 1 : Support navigateur pour l'API Digital Credentials & Protocoles (Mars 2026)

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.

É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, soit ceux sur Chrome/Android. Une approche pragmatique, bien que plus intensive en développement, est de construire la flexibilité pour gérer les deux.

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 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é.

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.

Les émetteurs de portefeuilles font face à des paysages distinctement différents sur iOS et Android concernant la création de portefeuille, l'intégration système et l'interaction avec l'API Digital Credentials.

• 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.

• 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).

L'approche « jardin clos » d'Apple est bien établie. Cependant, la WWDC25 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 iOS. Cela permet aux développeurs 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.

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, 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 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 de Chrome 143 permet aux sites de déclencher le provisionnement de portefeuilles. Mais une vulnérabilité de liaison de sélection bloque l'adoption gouvernementale de cette fonctionnalité.

Sur le front réglementaire, le Sujet F de l'ARF 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 n'est pas résolue. Et les considérations de confidentialité restent le plus grand fossé empêchant la progression vers la Candidate Recommendation. La spécification est estimée être à 1 ou 2 ans de la Recommandation W3C.