Comment fonctionne la vérification eIDAS : analyse technique approfondie

Rectifié le 20 octobre 2026 : une version antérieure de cet article affirmait que le PID du portefeuille EUDI peut divulguer un attribut age_over_18. C'est faux — le PID ne contient aucun attribut d'âge : le vérificateur demande uniquement la date de naissance et en déduit lui-même le oui/non. age_over_18 n'existe que dans l'attestation de preuve d'âge, distincte du PID (eu.europa.ec.av.1). Nous ne présentons plus non plus ID Austria, Smart-ID et BankID comme des portefeuilles EUDI (ce sont des applications d'eID nationales existantes), et nous avons précisé que le vérificateur contrôle la signature du fournisseur de PID au regard des listes de confiance, sans interroger un système public pendant la vérification.

Vue d'ensemble du flux de vérification

La vérification d'identité fondée sur eIDAS suit une séquence soigneusement orchestrée, conçue pour équilibrer sécurité, protection de la vie privée et expérience utilisateur. Comprendre ce flux est essentiel pour les développeurs qui intègrent la vérification d'identité dans leurs applications.

Le processus complet de vérification implique quatre acteurs principaux :

Partie utilisatrice (votre application) : le service qui demande la vérification d'identité
Fournisseur de services eIDAS : le middleware qui relie votre application au réseau eIDAS
Portefeuille EUDI : l'application de portefeuille de l'utilisateur, fournie dans le cadre du schéma de son État membre
Fournisseur de PID : l'organisme désigné par l'État membre qui délivre les données d'identification personnelle au portefeuille et dont les certificats de signature sont publiés via les listes de confiance

Parcourons chaque étape de ce processus en détail.

Étape 1 : initialisation de la session de vérification

Lorsque votre application doit vérifier l'identité d'un utilisateur, le processus commence par la création d'une session de vérification.

Requête de création de session

Votre application effectue un appel API vers votre fournisseur de services eIDAS :

POST /api/verification/create
{
  "verificationType": "AGE",
  "purpose": "Age verification for purchase",
  "returnUrl": "https://yourapp.com/verification/callback"
}

Le champ verificationType précise la question à laquelle vous avez besoin d'une réponse. eIDAS Pro se concentre sur des résultats booléens : vous recevez des réponses true/false, pas de données personnelles.

Vérification d'âge (AGE) :

À partir d'un PID, le portefeuille divulgue uniquement la date de naissance (le PID ne comporte pas d'attribut age_over_18) ; le vérificateur calcule « 18 ans ou plus ? » et ne conserve que le oui/non
À partir d'une attestation de preuve d'âge (eu.europa.ec.av.1), le portefeuille divulgue directement age_over_18, sans aucune date de naissance

Vérification du pays (COUNTRY) :

Le pays de résidence de l'utilisateur figure-t-il sur votre liste autorisée ? (le pays de résidence est un attribut facultatif du PID : tous les PID ne permettent donc pas d'y répondre)

Pourquoi des résultats booléens ?

Cette approche offre une confidentialité maximale avec une exposition RGPD minimale :

Vous n'obtenez que l'information strictement nécessaire (oui/non)
Aucun nom, date de naissance ou adresse à stocker et à sécuriser
Aucun traitement de données de catégorie particulière
Une responsabilité en cas de fuite fortement réduite

Note de confidentialité : eIDAS Pro limite volontairement ce qu'il renvoie à des réponses booléennes ; la date de naissance lue dans un PID n'est jamais renvoyée, stockée ni journalisée. Si vous avez besoin de données d'identité complètes (noms, adresses), il faudra recourir à des approches de vérification documentaire, avec les obligations RGPD et les coûts associés. De nombreuses organisations utilisent eIDAS pour des cas d'usage européens à données minimales, et la vérification documentaire pour les scénarios qui exigent des données d'identité complètes.

Note sur le rôle de responsable de traitement : même si eIDAS minimise la collecte de données, votre organisation reste responsable de traitement pour tous les résultats de vérification que vous stockez. Consultez notre guide de conformité RGPD pour connaître vos obligations restantes.

Réponse de session

Le fournisseur de services génère une session de vérification unique et renvoie :

