Identifiants numériques et Passkeys : leurs points communs et leurs différences

• 🔑 Passkeys : pour des connexions sécurisées. Ils prouvent qui vous êtes (authentification) et luttent efficacement contre l'hameçonnage.
• 📄 Identifiants numériques : pour des preuves vérifiables. Ils prouvent des faits vous concernant (attestation, par exemple, votre identité, vos compétences), et vous contrôlez ce qui est partagé.
• 🤝 Leurs points communs : les deux utilisent une cryptographie forte pour une meilleure sécurité et une expérience utilisateur plus fluide par rapport aux mots de passe.
• 🎯 Leurs différences : les Passkeys servent principalement à accéder à des services. Les identifiants numériques servent à fournir des informations vérifiées sur vous-même.

Le paysage numérique évolue rapidement. Ce changement ne s'explique pas seulement par les défaillances répétées des mots de passe traditionnels et des secrets partagés, mais aussi parce que les attaques comme l'hameçonnage et les deepfakes générés par l'IA deviennent bien plus performantes et difficiles à repérer. Ces menaces avancées peuvent tromper même les utilisateurs les plus prudents et rendre les anciennes méthodes de vérification d'identité peu fiables. Cela montre clairement que la preuve cryptographique numérique est le seul moyen vraiment sûr de confirmer l'identité d'une personne. Dans ce contexte difficile, nous avons un besoin urgent de moyens plus sécurisés, conviviaux et cryptographiquement vérifiables pour interagir en ligne. Ce besoin a mis en avant deux technologies clés : les Passkeys, déjà largement utilisés, et les identifiants numériques, qui commencent tout juste à émerger. Ces technologies ne reposent pas sur des affirmations vérifiées par des humains – qui sont de plus en plus faciles à falsifier – mais utilisent plutôt une preuve cryptographique vérifiable par machine pour instaurer une confiance réelle.

L'utilisation des Passkeys a connu une forte croissance entre 2023 et 2025, grâce au soutien solide de grandes entreprises comme Apple, Google et Microsoft, ainsi que de la FIDO Alliance. Basés sur la norme robuste W3C WebAuthn, les Passkeys représentent un changement fondamental par rapport aux secrets partagés et vulnérables. Au lieu de mots de passe, ils utilisent la cryptographie à clé publique. Ici, une clé privée, stockée en toute sécurité sur l'appareil de l'utilisateur, signe les défis envoyés par la partie de confiance (RP). Cela prouve que l'utilisateur possède la clé sans la révéler.

Cette cryptographie rend les Passkeys très difficiles à hameçonner, un avantage majeur alors que les attaques d'hameçonnage deviennent plus sophistiquées, utilisant parfois des deepfakes pour paraître plus réelles. Comme un Passkey est lié au site web ou à l'application spécifique pour lequel il a été créé, les utilisateurs ne peuvent pas l'utiliser accidentellement sur de faux sites. C'est un problème courant avec les anciennes méthodes de connexion qui sont vulnérables à de telles astuces avancées. Les Passkeys empêchent également la réutilisation des mots de passe et les dangers du credential stuffing après des fuites de données. Au-delà de la sécurité, les Passkeys améliorent considérablement la connexion : elle est plus rapide, ne nécessitant souvent qu'une analyse biométrique (comme Face ID ou une empreinte digitale), de sorte que les utilisateurs n'ont pas à se souvenir ou à taper de longs mots de passe. Cette combinaison d'une sécurité renforcée et d'une grande facilité d'utilisation a rapidement favorisé leur popularité.

Parallèlement, les identifiants numériques, souvent conservés dans des Wallets d'identité numérique, ont fait l'objet de beaucoup plus d'attention. Le Wallet d'identité numérique de l'UE (EUDI Wallet) est un bon exemple de cette tendance.

Contrairement aux Passkeys, qui servent principalement à l'authentification (prouver qui vous êtes en montrant que vous contrôlez une clé privée), les identifiants numériques (basés sur des normes comme les Verifiable Credentials (VCs) du W3C ou les mdocs ISO) concernent l'attestation cryptographiquement vérifiable (prouver ce qui est vrai à votre sujet avec des affirmations signées numériquement). La capacité de vérifier solidement ces affirmations est importante, surtout maintenant que les deepfakes peuvent créer des contrefaçons convaincantes de preuves traditionnelles. Sans vérifications cryptographiques, même les experts peuvent avoir du mal à distinguer le vrai du faux. Ils permettent aux gens de transporter et de présenter numériquement des informations vérifiées – comme leur nom, leur date de naissance, leur permis de conduire, leurs diplômes ou leurs certificats professionnels – d'une manière qui est cryptographiquement sécurisée, respectueuse de la vie privée (en permettant aux utilisateurs de ne partager que le nécessaire) et vérifiable par des machines.

