API Digital Credentials (2025) : Chrome et Safari (WWDC25)

Dernière mise à jour : 15 juillet 2025 (après la WWDC25)

Un aperçu rapide du support de l'API Digital Credentials dans les principaux navigateurs :

Le monde des informations d'identification numériques évolue rapidement. Voici un aperçu des développements clés et des projections :

Les informations d'identification numériques, ou 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é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 de solutions plus robustes est palpable.

Dans cet article, nous allons explorer 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 examinerons ses mécanismes sous-jacents, les protocoles qu'elle supporte, l'adoption actuelle par les navigateurs, et nous proposerons des recommandations pour les relying parties (parties de confiance) et les émetteurs de wallets naviguant 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 également ouvert de nouvelles voies à la fausse déclaration et à la fraude.

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 wallets 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, suivis par l'essor plus récent de la numérisation automatisée de 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 chronophages, 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 façon 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 constitue 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 de vérification et d'identité en ligne plus sécurisés et vérifiables par cryptographie.

Want to try digital credentials yourself in a demo?

Try Digital Credentials

Comprendre le fonctionnement des informations d'identification numériques implique d'examiner les acteurs clés impliqués et les différentes couches technologiques qui permettent leur fonctionnalité.

À la base, le concept d'informations d'identification numériques, en particulier dans le contexte des nouvelles API web, s'articule autour d'un modèle à trois parties :