{
  "sessionId": "vs_a8f2b3c1...",
  "qrCodeData": "eidas://verify?session=vs_a8f2b3c1...",
  "deepLink": "at.gv.eid://verify?session=vs_a8f2b3c1...",
  "expiresAt": "2026-01-22T15:30:00Z",
  "statusUrl": "https://api.provider.com/verification/vs_a8f2b3c1/status"
}

La session expire généralement au bout de 5 à 10 minutes afin d'éviter les requêtes de vérification obsolètes.

Étape 2 : génération et affichage du QR code

Le QR code sert de passerelle entre votre application web et l'appareil mobile de l'utilisateur.

Contenu du QR code

Le QR code encode plusieurs informations critiques :

Gestionnaire de protocole : eidas:// ou des schémas spécifiques à un pays comme at.gv.eid://
Identifiant de session : relie cette vérification à votre session backend
Point de terminaison du fournisseur de services : l'adresse à laquelle le portefeuille doit envoyer la requête de vérification
Attributs demandés : les informations à vérifier

Standards modernes : OpenID4VP

Les implémentations eIDAS modernes utilisent OpenID for Verifiable Presentations (OpenID4VP), qui standardise la manière de demander et de présenter des justificatifs vérifiables. Le QR code contient :

openid4vp://?
  client_id=https://yourprovider.com
  &request_uri=https://yourprovider.com/request/vs_a8f2b3c1

Le request_uri pointe vers un JWT signé contenant la requête de vérification complète, ce qui garantit l'intégrité et empêche toute altération.

Bonnes pratiques d'affichage

Design adaptatif : sur mobile, affichez un bouton "appuyer pour ouvrir" au lieu d'un QR code, en utilisant des liens profonds pour lancer directement l'application portefeuille appropriée.

États de chargement : affichez une animation de scan et des instructions claires ("Scannez avec votre application eID nationale").

Options de secours : proposez des méthodes de vérification alternatives pour les utilisateurs sans portefeuille eID.

Étape 3 : authentification dans l'application portefeuille

Une fois le QR code scanné, l'application portefeuille eID nationale de l'utilisateur prend le relais.

Validation de la requête

L'application portefeuille :

Récupère la requête complète : télécharge la requête signée depuis le request_uri
Valide les signatures : s'assure que la requête provient d'un fournisseur légitime
Vérifie la portée : confirme que les attributs demandés sont appropriés et légaux
Affiche l'écran de consentement : montre à l'utilisateur exactement quelles informations seront partagées

Authentification utilisateur

Avant de transmettre la moindre information, le portefeuille exige une authentification forte. Les méthodes varient selon les pays, mais incluent généralement :

Authentification biométrique (la plus courante) :

Empreinte digitale
Reconnaissance faciale
Scan de l'iris

PIN/mot de passe : un code PIN numérique ou un mot de passe alphanumérique

Sécurité matérielle : de nombreux portefeuilles eID nationaux utilisent des éléments sécurisés (SE) ou des environnements d'exécution de confiance (TEE) sur l'appareil, ce qui garantit que les clés cryptographiques ne quittent jamais l'enclave sécurisée.

Exemple : flux dans le portefeuille

L'utilisateur ouvre son application de portefeuille EUDI en scannant le QR code
L'application affiche : "eidas-pro.com demande : date de naissance (pour une vérification d'âge)"
L'utilisateur vérifie puis appuie sur "Approuver"
Invite biométrique : "Utilisez votre empreinte pour confirmer"
L'utilisateur s'authentifie avec son empreinte
L'application génère et signe la réponse de vérification

L'ensemble du flux in-app prend 3 à 5 secondes pour les utilisateurs récurrents.

Étape 4 : échange et validation des attributs

Après l'authentification utilisateur, le portefeuille prépare une réponse signée cryptographiquement contenant les attributs demandés.

Structure de la réponse

Le portefeuille génère une présentation vérifiable (Verifiable Presentation) en SD-JWT VC (Selective Disclosure JWT Verifiable Credentials), le format réellement utilisé par le portefeuille d'identité numérique de l'UE :