L'essor de ces deux technologies n'est pas une coïncidence. Il témoigne d'une évolution plus large de l'industrie, qui s'éloigne des systèmes d'identité centralisés basés sur les mots de passe pour adopter un modèle plus décentralisé, centré sur l'utilisateur et fondé sur la confiance cryptographique. Les mots de passe sont une faiblesse connue de la sécurité en ligne. Les anciennes méthodes de partage des détails d'identité sont souvent lourdes, peu sûres ou partagent trop de données, ce qui nuit à la confidentialité des utilisateurs. Les Passkeys corrigent directement la faiblesse de l'authentification. Les identifiants numériques gèrent le partage sécurisé d'attributs avec le contrôle de l'utilisateur. Les deux utilisent une cryptographie similaire et dépendent de plus en plus de l'intégration des plateformes et du matériel sécurisé, ce qui témoigne d'un effort commun pour améliorer considérablement nos systèmes d'identité numérique.

Alors que les Passkeys gèrent la « connexion » et les identifiants numériques la « preuve d'attributs », ils utilisent des bases cryptographiques similaires et jouent des rôles complémentaires dans la mise en place d'interactions numériques fiables. C'est quelque chose dont nous avons vraiment besoin, car les menaces actuelles comme l'hameçonnage sophistiqué et les deepfakes rendent les anciennes méthodes non cryptographiques de vérification d'identité peu sûres. Cela nous amène à la question principale : comment les Passkeys et les identifiants numériques se connectent-ils, et comment peuvent-ils fonctionner ensemble dans les situations quotidiennes des utilisateurs ?

Cet article explore cette synergie. Nous examinerons leurs différences et leurs similitudes, les protocoles qui les rendent possibles, leur dépendance commune au matériel sécurisé, et comment ils peuvent s'imbriquer dans des scénarios comme l'intégration des utilisateurs, la connexion avec authentification renforcée et la migration d'appareils. Nous aborderons également la manière dont les nouvelles normes de navigateur comme la Digital Credentials API visent à jeter un pont entre ces mondes. Cet article se concentre spécifiquement sur l'interaction entre ces technologies, en complément de l'exploration technique plus approfondie de la Digital Credentials API déjà disponible.

Pour comprendre comment les Passkeys et les identifiants numériques peuvent fonctionner ensemble, il est essentiel de saisir d'abord leurs caractéristiques distinctes et les couches technologiques qui les sous-tendent.

Le tableau suivant fournit une comparaison de haut niveau :

Cette comparaison met en évidence que, bien que les deux s'appuient sur la cryptographie pour la confiance, leurs fonctions principales et leurs schémas d'utilisation typiques diffèrent considérablement. Les Passkeys sont optimisés pour une authentification fréquente et sécurisée, tandis que les identifiants numériques excellent dans la fourniture d'attributs vérifiables avec le consentement de l'utilisateur.

Les Passkeys prennent vie grâce à l'interaction de plusieurs normes clés :

• WebAuthn (Web Authentication) : Cette norme du W3C définit l'API JavaScript que les applications web utilisent pour interagir avec les authentificateurs afin d'enregistrer (navigator.credentials.create()) et d'authentifier (navigator.credentials.get()) les Passkeys. Elle sert de pont entre l'application web de la partie de confiance et le navigateur ou le système d'exploitation de l'utilisateur. WebAuthn étend la Credential Management API générale du W3C.

• CTAP (Client to Authenticator Protocol) : Défini par la FIDO Alliance, le CTAP spécifie comment le client (navigateur ou SE) communique avec l'authentificateur. Il peut s'agir d'un authentificateur de plateforme intégré à l'appareil (utilisant du matériel sécurisé comme un TPM ou un Secure Enclave) ou d'un authentificateur itinérant comme une clé de sécurité USB ou même un téléphone agissant comme authentificateur pour un autre appareil. CTAP2 est la version alignée sur FIDO2 et les Passkeys, prenant en charge divers transports comme l'USB, le NFC et le Bluetooth Low Energy (BLE).

• Signaux de confiance avancés et liaison à l'appareil (considérations pour les Passkeys synchronisés) : À mesure que les Passkeys ont évolué pour devenir synchronisables entre les appareils (« identifiants multi-appareils »), les parties de confiance (RP) ont parfois eu besoin d'identifier l'appareil physique spécifique utilisé lors de l'authentification pour l'évaluation des risques. Les premières idées, comme les extensions devicePubKey et supplementalPubKeys, ont tenté de résoudre ce problème mais ont été abandonnées par la suite. Le groupe de travail sur les signaux de confiance de la FIDO Alliance développe maintenant des solutions de remplacement. L'idée principale ici est qu'un authentificateur avec un Passkey synchronisé pourrait également créer et utiliser une deuxième paire de clés liée à l'appareil. Lors de l'authentification, l'authentificateur pourrait alors fournir des signatures à la fois de la clé synchronisée principale et de cette deuxième clé liée à l'appareil. Cela permettrait aux RP de reconnaître un appareil de confiance spécifique. Cela pourrait signifier moins de friction (par exemple, sauter des défis supplémentaires) même si le Passkey principal est synchronisé sur de nombreux appareils, le tout sans perdre le principal avantage des Passkeys synchronisés : la facilité d'utilisation sur plusieurs appareils. Bien qu'il n'y ait pas encore de norme définitive pour cela, une telle fonctionnalité répondrait à un besoin clé pour les RP exigeant une haute assurance, leur permettant de mieux repérer l'utilisation d'un nouvel appareil ou de respecter les règles internes de l'authentification forte du client (SCA).

