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

Dernière mise à jour : 30 octobre 2025

Voici un aperçu rapide de la prise en charge de l'API Digital Credentials par les principaux navigateurs :

Le monde des Digital Credentials évolue rapidement. Voici un aperçu des développements clés et des projections :

Want to experience digital credentials in action?

Try Digital Credentials

Qu'est-ce qui a changé depuis juillet 2025 ?

• Disponible : Chrome 141 (30 sept. 2025) & Safari 26 (15 sept. 2025).
• Chrome : Agnostique au protocole (OpenID4VP et ISO 18013-7 Annexe C), inter-appareils sur ordinateur via CTAP.
• Safari : mdoc uniquement (org-iso-mdoc), flux inter-appareils via CTAP.
• Forme de l'API : navigator.credentials.get() ; nommage requests/data ; détection de la fonctionnalité DigitalCredential.

Les Digital Credentials sont un sujet brûlant dans le domaine de l'identité en ce moment. À mesure que nos vies deviennent de plus en plus connectées au monde numérique, le besoin de moyens sûrs, 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 de solutions plus robustes est palpable.

Dans cet article, nous allons discuter de l'état actuel de l'API Digital Credentials, une avancée importante 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 prend en charge, son adoption actuelle par les navigateurs, et nous offrirons des recommandations pour les Relying Parties et les Issuers de wallets qui naviguent dans ce paysage en rapide évolution.

Prouver son identité de manière fiable et sécurisée est 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 aussi ouvert de nouvelles voies à la fraude et à l'usurpation d'identité.

Dans certains pays, des solutions ont émergé, principalement portées par les premiers 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, en imposant ou en fournissant des portefeuilles et des services d'identité numérique nationaux. Cependant, ces solutions étaient souvent cloisonnées, géographiquement limitées et pas universellement interopérables.