// SD-JWT VC (PID, vct urn:eudi:pid:1) with selective disclosure - only revealing birthdate
eyJhbGciOiJFUzI1NiIsInR5cCI6ImRjK3NkLWp3dCJ9.
eyJpc3MiOiJodHRwczovL2lzc3Vlci5laWRhcy5ldSIsImlhdCI6MTY0MzI4NDgwMCwiZXhwIjoxNjQzMjg4NDAwLCJ2Y3QiOiJ1cm46ZXVkaTpwaWQ6MSIsInN1YiI6ImRpZDpqd2s6ZXlKdUlqb2lSRk5CSWl3aWVTSTZJalkzTnpZeE1qRTJNeUo5IiwiX3NkIjpbIkc1RW5oT0FPb1U5WF84UUFBQUFBQUFBQUFBIiwiSjZVVnJPbkFBQUFBQUFBQUFBQUFBQUEiXSwiX3NkX2FsZyI6InNoYS0yNTYifQ.
kLJkC5RhcvkKU-VU8-U5Ng7Iq4r8KxP9I_gKU8U8U8U8U

// Disclosures array (only birthdate disclosed, other attributes hidden)
~WyJhQUFBQUFBQSIsImJpcnRoZGF0ZSIsIjE5OTAtMDUtMTQiXQ

// Key Binding JWT (proves holder controls the wallet)
eyJhbGciOiJFUzI1NiIsInR5cCI6ImtiK2p3dCJ9.
eyJub25jZSI6IjEyMzQ1Njc4OTAiLCJhdWQiOiJodHRwczovL3ZlcmlmaWVyLmNvbSIsImlhdCI6MTY0MzI4NDgwMCwic2RfaGFzaCI6ImtoMlA1LVl0QmQzSnVIbVFQQUFBQUFBIn0.
signature_proving_holder_possession

Note sur la divulgation sélective : l'exemple ci-dessus utilise SD-JWT VC (Selective Disclosure JSON Web Token Verifiable Credential), qui est le standard actuel imposé par les actes d'exécution eIDAS 2.0. Même si les preuves à divulgation nulle de connaissance (ZKP) sont étudiées pour de futures améliorations de confidentialité, l'implémentation actuelle du portefeuille EUDI utilise la divulgation sélective via les formats SD-JWT VC et mdoc. Avec un PID, la vérification d'âge fonctionne en divulguant uniquement la déclaration birthdate, que le vérificateur réduit à un oui/non ; le PID ne possède pas d'attribut age_over_18. Un age_over_18 sans date de naissance n'existe que dans l'attestation de preuve d'âge, distincte du PID (eu.europa.ec.av.1).

Composants clés de SD-JWT VC :

Header + payload : contient l'émetteur, la date d'émission et des déclarations divulguables de manière sélective (hachées)
Éléments divulgués (disclosures) : uniquement les attributs que l'utilisateur choisit de révéler (dans ce cas, birthdate)
Key binding : preuve cryptographique que la personne qui présente le justificatif contrôle bien le portefeuille

Bénéfice de confidentialité : le vérificateur apprend UNIQUEMENT la date de naissance, dont il a besoin une seule fois pour calculer le résultat 18+. Les autres attributs comme le nom, l'adresse et la nationalité restent cryptographiquement masqués, et eIDAS Pro réduit la date à un oui/non avant tout stockage.

Validation cryptographique

Votre fournisseur de services valide :

Vérification de signature : confirme que la réponse est signée par le fournisseur d'identité national légitime
Chaîne de certificats : valide toute la chaîne de confiance jusqu'à l'autorité de certification racine nationale
Statut de révocation : vérifie que le certificat de signature n'a pas été révoqué
Validation temporelle : garantit que la réponse est récente et n'a pas été rejouée

Cette validation se fait en quelques millisecondes grâce à des clés publiques pré-cachées et à des listes de révocation de certificats.

Extraction des attributs

Une fois validés, les attributs spécifiques sont extraits et renvoyés à votre application :

{
  "status": "success",
  "sessionId": "vs_a8f2b3c1...",
  "result": {
    "ageVerified": true  // derived from the birth date, which is not returned
  },
  "verifiedAt": "2026-01-22T12:00:05Z",
  "providerId": "AT",  // Austria
  "assuranceLevel": "high"  // eIDAS assurance level
}