De même, l'écosystème des identifiants numériques repose sur un ensemble de protocoles et d'API émergentes pour fonctionner :

• Digital Credentials API : Il s'agit d'un effort de spécification émergent du W3C visant à étendre l'API navigator.credentials.get() pour permettre aux applications web de demander des Verifiable Credentials depuis le Wallet numérique d'un utilisateur de manière standardisée. Elle a un objectif similaire à WebAuthn mais se concentre sur les VCs au lieu des Passkeys.
• OpenID for Verifiable Presentations (OpenID4VP) : Ce protocole, construit sur OAuth 2.0, définit comment un vérificateur (la RP demandant des identifiants) peut demander des VCs au Wallet d'un détenteur. Les éléments clés incluent la presentation_definition (spécifiant les identifiants et les affirmations requis), le Wallet agissant comme un serveur d'autorisation, et le vp_token transportant la présentation vérifiable vers le vérificateur.
• OpenID for Verifiable Credential Issuance (OpenID4VCI) : En complément d'OpenID4VP, cette norme standardise la manière dont un émetteur délivre des VCs au Wallet d'un détenteur, en utilisant à nouveau les mécanismes OAuth 2.0. Elle implique des concepts tels que les offres d'identifiants, les flux de code pré-autorisés ou d'autorisation, et des points de terminaison d'identifiants dédiés.
• Normes ISO (par ex., ISO/IEC 18013-7, ISO/IEC 23220) : Ces normes internationales sont particulièrement importantes pour les permis de conduire mobiles (mDL) et d'autres types de documents mobiles (mdoc). La norme ISO 18013-5 définit la structure de données de base du mDL et la présentation hors ligne (NFC, BLE), tandis que les normes ISO 18013-7 et 23220 spécifient les mécanismes de présentation en ligne, y compris les API REST et les profils d'intégration avec OpenID4VP (Annexe B de la norme 18013-7). Des plateformes comme Google Wallet et Apple Wallet s'appuient sur ces normes ISO.

Malgré leurs objectifs et protocoles différents, les Passkeys et les identifiants numériques partagent des blocs de construction fondamentaux :

• Cryptographie asymétrique : Les deux reposent fortement sur des paires de clés publiques-privées. Les Passkeys utilisent la clé privée pour prouver la possession lors de l'authentification. Les identifiants numériques utilisent la clé privée de l'émetteur pour signer l'identifiant, garantissant son authenticité et son intégrité, et le détenteur peut utiliser sa clé privée pour signer une présentation contenant l'identifiant.
• Matériel sécurisé : La protection des clés privées est primordiale. Les deux technologies bénéficient énormément des composants matériels sécurisés intégrés dans les appareils modernes :
  • TPM (Trusted Platform Module) : Une puce dédiée que l'on trouve souvent dans les ordinateurs portables et de bureau, offrant une génération de clés, un stockage et des opérations cryptographiques sécurisés. Elle est couramment utilisée par les authentificateurs de plateforme comme Windows Hello.
  • Secure Enclave : Le gestionnaire de clés matériel d'Apple, isolé du processeur principal sur les iPhones, iPads et Macs, utilisé pour protéger les données sensibles, y compris les clés privées des Passkeys.
  • Système Android Keystore / StrongBox Keymaster : Android fournit un Keystore matériel, souvent mis en œuvre à l'aide d'un processeur sécurisé dédié (StrongBox Keymaster), offrant une protection solide pour les clés cryptographiques sur les appareils Android. Bien que certains gestionnaires de mots de passe utilisent le nom « Strongbox », l'élément matériel sécurisé sous-jacent fourni par le SE est le catalyseur clé ici.

L'utilisation des mêmes éléments matériels sécurisés (TPM, Secure Enclave, Keystore matériel d'Android) à la fois pour les opérations de Passkey et potentiellement pour sécuriser les clés privées dans les Wallets numériques crée une synergie significative. Les plateformes n'ont pas besoin de puces sécurisées distinctes pour chaque fonction. Au lieu de cela, elles peuvent utiliser une base matérielle unique et solide et les API du système d'exploitation associées (comme celles pour le Keystore d'Android ou le Secure Enclave d'Apple) pour protéger solidement à la fois les identifiants d'authentification (Passkeys) et les identifiants d'attestation (VCs). Cela facilite le développement, améliore la cohérence de la sécurité et utilise bien les investissements existants des plateformes.

