Decentralized identity: W3C VC, ISO mDL and OpenID4VC compared

« Faut-il partir sur les W3C VC, l’ISO mDL ou OpenID4VC ? » La question revient dans presque tous les projets d’identité numérique, et elle est mal posée. Ces trois standards d’identité décentralisée ne se situent pas au même niveau : deux décrivent la forme d’une attestation, le troisième la façon de la délivrer et de la présenter. Un projet sérieux en combine en général plusieurs. Ce comparatif les situe, puis les confronte sur les mêmes critères, à l’état des spécifications en octobre 2025.

Un modèle commun, trois niveaux

Tous partagent le même schéma. Un émetteur (un ministère, une université, une préfecture) délivre une attestation signée. Le détenteur la conserve dans un portefeuille, sur son téléphone. Il la présente à un vérificateur (une banque, un service public, un agent de contrôle), qui contrôle la signature de l’émetteur, et peut ne recevoir que les données strictement nécessaires.

Les trois familles en bref

W3C Verifiable Credentials. Le W3C définit un modèle de données pour les attestations vérifiables, dont la version 2.0 a été publiée comme recommandation au printemps 2025. Les attestations s’expriment en JSON, avec un vocabulaire extensible, et peuvent être sécurisées de plusieurs manières. Le modèle s’accompagne souvent des identifiants décentralisés (DID), autre recommandation du W3C depuis 2022, mais ne les impose pas. Il est très général : diplômes, qualifications, adhésions, attestations professionnelles. Les attestations européennes d’apprentissage (Europass) s’appuient sur ce modèle.

ISO/IEC 18013-5, le permis de conduire mobile (mDL). Publiée en 2021, la norme définit à la fois un format d’attestation, appelé mdoc, encodé en CBOR, et un protocole de présentation en proximité, par NFC, Bluetooth ou code QR. Elle a été conçue pour le permis de conduire, mais le format mdoc sert à d’autres attestations. La divulgation sélective est native : l’émetteur signe des empreintes de chaque donnée, et le détenteur ne révèle que celles demandées. La confiance repose sur une infrastructure à clés publiques classique, par autorité émettrice. La spécification 18013-7 ajoute la présentation en ligne.

OpenID for Verifiable Credentials (OpenID4VC). L’OpenID Foundation publie une famille de protocoles qui appliquent les mécanismes éprouvés d’OAuth 2.0 et d’OpenID à l’émission (OpenID4VCI) et à la présentation (OpenID4VP) d’attestations. Ces protocoles ne définissent pas de format : ils transportent des attestations mdoc, W3C VC ou SD-JWT VC, un format fondé sur les jetons JWT et la divulgation sélective, normalisé à l’IETF. Leur intérêt principal est de s’appuyer sur des briques que les équipes de développement connaissent déjà.

Comparaison sur les mêmes critères

Maturité et adoption à l’automne 2025

Les trois familles n’en sont pas au même stade, et la maturité d’une spécification ne dit pas tout de celle de son écosystème.

L’ISO mDL est la plus éprouvée en conditions réelles. Plusieurs États américains délivrent des permis de conduire mobiles conformes à la norme, que certains contrôles, notamment dans des aéroports, acceptent déjà. Les grands systèmes d’exploitation mobiles ont intégré la prise en charge de ces titres dans leurs portefeuilles natifs, dans les juridictions qui l’ont autorisée. Sa limite tient à son origine : pensée pour la présentation en face à face, elle a dû être complétée pour les usages en ligne, et ces compléments sont plus récents.

Le modèle du W3C a gagné en stabilité avec la publication de sa version 2.0, accompagnée de spécifications de sécurisation et de gestion des statuts. Il est largement utilisé dans l’éducation, la formation et certains secteurs professionnels. Sa souplesse est aussi sa difficulté : deux implémentations conformes au modèle peuvent ne pas se comprendre si elles n’ont pas choisi les mêmes options de sécurisation, de vocabulaire et de révocation. L’interopérabilité suppose donc de s’accorder sur un profil.

OpenID4VC a franchi une étape importante en 2025 avec la stabilisation de ses spécifications principales, et bénéficie de l’élan du portefeuille européen, qui l’a retenu. Des profils d’interopérabilité, publiés par l’OpenID Foundation et par les projets pilotes européens, précisent les options à retenir pour que portefeuilles et vérificateurs se comprennent. Pour une équipe de développement, c’est souvent la famille la plus accessible, car elle réutilise des mécanismes d’OAuth qu’elle pratique déjà.

Dans les trois cas, la disponibilité de bibliothèques logicielles ouvertes, de suites de tests de conformité et d’événements d’interopérabilité compte autant que la spécification elle-même. Avant de s’engager, il est utile de vérifier qu’au moins deux implémentations indépendantes ont démontré leur capacité à échanger avec la combinaison envisagée.

Ce que fait le portefeuille européen