Étape 5 : mises à jour de statut en temps réel

Pendant que l'utilisateur s'authentifie sur son appareil mobile, votre application web doit savoir quand le processus est terminé.

Server-Sent Events (SSE)

La solution la plus élégante consiste à utiliser les Server-Sent Events pour des mises à jour en temps réel :

const eventSource = new EventSource(
  `https://api.provider.com/verification/${sessionId}/stream`
);

eventSource.addEventListener('status', (event) => {
  const data = JSON.parse(event.data);

  if (data.status === 'scanned') {
    // L'utilisateur a scanné le QR code
    showMessage('En attente d\'authentification...');
  } else if (data.status === 'completed') {
    // Vérification réussie
    redirectToSuccessPage();
  } else if (data.status === 'failed') {
    // Échec de la vérification
    showError(data.reason);
  }
});

Alternative par polling

Pour les environnements qui ne prennent pas en charge SSE, implémentez un polling avec backoff exponentiel :

async function pollStatus(sessionId) {
  const maxAttempts = 60;  // 5 minutes
  let attempts = 0;

  while (attempts < maxAttempts) {
    const response = await fetch(
      `https://api.provider.com/verification/${sessionId}/status`
    );
    const data = await response.json();

    if (data.status !== 'pending') {
      return data;
    }

    // Backoff exponentiel : 1s, 2s, 4s, 8s, puis 10s
    const delay = Math.min(1000 * Math.pow(2, attempts), 10000);
    await sleep(delay);
    attempts++;
  }

  throw new Error('Délai de vérification dépassé');
}

Protocoles de sécurité et chiffrement

eIDAS utilise plusieurs couches de sécurité pour se protéger contre différents vecteurs d'attaque.

Sécurité de la couche transport

Toutes les communications utilisent TLS 1.3 avec des suites cryptographiques robustes. Le certificate pinning est recommandé pour les applications mobiles afin d'éviter les attaques de type homme du milieu.

Signature des requêtes

Les requêtes de vérification sont signées avec JSON Web Signatures (JWS), avec :

Algorithme : ES256 (ECDSA avec P-256 et SHA-256)
Stockage des clés : Hardware Security Modules (HSM) pour les clés du fournisseur de services
Rotation : rotation régulière des clés avec des périodes de validité qui se chevauchent

Validation des réponses

Les réponses sont validées via :

Signatures numériques : chaque réponse est signée numériquement par le fournisseur d'identité national
Contrôles temporels : les réponses doivent être utilisées dans une fenêtre courte (en général 60 secondes)
Vérification du nonce : chaque requête inclut un nonce cryptographique qui doit être renvoyé dans la réponse
Liaison de session : les réponses sont liées à des sessions spécifiques et ne peuvent pas être réutilisées

Techniques de préservation de la confidentialité

Divulgation sélective : les utilisateurs peuvent choisir quels attributs partager, même si d'autres ont été demandés.

Preuves à divulgation nulle de connaissance (Zero-Knowledge Proofs) : permettent de prouver des propriétés sur des données sans révéler les données elles-mêmes. Par exemple, prouver que vous avez plus de 18 ans sans révéler votre date de naissance. Dans la spécification européenne de vérification d'âge, cela concerne l'attestation de preuve d'âge distincte, et uniquement via l'API W3C Digital Credentials, pas OpenID4VP ; une présentation du PID divulgue toujours la date de naissance.

Chiffrement des attributs : en transit, les attributs sont chiffrés avec des clés spécifiques à la session, ce qui garantit que même l'infrastructure du fournisseur de services ne peut pas y accéder avant leur remise à votre application.

Modèles d'intégration

Des architectures applicatives différentes exigent des approches d'intégration différentes.

Modèle 1 : backend vers backend (server-side)

Idéal pour les applications rendues côté serveur ou les applications mobiles natives :

// 1. Créer la session sur votre backend
POST /api/verification/create
→ { sessionId, qrCodeData }

// 2. Afficher le QR code à l'utilisateur
// 3. Polling ou stream du statut sur le backend
GET /api/verification/:sessionId/status

// 4. Une fois terminé, récupérer le résultat
GET /api/verification/:sessionId/result
→ { result: { ageVerified: true } }