De plus, l'API Credential Management du navigateur (navigator.credentials) est une couche d'organisation clé. D'abord étendue par WebAuthn pour les Passkeys, elle est maintenant étendue par la Digital Credentials API pour les VCs. Cela indique un plan clair : donner aux RP un moyen principal de demander différents identifiants, et donner aux utilisateurs un moyen familier de les choisir (comme via le gestionnaire d'identifiants d'Android ou les gestionnaires de mots de passe intégrés au navigateur). Cela masquerait les détails techniques complexes des protocoles comme CTAP, OID4VP et ISO, simplifiant les choses pour les développeurs et les utilisateurs.

Du point de vue d'une partie de confiance (RP), il est crucial de comprendre comment intégrer et exploiter efficacement les Passkeys et les identifiants numériques pour renforcer la sécurité, améliorer l'expérience utilisateur et répondre aux exigences réglementaires. Cette section analyse comment les RP peuvent déployer ces technologies dans différents scénarios et écosystèmes courants.

La stratégie d'intégration optimale pour les Passkeys et les identifiants numériques varie considérablement en fonction du cas d'utilisation spécifique, de son profil de risque et de ses exigences. Le tableau suivant fournit une comparaison de haut niveau entre les scénarios courants :

Comparaison des scénarios d'écosystème

Légende :

• Rôle du VC 🆔 : Décrit le rôle lors de l'interaction principale, reconnaissant que les VCs sont souvent utilisés pour l'intégration initiale/KYC dans tous les scénarios.
• Lien à l'appareil ? 🔗 : Fait référence à la nécessité d'une liaison explicite à l'appareil au-delà de la liaison d'origine standard des Passkeys, particulièrement pertinente pour les Passkeys synchronisés.
• Mandat EUDI Wallet UE* : Ce scénario reflète les exigences de la future réglementation eIDAS 2, qui devrait s'appliquer environ 36 mois après l'entrée en vigueur des actes d'exécution finaux (probablement fin des années 2020).

Cette comparaison donne un aperçu rapide ; les sections suivantes approfondissent les spécificités de chaque scénario du point de vue de l'intégration de la RP.

• Objectif : Accès rapide et à faible friction avec une bonne sécurité de base.
• Flux probable :
  • Authentification principale : Les Passkeys domineront. Leur résistance à l'hameçonnage et leur expérience utilisateur transparente (souvent juste une biométrie/PIN) les rendent idéaux pour remplacer les mots de passe dans les scénarios de connexion fréquents.
  • Rôle des identifiants numériques : Minimal pour la connexion de base. Les VCs pourraient être utilisés en option après la connexion pour des actions spécifiques comme la vérification de l'âge (par ex., achat de produits réglementés), la personnalisation basée sur des attributs vérifiés (par ex., statut de fidélité), ou pour compléter rapidement un profil lors de l'inscription initiale.
• Interaction : Le Passkey gère la connexion de base ; les VCs sont réservés aux interactions optionnelles basées sur des attributs.

• Objectif : Connexion à haute assurance et, si nécessaire, assertion d'identité vérifiée.
• Flux probable :
  • Les Passkeys comme 2FA/MFA autonomes : Les Passkeys remplissent intrinsèquement les exigences de l'authentification à deux facteurs lorsque la vérification de l'utilisateur (PIN/biométrie) a lieu pendant la cérémonie de connexion. Ils combinent :
    • Possession : Preuve du contrôle de la clé privée.
    • Connaissance/Inhérence : Vérification de l'utilisateur via PIN ou biométrie. Cela fait de la connexion par Passkey elle-même une méthode MFA forte et résistante à l'hameçonnage, suffisante pour de nombreux scénarios à haute assurance sans nécessiter une deuxième étape distincte uniquement pour atteindre le 2FA.
  • Renforcement pour la vérification d'identité (ponctuelle) : Le principal besoin d'une étape supplémentaire avec les identifiants numériques survient lorsque le service doit vérifier explicitement l'identité au-delà de la simple authentification d'un utilisateur connu. Ce type de vérification cryptographique forte est vital lorsque les deepfakes peuvent falsifier de manière convaincante des pièces d'identité visuelles ou documentaires. Seule une preuve cryptographique numérique provenant d'une source fiable peut alors confirmer un attribut de manière fiable. Cela peut être nécessaire :
    • Lors de l'intégration initiale.
    • Pour des actions spécifiques à haut risque nécessitant des attributs d'identité confirmés. Dans ces cas, la RP demande une présentation de Verifiable Credential spécifique (par ex., un PID, un identifiant national) depuis le Wallet de l'utilisateur après la connexion par Passkey.
  • Identité pour la récupération : Une fois l'identité d'un utilisateur fortement vérifiée (par ex., via une étape de renforcement par présentation de VC), ces informations d'identité vérifiées pourraient potentiellement être exploitées dans des flux de récupération de compte sécurisés. Par exemple, si un utilisateur perd tous ses authentificateurs de Passkey, la présentation d'un identifiant à haute assurance pourrait faire partie d'un processus pour retrouver l'accès et enregistrer de nouveaux Passkeys.