La solution de repli pour la vérification d'identité dans de nombreuses régions a traditionnellement impliqué des processus à forte friction. La vérification physique dans un bureau de poste, par exemple, entraîne des retards 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, suivie par l'essor plus récent de la numérisation automatisée des documents et des vérifications du vivant (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 se sont souvent révélées vulnérables aux falsifications sophistiquées.

Le défi s'intensifie de manière spectaculaire avec l'avènement des deepfakes, des techniques d'usurpation d'identité avancées basées sur 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 basés sur 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 sérieuse, en particulier pour les institutions financières et tout service nécessitant des processus robustes de connaissance du client (KYC). Ce paysage de menaces en pleine escalade 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 Digital Credentials, il faut examiner les acteurs clés impliqués et les différentes couches technologiques qui permettent leur fonctionnalité.

À la base, le concept de Digital Credentials, en particulier dans le contexte des nouvelles API web, s'articule autour d'un modèle à trois parties :

1. Issuer (Émetteur) : Une entité (par ex., gouvernement, université, employeur) qui fait autorité pour certaines informations sur un sujet et peut émettre un Digital Credential attestant de ces informations.
2. Holder (Détenteur) : Le sujet des informations (c'est-à-dire l'utilisateur) qui reçoit l'information d'identification de l'émetteur et la stocke dans un portefeuille numérique. Le détenteur contrôle quand et quelles informations de l'identifiant sont partagées.
3. Verifier (Vérificateur) (ou Relying Party) : Une entité (par ex., un site web, un service en ligne) qui a besoin de 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 à donner à 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 centralisée 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 quelles informations partager à partir d'un identifiant pour une transaction spécifique, plutôt que de révéler l'identifiant complet.

Un aspect fondamental de ces systèmes est l'implication de paires de clés cryptographiques. L'émetteur signe numériquement l'information d'identification, garantissant son authenticité et son intégrité. Le détenteur, à son tour, utilise sa clé privée, souvent sécurisée dans son portefeuille numérique (qui est protégé par le matériel de l'appareil), pour prouver le contrôle sur l'information d'identification et pour 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 en utilisant 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 des défis cryptographiques sont communs aux différentes technologies sous-jacentes.

Cet article se concentre sur la vérification des Digital Credentials 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 pour les Digital Credentials puissent prendre en charge des fonctionnalités comme les signatures électroniques qualifiées (QES) et les capacités de signature à distance (comme on le voit dans des solutions complètes comme le portefeuille d'identité numérique de l'UE pour les signatures juridiquement contraignantes), l'accent est mis ici, en particulier pour l'API Digital Credentials, sur l'assertion d'identité et la vérification d'attributs pour les interactions en ligne, et non principalement sur ces fonctionnalités de signature plus larges.

Pour comprendre comment fonctionnent les Digital Credentials, il est utile de visualiser un modèle en couches. Chaque couche aborde 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 de base :

• Digital Credential : Tout identifiant lisible par machine (PDF avec un code-barres, ISO mDL, W3C VC, SD-JWT, etc.). « Numérique » ne dit rien sur la vérifiabilité cryptographique.
• Verifiable Credential : Un type de Digital Credential, défini par le modèle de données W3C VC. Il ajoute une preuve d'intégrité et une preuve cryptographique, et il vit toujours dans un monde à trois parties : émetteur → détenteur → vérificateur.
• API Verifiable Credential : Une interface de service REST/HTTP pour l'émission, le stockage, la présentation et la vérification des VCs entre les systèmes back-end (émetteurs, portefeuilles, vérificateurs).
• API Digital Credentials (DC API) : Une API de navigateur / système d'exploitation (JavaScript + plomberie native) qui permet à un site web de demander au portefeuille côté appareil de l'utilisateur de présenter n'importe quel Digital Credential pris en charge (VC, ISO mDoc, SD-JWT…) d'une manière respectueuse de la vie privée.

Pensez aux VCs comme à un modèle de données, à l'API VC comme à une spécification back-end, et à l'API DC comme à l'implémentation front-end qui présente les informations d'identification au Web. Tout ce qui se trouve au-dessus de la couche 1 (couche du modèle de données) est agnostique au format ; tout ce qui se trouve en dessous dépend du format de l'identifiant.

Flux de bout en bout (exemple : vérification d'âge en ligne) :

1. Émission (API VC - émetteur ↔ portefeuille) : Le service des immatriculations émet un Verifiable Credential qui dit « Le détenteur a plus de 18 ans ».
2. Stockage (App Wallet - OS) : L'identifiant se trouve dans le portefeuille de l'utilisateur avec sa preuve cryptographique.
3. Requête (navigator.credentials.get() via l'API DC - site web → navigateur) : Le site web d'une boutique de bière demande : « Montrez-moi la preuve que l'utilisateur a ≥18 ans. »
4. Présentation (L'API DC transmet au portefeuille → OpenID4VP (protocole) → charge utile VC) : Le portefeuille affiche une interface de consentement, l'utilisateur approuve, le portefeuille renvoie une présentation vérifiable.
5. Vérification (API VC - back-end de la boutique de bière) : Le back-end du site vérifie la signature et le DID/la clé publique de l'émetteur ; accorde l'accès.

Remarquez comment les données sont un VC, le transport sur le Web est l'API DC, le protocole d'échange sous-jacent est OpenID4VP, et la vérification côté serveur utilise l'API VC.

Pourquoi cette séparation existe :

• Modèle de données interopérable (preuves cryptographiques, divulgation sélective) : Résolu par le modèle de données VC (& autres formats).
• Points de terminaison REST standard pour les systèmes back-end : Résolu par l'API VC.
• Poignée de main portefeuille ↔ site web respectueuse de la vie privée : Résolu par l'API DC.
• Différents niveaux de confiance / types de documents (pièce d'identité gouvernementale vs certificat de cours) : Résolu en utilisant le bon format (ISO mDoc pour les identités à haute assurance ; W3C VC pour les affirmations générales) sous l'API DC.

Points clés à retenir :

1. « Digital Credential » est le terme générique.
2. Verifiable Credential est un type de Digital Credential avec une vérifiabilité cryptographique intégrée.
3. L'API VC est la plomberie serveur à serveur pour les opérations du cycle de vie sur les VCs.
4. L'API Digital Credentials est le pont entre le navigateur et le portefeuille qui permet enfin à ces informations d'identification de circuler de manière fluide 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 globale en couches des Digital Credentials, 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 une norme web en cours de développement pour fournir un moyen sécurisé et standardisé aux sites web de demander et de recevoir des informations d'identité numérique à partir des portefeuilles numériques des utilisateurs. Cet effort est principalement hébergé au sein du groupe de travail Federated Identity (FedID WG) du W3C, après avoir migré du FedID Community Group en avril 2025. Le projet de spécification officiel se trouve ici : https://w3c-fedid.github.io/digital-credentials/.

En octobre 2025, l'API est disponible dans les versions stables de Chrome 141 (30 sept. 2025) et Safari 26 (15 sept. 2025). L'implémentation de Chrome est agnostique au protocole, prenant en charge à la fois OpenID4VP et ISO 18013-7 Annexe C, tandis que Safari prend exclusivement en charge le protocole org-iso-mdoc. Chrome prend en charge cela nativement sur Android via son système Credential Manager et prend également en charge l'API Digital Credentials inter-appareils sur ordinateur via une transmission QR soutenue par CTAP/BLE.

L'API étend l'API Credential Management existante en permettant les requêtes de Digital Credentials via navigator.credentials.get(). Selon l'explainer des Digital Credentials 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 le navigator.identity précédemment proposé. Un site web demande un Digital Credential en appelant navigator.credentials.get() avec des paramètres spécifiques pour les Digital Credentials.

Voici un exemple illustratif de la manière dont un site web pourrait appeler l'API pour demander un identifiant en utilisant l'OpenID4VP :

async function requestCredential() {
    // Check for Digital Credentials API support
    if (typeof window.DigitalCredential !== "undefined") {
        try {
            // These parameters are typically fetched from the backend.
            // Statically defined here for protocol extensibility illustration purposes.
            const oid4vp = {
                protocol: "oid4vp", // An example of an OpenID4VP request to wallets. // Based on https://github.com/openid/OpenID4VP/issues/125
                data: {
                    nonce: "n-0S6_WzA2Mj",
                    presentation_definition: {
                        //Presentation Exchange request, omitted for brevity
                    },
                },
            };
 
            // create an Abort Controller
            const controller = new AbortController();
 
            // Call the Digital Credentials API using the presentation request from the backend
            let dcResponse = await navigator.credentials.get({
                signal: controller.signal,
                mediation: "required",
                digital: {
                    requests: [oid4vp],
                },
            });
 
            // Send the encrypted response to the backend for decryption and verification
            // Ommitted for brevity
        } catch (error) {
            console.error("Error:", error);
        }
    } else {
        // fallback scenario, illustrative only
        alert("The Digital Credentials API is not supported in this browser.");
    }
}

Cet exemple est tiré d'ici.

L'API Digital Credentials agit essentiellement comme un wrapper ou un intermédiaire sécurisé. Elle permet au navigateur de servir de médiateur pour 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 informations d'identification disponibles qui correspondent à la requête. Le navigateur et le système d'exploitation peuvent alors présenter une interface utilisateur cohérente pour sélectionner l'identifiant et autoriser sa communication, améliorant ainsi 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 Relying Party et le portefeuille/détenteur.

L'API Digital Credentials est conçue pour être agnostique au protocole, ce qui signifie qu'elle peut prendre en charge divers protocoles sous-jacents pour l'échange d'informations d'identification. Cependant, deux grandes familles de protocoles sont au cœur des implémentations et des discussions actuelles : org.iso.mdoc (dérivé de ISO 18013-5 et de son extension ISO 18013-7 « Annexe C ») et les spécifications OpenID for Verifiable Presentations (OpenID4VP) et OpenID for Verifiable Credential Issuance (OpenID4VCI) de la Fondation OpenID.

• 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 (mDLs), normalisé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é) à l'aide de 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 la norme ISO/IEC TS 18013-7 (Annexe C) pour être utilisée 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é. Il spécifie des espaces de noms et des éléments de données pour les attributs courants des permis de conduire et prend en charge de solides fonctionnalités de sécurité cryptographique, notamment l'authentification de l'émetteur, la liaison à l'appareil, l'authentification du détenteur (via le portrait), le chiffrement de la session et la divulgation sélective.

• Cas d'utilisation typiques : Principalement les 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 à haute assurance, à la fois en personne (par ex., contrôles routiers, vérification de l'âge pour les biens réglementés) et en ligne (par 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 la Fondation OpenID. Elles étendent OAuth 2.0 pour prendre en charge l'échange de verifiable credentials. Ce sont des normes ouvertes visant une large interopérabilité pour divers types d'informations d'identification, pas seulement gouvernementales. Début 2025, OpenID4VP est à un stade avancé de projet (par ex., projet 28 en avril). OpenID4VCI est également en cours de maturation.
• Modèle de données : OpenID4VP/VCI sont conçus pour être agnostiques au format des informations d'identification. Ils peuvent transporter des Verifiable Credentials (VCs) W3C 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'utilisation typiques : Large éventail d'applications, y compris la vérification d'identité, la preuve de qualifications (par ex., diplômes universitaires, certifications professionnelles), les attestations d'adhésion, etc. Ils sont bien adaptés aux interactions en ligne où une Relying Party a besoin de vérifier des affirmations provenant de divers émetteurs.

Il est important de reconnaître que ces options ne sont pas toujours mutuellement exclusives. OpenID4VP peut, par exemple, être utilisé pour demander et transporter un [org.iso.mdoc]. Le choix dépend souvent du cas d'utilisation spécifique, du type d'identifiant et des participants de l'écosystème.

Le portefeuille d'identité numérique de l'Union européenne (EUDI) 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 prendre en charge à la fois mdoc (en particulier pour les permis de conduire mobiles) et les Verifiable Credentials 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 d'OpenID4VCI pour l'émission de PIDs et de mDLs aux formats mDoc et SD-JWT-VC formats. Ce double support par un projet d'une telle envergure souligne l'importance des deux familles de protocoles. Cependant, cette direction n'est pas sans critiques, car certains observateurs notent que l'API Digital Credentials, fortement influencée par les entreprises « Bigtech américaines », pourrait être profondément intégrée dans les spécifications finales du portefeuille EUDI. Des préoccupations ont été soulevées quant à l'influence potentielle d'entités non-UE sur une pièce essentielle de l'infrastructure de l'UE, comme discuté dans les forums communautaires tels que cette discussion GitHub.

Le paysage des navigateurs pour l'API Digital Credentials a maintenant pris forme, avec Chrome 141 et Safari 26 qui ont livré un support stable en septembre 2025. Il existe des différences notables dans l'approche et les niveaux de support entre les navigateurs.

Chrome a livré l'API Digital Credentials dans Chrome 141 (30 sept. 2025). L'implémentation de Chrome est agnostique au protocole : compatible avec OpenID4VP et ISO 18013-7 Annexe C (mdoc en ligne). La version de bureau prend en charge la présentation inter-appareils depuis des portefeuilles mobiles via un canal soutenu par CTAP/BLE (transmission QR), avec la réponse opaque pour le navigateur. La forme de l'API est passée à navigator.credentials.get() ; les paramètres ont été renommés : providers → requests, request → data.

Détection de la fonctionnalité :

if (typeof DigitalCredential !== "undefined") {
    // Digital Credentials API supported
}

Le Credential Manager d'Android prend en charge nativement OpenID4VP pour la présentation et OpenID4VCI pour l'émission, permettant aux applications Android d'agir en tant que détenteurs et vérificateurs d'informations d'identification en utilisant ces normes. Google note un soutien croissant des portefeuilles ; Google Wallet est l'un des premiers à l'adopter, avec Samsung Wallet et 1Password annoncés.

Dans les versions précédentes de cet article, nous avions prédit 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é livré le 15 sept. 2025 avec le support de l'API Digital Credentials, confirmant que leur implémentation prend exclusivement en charge le protocole org-iso-mdoc (avec un trait d'union) pour la présentation.

Cela a été détaillé dans 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é, comme 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 uniquement : 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 de l'API Digital Credentials par Safari.
• Présentation uniquement : L'API est destinée à la présentation (vérification) d'informations d'identification existantes. L'émission dans Apple Wallet ou d'autres applications reste un processus distinct, non lié au navigateur.
• Centré sur l'utilisateur et sécurisé : Le flux est initié par un geste de l'utilisateur et tire parti d'un mécanisme de « requête partielle », où le système d'exploitation analyse et valide d'abord la requête dans un bac à sable avant de la transmettre à l'application de portefeuille, ce qui améliore la sécurité.
• Extensible aux applications : En plus d'Apple Wallet, les applications tierces peuvent agir en tant que fournisseurs de documents en implémentant le nouveau framework IdentityDocumentServices et une extension d'application.
• Support inter-appareils : La présentation inter-appareils depuis des plateformes non-Apple utilise CTAP pour la proximité après une transmission par code QR ; la réponse JS reste chiffrée/opaque pour le navigateur.

Apple a fourni un exemple de code clair sur la manière dont une Relying Party utiliserait l'API :

async function verifyIdentity() {
    try {
        // Server generates and cryptographically signs the request data.
        const response = await fetch("drivers/license/data");
        const data = await response.json();
 
        // The request specifies the 'org-iso-mdoc' protocol.
        const request = {
            protocol: "org-iso-mdoc",
            // data contains the cryptographically signed mdoc request.
            data,
        };
 
        // The API must be called from within a user gesture.
        const credential = await navigator.credentials.get({
            mediation: "required",
            digital: {
                requests: [request],
            },
        });
 
        // Send the encrypted response from the wallet to the server for decryption and validation.
        const verificationResponse = await fetch("/decrypt", {
            method: "POST",
            body: JSON.stringify(credential.data),
            headers: {
                "Content-Type": "application/json",
            },
        });
 
        // Display the verified details...
        const json = await verificationResponse.json();
        presentDetails(json);
    } catch (err) {
        // Handle errors, e.g., user cancellation.
    }
}

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 a officiellement exprimé une position négative sur les normes concernant l'API Digital Credentials telle qu'elle est actuellement. Leurs préoccupations sont complètes et ancrées dans leur mission de protection de la vie privée des utilisateurs, de leur autonomie et de la garantie d'un web ouvert et équitable.

Les principales préoccupations soulevées par Mozilla incluent :

• Risques pour la vie privée : Potentiel d'un partage accru de données personnelles et d'une réduction de l'anonymat en ligne si les demandes de Digital Credentials deviennent courantes pour des interactions triviales.
• Exclusion des utilisateurs : Risque que les personnes qui ne peuvent pas ou choisissent de ne pas utiliser les Digital Credentials soient exclues des services et des communautés en ligne. Les informations d'identification émises par le gouvernement, un cas d'utilisation principal, peuvent ne pas correspondre au choix de présentation de l'identité d'un individu.
• Problèmes d'interopérabilité : Craintes d'une prolifération de formats d'informations d'identification conduisant à un écosystème fragmenté plutôt qu'à un écosystème universellement interopérable.
• Divulgation sélective : Inquiétudes que les avantages en matière de confidentialité de la divulgation sélective puissent être sapés si elle n'est pas mise en œuvre avec de solides garanties de non-traçabilité, ou si les utilisateurs ne comprennent pas pleinement ce qui est partagé.
• Centralisation de la confiance et de l'autonomie de l'utilisateur : Craintes que l'API puisse conduire à une centralisation accrue de la confiance et à une réduction de l'autonomie de l'utilisateur, perpétuant ainsi les déséquilibres de pouvoir sociétaux existants.

Mozilla reconnaît qu'une telle API pourrait offrir une utilité par rapport aux méthodes ad hoc existantes pour la présentation d'informations d'identification, mais souligne que les nouvelles fonctionnalités de la plateforme web doivent manifestement améliorer le web dans son ensemble et donner la priorité aux intérêts des utilisateurs. Bien qu'un Conseil du W3C ait rejeté une objection formelle liée à ces préoccupations (pour permettre aux travaux de se poursuivre au sein du W3C plutôt que dans des lieux potentiellement moins transparents), le Conseil a recommandé que le groupe de travail s'efforce activement d'atténuer ces préjudices potentiels.

Tableau 1 : Support de l'API Digital Credentials et des protocoles par les navigateurs (oct. 2025)

Pour les organisations (Relying Parties ou RPs) qui ont l'intention de demander et de vérifier les Digital Credentials des utilisateurs, le paysage actuel nécessite une planification stratégique minutieuse.

Étant donné que Safari (livré le 15 sept. 2025) prend exclusivement en charge les interactions directes org-iso-mdoc (ISO 18013-7 Annexe C) via l'API Digital Credentials, et que Chrome (livré le 30 sept. 2025) est agnostique au protocole, prenant en charge à la fois OpenID4VP et ISO 18013-7 Annexe C (mdoc), les RPs visant la plus large portée possible devraient se préparer à prendre en charge les interactions basées sur les deux approches.

Cela signifie architecturer des systèmes capables de :

1. Initier des demandes d'informations d'identification via l'API navigator.credentials.get(), en spécifiant différents paramètres de protocole ("org-iso-mdoc" pour Safari ou "openid4vp" pour les flux Chrome/OID4VP) en fonction de la détection du navigateur ou des capacités de l'user agent.
2. Traiter les réponses qui peuvent arriver directement dans un format mdoc (ISO 18013-7 Annexe C) ou sous forme de vp_token via OpenID4VP, qui doit ensuite être analysé pour extraire l'identifiant sous-jacent (qui pourrait lui-même être un mdoc ou un autre format VC).

Bien que cela ajoute de la complexité, tenter de forcer tous les utilisateurs à suivre une seule voie de protocole exclura probablement une partie substantielle de la base d'utilisateurs, que ce soit ceux sur iOS ou ceux sur Chrome/Android, selon la voie choisie. Une approche pragmatique, bien que plus intensive en développement, consiste à intégrer la flexibilité nécessaire pour gérer les deux.

Les Relying Parties doivent être parfaitement conscientes que même lorsqu'elles demandent la même information logique (par ex., « l'utilisateur a-t-il plus de 21 ans ? »), la manière dont cela est défini dans une requête et dont cela est retourné dans une réponse peut différer considérablement 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 ainsi que leurs sels, permettant au vérificateur de les confirmer par rapport aux hachages sans voir d'autres données. La demande d'éléments spécifiques est liée à des espaces de noms et des identifiants d'éléments de données prédéfinis dans la norme mdoc.
• 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 présentation_definition de la requête. Cela permet aux RPs de spécifier les types d'informations d'identification et les affirmations individuelles dont elles ont besoin. Le portefeuille construit alors une Présentation Vérifiable ne contenant que les informations demandées, si cela est pris en charge par le format de l'identifiant et le portefeuille.

Les RPs doivent faire correspondre leurs besoins spécifiques en données à ces différentes structures de protocole. Il est crucial de comprendre les nuances de la manière dont la divulgation sélective est mise en œuvre et demandée dans chaque protocole pour s'assurer que seules les données minimales nécessaires sont demandées et traitées, respectant ainsi les meilleures pratiques en matière de confidentialité et les principes de minimisation des données. Le format et la structure des données divulguées retournées par le portefeuille peuvent également différer, nécessitant une logique d'analyse et de validation distincte sur le backend du RP.

Pour les entités qui cherchent à émettre des Digital Credentials et à fournir des applications de portefeuille pour les détenteurs, l'environnement du système d'exploitation joue un rôle crucial.

Les émetteurs de portefeuilles font face à des paysages très différents sur iOS et Android en ce qui concerne la création de portefeuilles, 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 natives tierces de s'enregistrer en tant que détenteurs d'informations d'identification. Ces applications de détenteur enregistrées peuvent ensuite participer aux flux de présentation d'informations d'identification médiés par le système, en répondant aux requêtes de l'API Digital Credentials (via Chrome) ou des vérificateurs d'applications natives. Android prend également explicitement en charge OpenID4VCI pour l'émission d'informations d'identification, permettant aux utilisateurs de choisir un portefeuille tiers compatible pour recevoir les nouvelles informations d'identification émises. Bien que les applications natives soient au centre des capacités complètes de détenteur d'informations d'identification, le système est conçu pour une participation plus large.

• iOS : Apple maintient un contrôle plus strict sur son écosystème. Bien que des applications de portefeuille tierces puissent exister sur l'App Store, leur capacité à s'intégrer profondément en tant que détenteurs d'informations d'identification au niveau du système pour les informations d'identification à haute assurance (comme les mDLs destinés à Apple Wallet) est souvent soumise aux processus et aux droits spécifiques d'Apple. L'ajout d'une pièce d'identité à Apple Wallet, par exemple, est un flux contrôlé impliquant les autorités émettrices de l'État et la vérification d'Apple. Pour l'API Digital Credentials dans Safari, les interactions seront probablement gérées de près, avec un accent principal sur org.iso.mdoc présenté à partir de sources autorisées, à savoir Apple Wallet lui-même et les applications tierces de fournisseurs de documents enregistrées.

L'approche du « jardin clos » d'Apple est bien établie, et leur implémentation des Digital Credentials ne fait pas exception. Cependant, la WWDC25 a clarifié la voie pour la participation de tiers.

Bien qu'Apple Wallet soit le fournisseur principal et intégré pour les informations d'identification comme les mDLs d'État, Apple a introduit le framework IdentityDocumentServices pour les applications natives iOS. Cela permet aux développeurs tiers de créer des applications qui peuvent provisionner et présenter leurs propres documents d'identité.

Pour participer au flux web, une application native doit :

1. Enregistrer les documents : Utiliser le IdentityDocumentProviderRegistrationStore pour enregistrer les mdocs que l'application gère auprès du système d'exploitation. Cet enregistrement inclut le type de document et les autorités de certification de confiance pour la signature des requêtes.
2. Implémenter une extension d'application : Ajouter une extension d'application UI « Identity Document Provider » au projet. Cette extension est responsable de l'affichage de l'interface d'autorisation à l'utilisateur lorsque l'application est sélectionnée lors d'un flux de vérification basé sur le web.

Cela signifie que bien que la création d'un portefeuille entièrement intégré sur iOS nécessite de créer une application native et d'utiliser les frameworks spécifiques d'Apple — et non des technologies web comme les PWAs — il existe un mécanisme clair, bien que étroitement contrôlé, pour que les applications tierces agissent en tant que fournisseurs de documents aux côtés d'Apple Wallet. Cela confirme que l'interaction avec l'API Digital Credentials dans Safari est gérée par le système d'exploitation, qui transmet ensuite les requêtes à Apple Wallet ou à toute autre application de fournisseur de documents enregistrée et autorisée.

L'API Digital Credentials représente une avancée significative dans le domaine de l'identité numérique, offrant une approche plus sûre, centrée sur l'utilisateur et respectueuse de la vie privée pour la vérification d'identité et la présentation d'informations d'identification. Avec Chrome 141 (30 sept. 2025) et Safari 26 (15 sept. 2025) qui offrent désormais un support stable, l'API est passée du stade expérimental à celui de la production. Alors que l'écosystème continue d'évoluer, il est crucial pour les Relying Parties et les émetteurs de portefeuilles de s'adapter et d'adopter le potentiel de cette new technologie. Nous maintiendrons cet article à jour au fur et à mesure que le paysage évolue.

Cependant, des défis subsistent. Atteindre une véritable interopérabilité mondiale entre les différents formats d'informations d'identification, protocoles et implémentations de portefeuilles est une entreprise considérable. Répondre aux préoccupations légitimes soulevées par des organisations comme Mozilla concernant la vie privée, l'exclusion et l'autonomie de l'utilisateur est primordial pour garantir que ces technologies servent l'humanité. Les approches divergentes — l'implémentation agnostique au protocole de Chrome contre l'approche mdoc uniquement de Safari — signifient que les Relying Parties et les émetteurs de portefeuilles devront naviguer dans un paysage à double protocole dans un avenir prévisible.