Avantages : contrôle total, meilleure sécurité, les attributs ne passent jamais par le frontend.

Idéal pour les SPA et les intégrations rapides :

import { init } from '@eidas-pro/widget';

await init({
  containerId: 'age-check',
  baseUrl: 'https://yourapp.com/eidas', // votre proxy conserve la clé API côté serveur
  verificationType: 'age',
  onVerified: (verified, { sessionId }) => {
    console.log('Age check passed:', verified, sessionId);
  },
  onError: (error) => {
    console.error('Verification failed:', error);
  }
});

Avantages : intégration rapide, gestion automatique de l'UI, design adaptatif.

Modèle 3 : extension e-commerce

Des extensions préconstruites pour des plateformes comme WooCommerce et Shopify gèrent l'ensemble du flux :

Ajoute un point de vérification à l'étape de paiement
Stocke le statut de vérification avec la commande
Fournit un tableau de bord admin pour les rapports de conformité
Gère automatiquement les cas limites et les erreurs

Gestion des erreurs et cas limites

Les implémentations robustes doivent gérer différents scénarios d'échec.

Scénarios d'erreur fréquents

Dépassement de délai : l'utilisateur ne scanne pas le QR code avant la fin de validité

Solution : afficher un nouveau QR code, prolonger la session si l'utilisateur est toujours présent

Annulation utilisateur : l'utilisateur refuse de partager les attributs

Solution : proposer des méthodes de vérification alternatives ou expliquer pourquoi la vérification est nécessaire

Pannes réseau : problèmes de connexion pendant la vérification

Solution : implémenter des tentatives de reprise avec backoff exponentiel, conserver l'état de la session

Attributs non pris en charge : l'attribut demandé n'est pas disponible pour le schéma eID de l'utilisateur

Solution : dégradation élégante ou demande d'attributs alternatifs

Niveau de garantie incompatible : l'eID de l'utilisateur n'atteint pas le niveau de garantie requis

Solution : demander un facteur d'authentification supplémentaire ou rejeter la vérification avec une explication claire

Journalisation et supervision

Mettez en place une journalisation complète pour :

Détails des requêtes de vérification (sans données personnelles)
Taux de succès/échec par pays
Durée moyenne de vérification
Types et fréquences d'erreurs

Ces données sont essentielles pour optimiser les taux de conversion et identifier les problèmes techniques.

Optimisation des performances

Stratégies de cache

Cache des clés publiques : mettez en cache les clés publiques des fournisseurs d'identité nationaux avec un TTL adapté (en général 24 heures) pour éviter des récupérations répétitives.

Validation de la chaîne de certificats : préchargez et validez les chaînes de certificats pendant les périodes de faible trafic.

Mise en cache des listes de confiance : mettez en cache les listes de confiance et actualisez-les selon un calendrier. La vérification d'une présentation ne nécessite aucun appel au fournisseur de PID, la latence de validation reste donc locale.

Objectifs de temps de réponse

Création de session : < 200 ms
Génération du QR code : < 50 ms
Validation des attributs : < 500 ms
Flux utilisateur de bout en bout : 5 à 10 secondes (principalement le temps d'authentification utilisateur)

Conclusion

La vérification eIDAS repose sur des fondations cryptographiques robustes, des protocoles standardisés et des architectures respectueuses de la confidentialité. En comprenant le flux technique, de l'initialisation de session à la validation des attributs, les développeurs peuvent construire des intégrations à la fois sûres et simples à utiliser.

La combinaison d'OpenID4VP, des justificatifs vérifiables et de l'identité décentralisée crée un système qui passe à l'échelle dans toute l'Europe tout en protégeant la vie privée des utilisateurs et en conservant une validité juridique.

Lors de l'implémentation de la vérification eIDAS, concentrez-vous sur la gestion des erreurs, l'optimisation des performances et une communication utilisateur claire. La complexité technique est prise en charge par les protocoles sous-jacents ; votre rôle est de créer une expérience fluide et fiable.

Besoin d'un support technique pour votre intégration ? Notre équipe d'ingénierie peut vous aider pour les revues d'architecture, les questions d'implémentation et l'optimisation des performances. Contactez-nous →