• Interaction : Les Passkeys fournissent une authentification 2FA/MFA robuste et autonome. Les VCs sont utilisés de manière stratégique pour une vérification d'identité explicite lorsque cela est nécessaire, et cette identité vérifiée peut également prendre en charge des mécanismes de récupération de compte sécurisés.

• Objectif : Paiement ou initiation de paiement simplifié et sécurisé, minimisant la friction pour l'utilisateur.
• Flux probable :
  • Authentification pour le paiement : Les Passkeys sont idéaux pour authentifier l'utilisateur auprès de son compte de fournisseur de services de paiement (PSP) (par ex., PayPal) ou directement dans le flux de paiement du marchand. Cela remplace les mots de passe et fournit une confirmation rapide et sécurisée pour initier le paiement.
  • Intégration/KYC : Les VCs restent cruciaux pendant la phase d'intégration ou de configuration du compte avec le PSP ou le marchand, fournissant des informations d'identité vérifiées (contrôles KYC/AML) nécessaires pour activer les capacités de paiement en premier lieu.
  • Préoccupations concernant la friction des transactions : L'introduction d'une étape de présentation de Verifiable Credential distincte pendant le flux d'autorisation de paiement principal (nécessitant une interaction avec un Wallet d'identité numérique) ajouterait une friction significative par rapport à une étape de confirmation par Passkey transparente. Cette perturbation de l'expérience utilisateur nuirait probablement aux taux de conversion et est donc inadaptée aux scénarios de paiement typiques à faible friction.
• Interaction : Le Passkey sécurise l'authentification pour l'acte de paiement lui-même. Les VCs gèrent la preuve d'identité/KYC nécessaire, souvent ponctuelle, requise pour établir le compte de paiement, mais sont tenus à l'écart de l'étape critique et sensible à la friction de la confirmation du paiement. (Le sujet complexe de l'utilisation des identifiants numériques directement comme instruments de paiement, y compris la manière dont différents types de Wallets et les API de navigateur émergentes pourraient permettre ou interagir avec de tels VCs spécifiques au paiement, est exploré en détail dans notre prochain article complémentaire : Identifiants numériques et paiement).

• Objectif : Sécuriser l'accès bancaire avec une réduction significative de la fraude, en particulier celle liée à l'hameçonnage, en passant à des méthodes d'authentification plus modernes.
• Flux probable :
  • Remplacement de l'AMF héritée : De nombreuses institutions financières s'appuient actuellement sur des mots de passe combinés à des seconds facteurs hameçonnables comme les OTP par SMS. Les Passkeys offrent une alternative bien supérieure, fournissant une authentification forte intrinsèquement résistante à l'hameçonnage en un seul geste de l'utilisateur.
  • Connexion principale avec les Passkeys : L'adoption des Passkeys pour la connexion principale améliore immédiatement la sécurité en raison de leur résistance à l'hameçonnage. La nature cryptographique des Passkeys atténue les vecteurs d'attaque les plus courants qui affectent les identifiants traditionnels.
  • Renforcement basé sur le risque - Examen attentif des signaux de l'appareil : Pour les opérations à plus haut risque (par ex., transferts importants, modification des coordonnées), les institutions financières peuvent envisager une vérification renforcée. Bien que les signaux de liaison à l'appareil associés aux Passkeys soient une option, leur nécessité doit être soigneusement évaluée. La résistance à l'hameçonnage de l'authentification principale par Passkey atténue déjà fortement de nombreux risques.
  • Sécurité basée sur les résultats et réduction de la fraude : La réduction significative du risque d'hameçonnage obtenue grâce aux Passkeys est un facteur critique. Une approche de la sécurité basée sur les résultats, axée sur la force et la résistance à l'hameçonnage de la méthode d'authentification, peut entraîner une réduction substantielle de la fraude. Le poids d'un facteur résistant à l'hameçonnage comme un Passkey est considérablement plus élevé que l'ajout de facteurs plus hameçonnables. Cela doit être au cœur de la stratégie d'une institution financière lors de la migration depuis d'anciennes méthodes.
  • VCs pour l'intégration/la preuve d'identité : Comme dans d'autres scénarios, les VCs restent essentiels pour un KYC/AML initial robuste et pour mettre à jour en toute sécurité les attributs d'identité des clients à l'aide d'informations vérifiées, établissant ainsi une base de confiance pour la relation bancaire.
• Interaction : Les Passkeys servent de méthode d'authentification principale puissante et résistante à l'hameçonnage, réduisant considérablement le risque de fraude des systèmes hérités. Les signaux de l'appareil pour le renforcement sont une option tactique. La force inhérente des Passkeys devrait éclairer une posture de sécurité basée sur les risques, réduisant potentiellement la dépendance excessive à des facteurs supplémentaires moins résistants à l'hameçonnage. Les VCs fournissent une assurance d'identité fondamentale.