1. Émetteur : Une entité (par exemple, un gouvernement, une université, un employeur) qui fait autorité pour certaines informations concernant un sujet et qui peut émettre une information d'identification numérique attestant de ces informations.
2. Détenteur : Le sujet de l'information (c'est-à-dire l'utilisateur) qui reçoit l'information d'identification de l'émetteur et la stocke dans un wallet numérique. Le détenteur contrôle quand et quelles informations de son identifiant sont partagées.
3. Vérificateur (ou Relying Party) : Une entité (par exemple, 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 (le 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 wallet numérique (qui est protégé par le matériel de l'appareil), pour prouver le contrôle de 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 wallet 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 à différentes technologies sous-jacentes.

Cet article se concentre sur la vérification des informations d'identification numériques et le principe de divulgation sélective, permettant aux utilisateurs de prouver des attributs spécifiques (par exemple, "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 informations d'identification numériques 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 comme le Wallet 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 le fonctionnement des informations d'identification numériques, 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 elles sont présentées à 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 :

• Information d'identification numérique (Digital credential) : Toute information d'identification 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.
• Information d'identification vérifiable (Verifiable Credential) : Un type d'information d'identification numérique, défini par le modèle de données W3C VC. Elle ajoute une preuve d'intégrité et une preuve cryptographique, et elle 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 VC entre les systèmes back-end (émetteurs, wallets, vérificateurs).
• API Digital Credentials (API DC) : Une API de navigateur / système d'exploitation (JavaScript + plomberie native) qui permet à un site web de demander au wallet côté appareil de l'utilisateur de présenter n'importe quelle information d'identification numérique supportée (VC, ISO mDoc, SD-JWT…) d'une manière respectueuse de la vie privée.

Considérez les VC 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 de l'âge en ligne) :

1. Émission (API VC - émetteur ↔ wallet) : Le service des immatriculations de l'État émet une information d'identification vérifiable qui dit "Le détenteur a plus de 18 ans".
2. Stockage (App Wallet - OS) : L'information d'identification se trouve dans le wallet de l'utilisateur avec sa preuve cryptographique.
3. Requête (navigator.credentials.get() via l'API DC - site web → navigateur) : Le site web du magasin de bière demande : "Montrez-moi la preuve que l'utilisateur a ≥18 ans."
4. Présentation (l'API DC transmet au wallet → OpenID4VP (protocole) → charge utile VC) : Le wallet affiche une interface de consentement, l'utilisateur approuve, le wallet renvoie une présentation vérifiable.
5. Vérification (API VC - back-end du magasin 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 (et d'autres formats).
• Points de terminaison REST standard pour les systèmes back-end : Résolu par l'API VC.
• Poignée de main Wallet ↔ 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 identifiants à haute assurance ; W3C VC pour les affirmations générales) sous l'API DC.

Points clés à retenir :

1. "Information d'identification numérique" est le terme générique.
2. Une information d'identification vérifiable est un type d'information d'identification numérique avec une vérifiabilité cryptographique intégrée.
3. L'API VC est la plomberie serveur à serveur pour les opérations de cycle de vie sur les VC.
4. L'API Digital Credentials est le pont entre le navigateur et le wallet 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 informations d'identification 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 une norme web en cours de développement pour fournir un moyen sécurisé et standardisé pour les sites web de demander et de recevoir des informations d'identité numérique des wallets des utilisateurs. Cet effort est principalement hébergé au sein du groupe de travail sur l'identité fédérée du W3C (FedID WG), ayant migré du groupe communautaire FedID en avril 2025. Le projet de spécification officiel peut être trouvé ici : https://w3c-fedid.github.io/digital-credentials/.

En 2025, l'API est toujours décrite comme subissant des changements importants. Cela met en évidence sa phase de développement active. Malgré cela, son potentiel est significatif. Chrome a été le premier à livrer quelque chose de public, avec son Origin Trial, permettant aux développeurs d'expérimenter ses capacités. Chrome le supporte également nativement sur Android via son système Credential Manager et a récemment publié le support pour l'utilisation de l'API Digital Credentials Cross-Device sur ordinateur.

L'API étend l'API Credential Management existante en permettant les requêtes d'informations d'identification numériques via navigator.credentials.get(). Selon l'explainer de l'API 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 du navigator.identity précédemment proposé. Un site web demande une information d'identification numérique en appelant navigator.credentials.get() avec des paramètres spécifiques pour les informations d'identification numériques.

Voici un exemple illustratif de la manière dont un site web pourrait appeler l'API pour demander une information d'identification en utilisant 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 wallets 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'information d'identification et autoriser sa divulgation, 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 d'identification réelles 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 wallet/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 l'ISO 18013-5 et de son extension ISO 18013-7 "Annexe C") et les spécifications de la Fondation OpenID, OpenID for Verifiable Presentations (OpenID4VP) et OpenID for Verifiable Credential Issuance (OpenID4VCI).

• Origine et normalisation : 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), normalisés par l'Organisation internationale de normalisation (ISO) et la Commission électrotechnique internationale (CEI). La norme fondamentale est l'ISO/CEI 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. L'ISO/CEI 18013-7 étend cela pour permettre la présentation en ligne/à distance des mDL. La chaîne de protocole "org.iso.mdoc" est spécifiquement définie dans l'ISO/CEI 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 le 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 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 le portrait), le chiffrement de 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 exemple, contrôles routiers, vérification de l'âge pour les produits réglementés) et en ligne (par exemple, accès aux services gouvernementaux, vérification d'identité à distance pour l'ouverture d'un compte bancaire).

• Origine et normalisation : 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 d'informations d'identification vérifiables. Ce sont des normes ouvertes visant une large interopérabilité pour divers types d'informations d'identification, pas seulement celles du gouvernement. Début 2025, OpenID4VP est à un stade de projet avancé (par exemple, 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 (VC) W3C aux formats JSON/JSON-LD ou JWT, des mdocs, des SD-JWT et d'autres formats. Le modèle d'interaction implique une requête d'autorisation du vérificateur (RP) et une réponse du Wallet 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 exemple, diplômes universitaires, certifications professionnelles), les attestations d'adhésion, et plus encore. 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 ceux-ci 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'utilisation spécifique, du type d'information d'identification et des participants de l'écosystème.

Le Wallet 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 wallet numérique sécurisé pour les documents d'identité et les attestations. L'architecture et le cadre de référence du Wallet EUDI prévoient explicitement de prendre en charge à la fois le 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 pour OpenID4VP transférant des mDocs et OpenID4VCI pour l'émission de PID et de mDL aux formats mDoc et SD-JWT-VC. Ce double support par un projet d'une si grande 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 Wallet EUDI. Des préoccupations ont été soulevées quant à l'influence potentielle d'entités non-européennes sur un élément critique de l'infrastructure de l'UE, comme discuté dans des forums communautaires tels que cette discussion GitHub.

Le paysage des navigateurs pour l'API Digital Credentials est encore en train de se dessiner, avec des différences notables dans l'approche et les niveaux de support.

Google Chrome, en particulier sur Android, a été un adopteur et un implémenteur précoce de l'API Digital Credentials. Ils ont mené des Origin Trials et l'ont intégré au Credential Manager natif d'Android. L'implémentation de Chrome s'appuie principalement sur OpenID4VP comme protocole pour demander des informations d'identification via l'appel API navigator.credentials.get(). Bien qu'OpenID4VP soit lui-même agnostique au format et puisse transporter des org.iso.mdoc ou des Verifiable Credentials W3C comme charges utiles, l'accent pratique de Google semble être mis sur le flux OpenID4VP comme mécanisme de transport. Le Credential Manager d'Android prend également en charge nativement OpenID4VP pour la présentation et OpenID4VCI pour l'émission. Cela permet aux applications Android d'agir en tant que détenteurs et vérificateurs d'informations d'identification en utilisant ces normes.

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. Lors de la conférence, Apple a officiellement annoncé le support de l'API dans Safari 26 (livré avec iOS 26 et d'autres mises à jour d'OS à l'automne 2025), confirmant que leur implémentation supporte exclusivement le protocole org.iso.mdoc pour la présentation.

Cela a été détaillé dans la session de la 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 uniquement : L'API utilise exclusivement la chaîne de protocole "org-iso-mdoc", basée sur la norme ISO/CEI 18013-7 Annexe C. Il n'y a aucun support pour OpenID4VP dans l'implémentation de l'API Digital Credentials de Safari.
• Présentation uniquement : L'API est destinée à la présentation (vérification) des informations d'identification existantes. L'émission dans Apple Wallet ou d'autres applications reste un processus distinct, hors navigateur.
• Centré sur l'utilisateur et sécurisé : Le flux est initié par un geste de l'utilisateur et s'appuie sur 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 wallet, ce qui renforce 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.

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 la proposition de l'API Digital Credentials telle qu'elle est actuellement. Leurs préoccupations sont complètes et ancrées dans leur mission de protéger la vie privée des utilisateurs, leur autonomie, et d'assurer un web ouvert et équitable.

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

• Risques pour la vie privée : Potentiel de partage accru de données personnelles et réduction de l'anonymat en ligne si les demandes d'informations d'identification numériques deviennent monnaie courante pour des interactions triviales.
• Exclusion des utilisateurs : Risque que les personnes qui ne peuvent pas ou choisissent de ne pas utiliser d'informations d'identification numériques soient exclues des services et 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 menant à 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 compromis 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 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 prioriser les intérêts des utilisateurs. Bien qu'un Conseil du W3C ait rejeté une objection formelle liée à ces préoccupations (pour permettre au travail 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 des navigateurs pour l'API Digital Credentials et les protocoles

Pour les organisations (Relying Parties ou RP) qui ont l'intention de demander et de vérifier les informations d'identification numériques des utilisateurs, le paysage actuel nécessite une planification stratégique minutieuse.

Étant donné que Safari, avec sa part de marché significative, est susceptible de prioriser les interactions directes org.iso.mdoc via l'API Digital Credentials, et que Chrome/Android mettent l'accent sur OpenID4VP (qui peut transporter des mdocs ou d'autres formats de Verifiable Credential), les RP visant la portée la plus large possible devraient se préparer à supporter des interactions basées sur les deux approches.

Cela signifie concevoir des systèmes capables de :

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

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

Les Relying Parties doivent être parfaitement conscientes que même lorsqu'elles demandent la même information logique (par exemple, "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 wallet du détenteur ne révèle alors que les éléments demandés avec 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 presentation_definition de la requête. Cela permet aux RP de spécifier les types d'informations d'identification et les affirmations individuelles dont elles ont besoin. Le wallet 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 wallet.

Les RP doivent mapper leurs exigences de données spécifiques à ces structures de protocole variables. Il est crucial de comprendre les nuances de la mise en œuvre et de la demande de divulgation sélective 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 wallet peuvent également différer, nécessitant une logique d'analyse et de validation distincte sur le back-end du RP.

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

Les émetteurs de wallets font face à des paysages nettement différents sur iOS et Android en ce qui concerne la création de wallets, 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 alors participer aux flux de présentation d'informations d'identification médiés par le système, répondant aux requêtes de l'API Digital Credentials (via Chrome) ou des vérificateurs d'applications natives. Android prend également en charge explicitement OpenID4VCI pour l'émission d'informations d'identification, permettant aux utilisateurs de choisir un wallet tiers compatible pour recevoir les nouvelles informations d'identification émises. Bien que les applications natives soient l'objectif principal pour les 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 wallet 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 identifiants à haute assurance (comme les mDL 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 les org.iso.mdoc présentés à partir de sources autorisées, à savoir Apple Wallet lui-même et les applications tierces enregistrées de fournisseurs de documents.

L'approche du "jardin clos" d'Apple est bien établie, et leur implémentation des informations d'identification numériques ne fait pas exception. Cependant, la WWDC25 a clarifié la voie pour la participation de tiers.

Alors qu'Apple Wallet est le fournisseur principal et intégré pour les informations d'identification comme les mDL 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 des 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 wallet 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 PWA — 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 l'OS, 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écurisée, 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. À mesure que l'écosystème évolue, il est crucial pour les relying parties et les émetteurs de wallets de s'adapter et d'adopter le potentiel de cette nouvelle technologie. Nous maintiendrons cet article à jour au fur et à mesure que le paysage change.

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 wallets est une entreprise de taille. 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é. La fragmentation actuelle du support des navigateurs et de l'accent mis sur les protocoles signifie que les relying parties et les émetteurs de wallets doivent pour l'instant naviguer dans un paysage complexe.