Le cadre d’architecture et de référence du portefeuille européen d’identité numérique, publié par la Commission dans le cadre d’eIDAS 2, illustre la logique de combinaison. Les données d’identité et les attestations y sont prévues dans deux formats, mdoc et SD-JWT VC. L’émission et la présentation en ligne s’appuient sur OpenID4VCI et OpenID4VP ; la présentation en proximité, sur l’ISO 18013-5. La confiance repose sur des listes de confiance tenues par les États membres. Pour un organisme qui devra accepter ces portefeuilles d’ici fin 2026, ce choix de fait vaut orientation, comme le détaille notre article ce qu’il faut préparer pour le portefeuille européen.

Les vraies questions de choix

Le format compte moins, au final, que quatre questions que tous les standards laissent en partie ouvertes.

Sur la révocation, les approches convergent vers des listes de statut publiées par l’émetteur sous forme compacte : le vérificateur télécharge une liste couvrant un grand nombre d’attestations et y lit le statut de celle qu’il contrôle, sans révéler à l’émetteur laquelle. Le W3C et l’IETF ont chacun spécifié un mécanisme de ce type. Sur la non-traçabilité, la parade la plus répandue consiste à délivrer au détenteur un lot d’attestations identiques, chacune signée différemment, et à en utiliser une nouvelle à chaque présentation. Les signatures cryptographiques qui permettent des présentations non corrélables par construction existent, mais leur normalisation et leur prise en charge par les composants de sécurité des téléphones restent en cours.

Ces choix ont des conséquences concrètes sur l’architecture : taille et fréquence de publication des listes de statut, gestion des lots d’attestations dans le portefeuille, capacité des vérificateurs à travailler hors connexion. Ils méritent d’être tranchés avant le choix d’un fournisseur, pas après.

Selon le contexte, l’orientation diffère. Un État qui délivre un permis de conduire contrôlé sur le terrain par des agents a intérêt à l’ISO mDL. Un service en ligne qui devra accepter les portefeuilles européens doit savoir parler OpenID4VP et lire mdoc et SD-JWT VC. Un réseau d’universités ou un ordre professionnel qui délivre des attestations variées trouvera dans le modèle du W3C la souplesse nécessaire, à condition de choisir un mécanisme de divulgation sélective et de révocation compatible avec ses partenaires. Pour un pays hors de l’Union qui construit son propre cadre, s’aligner sur les choix européens facilite la reconnaissance mutuelle future, sans obliger à tout reprendre.

Dans tous les cas, une attestation ne vaut que par le registre qui l’alimente. Notre produit État civil part de cette source, et notre dossier de référence sur l’identité numérique replace ces standards dans une stratégie d’ensemble.

1. W3C, Verifiable Credentials Data Model v2.0, recommandation, 2025 ; Decentralized Identifiers (DID) v1.0, recommandation, 2022.
2. ISO/IEC 18013-5:2021, Permis de conduire conforme à l’ISO, application de permis de conduire mobile (mDL) ; ISO/IEC TS 18013-7, présentation en ligne.
3. OpenID Foundation, OpenID for Verifiable Credential Issuance et OpenID for Verifiable Presentations.
4. IETF, SD-JWT et SD-JWT-based Verifiable Credentials (SD-JWT VC), groupe de travail OAuth.
5. Commission européenne, European Digital Identity Wallet Architecture and Reference Framework.

Questions fréquentes

Qu'est-ce que l'identité décentralisée ?

C'est un modèle dans lequel une autorité délivre à une personne une attestation numérique signée (identité, diplôme, permis, qualité), que la personne conserve dans un portefeuille et présente elle-même à qui en a besoin. Le vérificateur contrôle la signature de l'émetteur sans avoir à l'interroger à chaque fois. Le terme « décentralisé » désigne cette absence d'intermédiaire systématique, pas nécessairement l'usage d'une chaîne de blocs.

Faut-il choisir entre W3C VC et ISO mDL ?

Pas toujours. Les deux décrivent des formats d'attestation, adaptés à des usages différents : l'ISO mDL est pensé pour le permis de conduire et les présentations en proximité, le modèle du W3C pour des attestations variées et des écosystèmes ouverts. Un portefeuille peut gérer plusieurs formats, comme le prévoit le cadre européen.

OpenID4VC remplace-t-il OpenID Connect ?

Non. OpenID Connect permet à un service de s'appuyer sur un fournisseur d'identité qui confirme l'identité de l'usager en temps réel. OpenID4VC applique les mécanismes d'OAuth et d'OpenID à l'émission et à la présentation d'attestations conservées dans un portefeuille. Les deux coexistent, et de nombreux services proposeront les deux pendant longtemps.

L'identité décentralisée utilise-t-elle une chaîne de blocs ?

Pas nécessairement. Les identifiants décentralisés du W3C peuvent s'appuyer sur un registre distribué, mais aussi sur un simple nom de domaine. L'ISO mDL et le portefeuille européen reposent principalement sur des infrastructures à clés publiques classiques et des listes de confiance.