• Objectif : Se conformer à la réglementation eIDAS 2 (Art 5f) exigeant l'acceptation du Wallet d'identité numérique de l'UE par des parties de confiance spécifiques (organismes publics, grandes entités privées dans les secteurs réglementés, VLOPs), permettant à la fois une connexion pseudonyme préservant la vie privée et une vérification d'identité/d'attributs à haute assurance lorsque la loi l'exige.
• Flux probable :
  • Connexion pseudonyme (par défaut) : L'utilisateur initie la connexion. La RP demande une authentification via l'EUDI Wallet. Le Wallet utilise sa « clé de pseudonyme » intégrée – une clé résidente WebAuthn liée au matériel, spécifique à la RP et stockée dans l'élément sécurisé certifié de l'appareil (WSCD) – pour authentifier l'utilisateur. Cela fournit une authentification forte et conforme à la SCA (possession + vérification de l'utilisateur) tout en gardant l'identité civile de l'utilisateur pseudonyme par défaut.
  • Renforcement pour l'identité/les attributs (légalement requis) : Si et seulement si la RP a une base légale spécifique en vertu du droit de l'Union ou national (par ex., PSD2, AML, enregistrement télécom) pour exiger une vérification d'identité ou des attributs spécifiques, elle initie une deuxième étape. La RP demande une présentation (via OpenID4VP) des données d'identification personnelle (PID) ou de l'attestation qualifiée d'attributs (QAA) nécessaires depuis le Wallet. L'utilisateur doit consentir explicitement au partage de ces données identifiées.
  • Authentification du Wallet et de la RP : Le flux implique une authentification mutuelle. La RP s'authentifie auprès du Wallet (sur la base de son enregistrement officiel), et le Wallet atteste de son authenticité et de la validité de l'identifiant auprès de la RP, en s'appuyant sur le matériel sécurisé (WSCD) et l'infrastructure de certification associée.
• Interaction : L'EUDI Wallet agit comme un authentificateur unifié. Son Passkey WebAuthn intégré (clé de pseudonyme) gère la connexion standard, offrant une authentification forte et respectueuse de la vie privée. Les capacités VC du Wallet sont invoquées sélectivement pour la divulgation explicite et légalement mandatée d'identité ou d'attributs, garantissant la minimisation des données par défaut.

Naviguer dans ce paysage en évolution nécessite une planification stratégique. Voici les principales considérations pour les parties de confiance (RP).

Pour les RP, la principale action aujourd'hui devrait être d'activer et d'encourager l'utilisation des Passkeys pour l'authentification. Les Passkeys sont standardisés, largement pris en charge par les plateformes et offrent des avantages immédiats et importants en matière de sécurité (résistance à l'hameçonnage) et d'expérience utilisateur (connexions plus rapides et plus faciles). Cela signifie moins de dépendance aux mots de passe et aux méthodes d'AMF non sécurisées comme les OTP par SMS. Cela peut également réduire les coûts de support liés aux réinitialisations de mot de passe et à la récupération de compte. Viser une large utilisation des Passkeys établit une base moderne et sécurisée pour l'authentification des utilisateurs. Bien que l'adoption puisse être lente au début, informer les utilisateurs des avantages au préalable et faciliter l'inscription peut les aider à démarrer.

Bien que les Passkeys eux-mêmes représentent une avancée significative vers une authentification robuste et puissent répondre aux exigences de l'authentification forte du client (SCA), certaines organisations peuvent avoir des cadres de conformité internes avec des interprétations encore plus strictes ou des préoccupations spécifiques, notamment concernant les Passkeys synchronisés. Pour les parties de confiance (RP) confrontées à de tels scénarios où les services de conformité recherchent des garanties supplémentaires, il est utile de savoir que des mesures additionnelles peuvent compléter les déploiements de Passkeys. Celles-ci peuvent aider à combler les lacunes perçues de la SCA ou à satisfaire ces exigences internes renforcées. Une stratégie courante consiste à exploiter les signaux de confiance de l'appareil, une approche adoptée par des services comme PayPal.

PayPal, par exemple, permet aux utilisateurs de marquer un appareil comme « mémorisé », comme décrit sur leur page d'aide :

Cela signifie que si un utilisateur se connecte avec son mot de passe (quelque chose qu'il connaît) depuis un appareil mémorisé (quelque chose qu'il possède), PayPal peut considérer cela comme suffisant pour la SCA dans de nombreux cas. Cependant, ils précisent également : « Il peut y avoir des cas où nous vous demandons tout de même une autre vérification pour nous assurer que votre compte est sécurisé. » Cela pourrait impliquer l'envoi d'un code à usage unique par SMS ou une demande de confirmation via l'application PayPal.

Cette approche permet une expérience utilisateur plus fluide sur les appareils de confiance tout en fournissant des mécanismes d'authentification renforcée lorsque les risques sont plus élevés ou que la réglementation l'exige. Les RP peuvent envisager des modèles similaires, où une combinaison d'authentification principale (comme un Passkey) et de confiance de l'appareil (potentiellement gérée en dehors des mécanismes directs de WebAuthn si nécessaire) peut aider à combler les lacunes de conformité SCA. Cependant, pour une approche plus intégrée et standardisée des signaux de confiance spécifiques à l'appareil au sein même du cadre WebAuthn, l'attention se tourne vers les développements en cours dans ce domaine.

Concernant ces approches intégrées à WebAuthn pour une confiance plus forte de l'appareil, les RP dans des environnements à haute sécurité devraient comprendre l'historique et l'orientation future. Les propositions d'extensions WebAuthn passées, comme devicePubKey et supplementalPubKeys, visaient à fournir ces signaux de confiance spécifiques à l'appareil. C'étaient des tentatives pour répondre aux considérations de sécurité des Passkeys synchronisés qui, tout en offrant une facilité d'utilisation cruciale pour l'adoption de masse, introduisent des profils de risque différents (par ex., dépendance à la récupération de compte cloud) par rapport aux clés liées à l'appareil. L'idée derrière de telles extensions était de permettre aux RP d'obtenir une couche d'assurance supplémentaire en vérifiant une signature d'une clé spécifiquement liée à l'appareil physique utilisé, même lorsque le Passkey principal lui-même est synchronisé.

Bien que ces extensions spécifiques (devicePubKey et supplementalPubKeys) aient été abandonnées, le défi d'obtenir des signaux de liaison à l'appareil plus forts pour les Passkeys synchronisés persiste. Les RP devraient donc surveiller le développement et la standardisation de solutions de suivi dans ce domaine. De telles solutions pourraient aider les RP à mieux évaluer le risque (par ex., distinguer une connexion depuis un appareil connu et de confiance d'une connexion depuis un appareil nouvellement synchronisé) sans forcer tous les utilisateurs à utiliser des Passkeys liés à l'appareil moins pratiques. Ce contexte présente aux RP un choix plus complexe que simplement « synchronisé vs. lié à l'appareil ». Les Passkeys synchronisés (généralement conformes à AAL2) offrent le plus de commodité et les meilleures chances d'adoption, ce qui est vital pour les applications grand public. Les Passkeys liés à l'appareil (potentiellement AAL3) offrent la plus haute assurance mais peuvent être plus difficiles à utiliser. L'objectif des extensions abandonnées était de trouver un juste milieu : améliorer la sécurité des clés synchronisées en ajoutant un signal de confiance spécifique à l'appareil. Cela pourrait aider à réduire certains risques si la synchronisation cloud est compromise, sans perdre toute la commodité de la synchronisation. Les RP devraient donc rechercher des solutions de suivi qui visent à atteindre cet objectif. La meilleure stratégie dépendra de la tolérance au risque spécifique d'une RP, de sa base d'utilisateurs et de la maturité des nouvelles normes.

Au-delà des mécanismes spécifiques au sein de WebAuthn pour la confiance de l'appareil, certaines parties de confiance (RP) — en particulier celles des secteurs comme la banque, l'assurance et les services de paiement — commencent à évaluer les identifiants numériques (Verifiable Credentials, ou VCs) comme un composant complémentaire, voire une prochaine étape, dans leurs stratégies d'identité et de sécurité.

Un facteur important qui motive cet intérêt est la liaison robuste à l'appareil souvent associée aux identifiants numériques, en particulier lorsqu'ils sont gérés dans des Wallets d'identité numérique sécurisés. Ces Wallets peuvent exploiter la sécurité matérielle (comme les Secure Enclaves ou les TPM) pour protéger les identifiants et les clés privées utilisées pour les présenter. Les émetteurs et les fournisseurs de Wallets peuvent également appliquer des politiques qui rendent certains identifiants de grande valeur intrinsèquement liés à l'appareil, offrant un niveau de contrôle attrayant pour les scénarios à haute assurance.

Il est crucial de reconnaître que si cette capacité de liaison renforcée à l'appareil est une caractéristique convaincante pour ces RP, l'objectif principal des identifiants numériques (attestation d'attributs et d'affirmations) est distinct de celui des Passkeys (authentification de l'utilisateur). Les Passkeys confirment qui est l'utilisateur, tandis que les identifiants numériques confirment ce qui est vrai à propos de l'utilisateur. Malgré cette différence fondamentale d'objectif, les solides caractéristiques de sécurité des VCs détenus dans un Wallet en font un domaine de considération active pour les RP cherchant à superposer des assurances supplémentaires. Cela conduit naturellement la discussion vers les fournisseurs de ces Wallets d'identité numérique et l'écosystème qui permet l'émission, le stockage et la présentation de tels identifiants.

Alors que les Passkeys offrent une authentification directe, les identifiants numériques (VCs) sont gérés et présentés aux parties de confiance par le biais de Wallets d'identité numérique. Ces Wallets, qu'il s'agisse de solutions de plateforme natives (comme Apple Wallet, Google Wallet) ou d'applications tierces (comme l'EUDI Wallet), évoluent pour utiliser les normes de navigateur émergentes comme la Digital Credentials API pour une vérification d'identité en ligne plus fluide (par ex., vérification de l'âge, partage d'attributs d'identité numérique).

Les mécanismes détaillés des différents types de Wallets, les stratégies spécifiques des plateformes pour l'intégration des VCs (y compris l'accent mis par Apple sur les mDoc pour les interactions de navigateur par rapport au support plus large d'OpenID4VP par Android via son Credential Manager), la manière dont ces Wallets facilitent l'attestation d'attributs, et les considérations entièrement distinctes pour toute fonctionnalité de paiement sont des sujets complexes. Ceux-ci sont explorés en profondeur dans notre prochain article complémentaire : Identifiants numériques et paiements.

Cet article actuel maintient son focus sur l'interaction fondamentale entre les Passkeys pour l'authentification et le rôle général des identifiants numériques pour l'attestation d'attributs.

Les Passkeys et les identifiants numériques, bien que différents dans leur objectif principal, représentent deux piliers d'un avenir de l'identité numérique moderne, plus sécurisé et centré sur l'utilisateur. Comprendre comment ils sont liés et peuvent se soutenir mutuellement est essentiel pour construire la prochaine vague de services en ligne.

Sur la base de l'état actuel et de la trajectoire de ces technologies, deux actions clés se distinguent pour les parties de confiance :

• Déployez les Passkeys partout dès aujourd'hui : les normes sont matures, le support des plateformes est répandu, et les avantages par rapport aux mots de passe sont clairs et substantiels. Faites des Passkeys la cible par défaut pour l'authentification des utilisateurs afin d'améliorer immédiatement la sécurité et la convivialité.
• Ajoutez une étape de renforcement par Wallet lorsque l'AML/KYC est important : pour les processus nécessitant une assurance plus élevée ou des attributs vérifiés spécifiques – comme le respect des réglementations anti-blanchiment d'argent (AML) / connaissance du client (KYC), la réalisation d'une vérification d'âge fiable ou la confirmation de qualifications professionnelles – intégrez des flux de présentation de Verifiable Credential pour obtenir des attributs cryptographiquement vérifiables, qui sont indispensables pour faire confiance à l'identité et aux affirmations à une époque de contrefaçons numériques sophistiquées et de deepfakes. Utilisez la Digital Credentials API lorsque c'est possible, mais mettez en œuvre des solutions de repli robustes par QR/lien profond pour garantir une portée multiplateforme jusqu'à ce que l'API se stabilise. Cela fournit une haute assurance ciblée sans alourdir chaque connexion.

À l'avenir, nous pouvons nous attendre à plus de convergence et d'améliorations :

• Portabilité améliorée des identifiants : les méthodes de transfert d'appareil à appareil vont probablement s'améliorer. Cela pourrait aller au-delà de l'authentification inter-appareils CTAP 2.2 pour les Passkeys pour inclure des moyens plus fluides de déplacer les VCs entre les Wallets, bien que la standardisation ici ne soit pas aussi avancée.
• API de navigateur consolidées : la Digital Credentials API va probablement mûrir et être prise en charge de manière plus cohérente par les navigateurs. Cela offrira aux RP un moyen plus standard de demander à la fois des Passkeys et des VCs via navigator.credentials.
• Expérience utilisateur unifiée : en fin de compte, les utilisateurs devraient voir moins de différence technique entre s'authentifier avec un Passkey et présenter des attributs avec un VC. Les gestionnaires d'identifiants de plateforme et les Wallets géreront probablement ces interactions en toute transparence en coulisses. Ils utiliseront des outils cryptographiques partagés et du matériel sécurisé, permettant aux utilisateurs d'approuver simplement les demandes avec des invites biométriques ou PIN familières, peu importe si un Passkey ou un VC est utilisé. De plus, des concepts comme l'authentification passive continue (CPA), qui vérifie constamment les utilisateurs en arrière-plan à l'aide de la biométrie comportementale et d'autres signaux, pourraient encore améliorer cette sécurité transparente, en travaillant potentiellement aux côtés d'authentificateurs actifs comme les Passkeys.

Atteindre cet avenir intégré nécessitera plus de travail sur les normes, la manière dont les plateformes les prennent en charge et la façon dont les applications les utilisent. En utilisant les Passkeys dès maintenant et en ajoutant judicieusement les identifiants numériques, les organisations peuvent se préparer à cette transition vers un monde numérique sans mot de passe qui donne aux utilisateurs plus de contrôle sur leurs données.