eu.europa.ec.av.1 expliqué : comment un vérificateur valide une attestation européenne de preuve d'âge avec la liste de confiance

Si vous avez commencé à intégrer l'application européenne de vérification d'âge, vous avez presque certainement croisé deux expressions que personne n'explique simplement : l'espace de noms eu.europa.ec.av.1, et l'instruction consistant à valider l'attestation de preuve d'âge par rapport à la liste de confiance.

Les deux sont essentiels, car c'est leur combinaison qui distingue un vrai contrôle d'âge d'un contrôle falsifiable. Un « oui, cette personne a plus de 18 ans » signé cryptographiquement ne vaut rien si vous ne pouvez pas répondre à la question suivante : qui l'a signé, et cette entité était-elle autorisée à le faire ? Cet article explique ce que contient eu.europa.ec.av.1, puis détaille les étapes exactes qu'un vérificateur suit pour prouver qu'une attestation est authentique à l'aide de l'Age Verification Trusted List de l'UE.

Ce qu'est réellement eu.europa.ec.av.1

La solution européenne de vérification d'âge — l'application en marque blanche que la Commission a rendue prête fonctionnellement le 15 avril 2026, avec une implémentation de référence open source (ageverification.dev) — émet un justificatif précis appelé attestation de preuve d'âge. Dans l'encodage ISO/IEC 18013-5 mso_mdoc, le type de document de cette attestation et son unique espace de noms sont tous deux eu.europa.ec.av.1.

Cet espace de noms est volontairement minuscule. Il ne transporte que les attributs suivants :

La spécification impose aussi une règle stricte : une attestation de preuve d'âge NE DOIT PAS inclure d'autre attribut. Pas de nom, pas de numéro de document, pas de date de naissance — une attestation de preuve d'âge est une attestation électronique d'attributs au sens de l'article 3(44) du règlement EUDI, qui confirme un seuil et rien d'autre. C'est la garantie de minimisation des données inscrite dans le format lui-même : même si elle le voulait, l'attestation ne peut pas divulguer une identité.

Le problème de confiance : un booléen a besoin d'un émetteur prouvable

Voici le point de friction que tout intégrateur finit par rencontrer. Votre vérificateur reçoit un objet signé indiquant age_over_18: true. La signature prouve que l'objet n'a pas été modifié — mais elle ne prouve pas, à elle seule, que le signataire est un émetteur légitime d'attestations d'âge. N'importe qui peut générer une paire de clés et signer {age_over_18: true}.

La vraie décision de confiance n'est donc pas « la signature est-elle valide ? ». Elle est : le certificat qui a produit cette signature figure-t-il sur la liste des entités que l'UE a autorisées à émettre des attestations de preuve d'âge ? Cette liste est l'Age Verification Trusted List.

L'Age Verification Trusted List

L'Age Verification Trusted List de l'UE est une liste de confiance de style ETSI, hébergée par la Commission européenne dans le tableau de bord eIDAS. Elle sert d'ancre de confiance centrale pour la vérification d'âge dans tous les États membres. Chaque État membre notifie à la Commission les fournisseurs d'attestations de preuve d'âge établis sur son territoire, et leurs certificats de signature sont publiés dans la liste.

Elle est identifiée par un type de liste dédié, et les émetteurs d'âge par un type de service dédié :

<TSLType>http://ec.europa.eu/tools/lotl/av/TrstSvc/TrustedList/TSLType/AVTL</TSLType>
...
<TSPService>
  <ServiceInformation>
    <ServiceTypeIdentifier>http://ec.europa.eu/tools/lotl/av/TrstSvc/Svctype/PAA</ServiceTypeIdentifier>
    <ServiceName><Name xml:lang="en">Age Verification Issuer</Name></ServiceName>
    <ServiceDigitalIdentity>
      <DigitalId><X509Certificate>...</X509Certificate></DigitalId>
    </ServiceDigitalIdentity>
  </ServiceInformation>
</TSPService>

PAA signifie Proof of Age Attestation Provider. Le X509Certificate présent sous chaque service est l'ancre de confiance que votre vérificateur contrôle. La Commission héberge aussi une liste de confiance d'acceptation, destinée aux tests, dans l'environnement ACC, afin que vous puissiez intégrer plusieurs émetteurs de test nationaux avant la mise en production.

Comment un vérificateur valide une attestation, étape par étape

Lorsqu'une attestation de preuve d'âge arrive, un vérificateur correct effectue toutes les opérations suivantes et refuse l'accès si l'une d'elles échoue :

1. Analyser et contrôler le périmètre. Décodez le mso_mdoc, confirmez que le type de document est eu.europa.ec.av.1, et ne lisez que l'attribut demandé, par exemple age_over_18. Ignorez tout le reste.
2. Vérifier la signature de l'émetteur. Contrôlez la signature du Mobile Security Object (MSO) afin de savoir que le contenu de l'attestation est authentique et inchangé.
3. Valider le signataire avec la liste de confiance. Prenez le certificat de signature du document qui a produit cette signature et confirmez qu'il chaîne vers un certificat publié dans l'AV Trusted List sous le type de service PAA. C'est cette étape qui transforme une signature en confiance. Aucune correspondance → rejet.
4. Contrôler la validité. Faites respecter expiry_date et la fenêtre ValidityInfo du mdoc.
5. Confirmer le lien avec le détenteur. Vérifiez que l'attestation est liée à l'appareil qui la présente : le portefeuille doit prouver qu'il contrôle la clé privée associée à la clé publique inscrite dans l'attestation. Ainsi, une attestation copiée ne peut pas être rejouée.
6. Échouer de façon fermée. Si l'émetteur n'est pas dans la liste, si la signature ne se vérifie pas, ou si la preuve est expirée ou non liée au détenteur, refusez. Ne faites jamais « passer en cas d'erreur ».

Les étapes 2 et 3 sont le cœur du mécanisme. Elles reflètent le modèle d'authentification passive utilisé pour les passeports électroniques : vérifier la signature, puis valider le certificat de signature contre une liste faisant autorité des émetteurs légitimes. La liste de confiance est cette liste faisant autorité.

Présentation et confidentialité : DC API, OID4VP, ZKP et mdocs à usage unique

Deux éléments sont utiles à connaître, car ils structurent la manière de construire le vérificateur :

Deux mécanismes de transport. La Digital Credentials API (DC API) est la voie principale, intégrée au navigateur ; OpenID for Verifiable Presentations (OID4VP) sert de repli lorsque la DC API n'est pas disponible. Un vérificateur de production prend en charge les deux et choisit la meilleure option à l'exécution.

Deux types de preuve, tous deux conçus contre le pistage. Une présentation par preuve à divulgation nulle de connaissance donne le même oui/non sans divulguer d'identifiant corrélable. L'attestation mdoc standard obtient l'absence de corrélation autrement : les preuves sont à usage unique et émises par lots (la spécification recommande des lots de 30), et les émetteurs rendent volontairement les horodatages ValidityInfo moins précis (mêmes hh:mm:ss au sein d'un lot, conformément à la recommandation ISO 18013-5), afin que l'attestation elle-même ne porte pas d'empreinte permettant de corréler un utilisateur entre plusieurs visites.

Le point à retenir pour quiconque applique une politique d'âge : vous recevez une réponse de seuil, et par conception vous ne pouvez pas la transformer en identifiant de suivi.

Pourquoi c'est précisément la plomberie que nous prenons en charge

Tout ce qui précède est facile à mal implémenter. Sautez l'étape 3, et vous obtenez un contrôle d'âge que n'importe quel attaquant peut falsifier. Codez en dur un seul certificat d'émetteur, et votre intégration casse dès qu'un nouvel État membre notifie un fournisseur. Analysez le XML ETSI à la main, et vous héritez pour toujours du rafraîchissement de la liste de confiance, de la validation des chaînes de certificats et de la révocation.

C'est exactement cette couche qu'eIDAS Pro exploite pour vous : notre vérificateur parle eu.europa.ec.av.1, valide chaque attestation contre l'AV Trusted List en direct (avec la liste de test/ACC pour l'intégration), prend en charge la DC API et OID4VP, et renvoie à votre application un booléen propre — sans stocker de données personnelles. Lorsque l'attestation AV autonome et les parcours plus larges de l'EUDI Wallet convergeront, le même appel de vérification couvrira les deux.

Si votre obligation de conformité est de « vérifier l'âge auprès d'une source de confiance autorisée par les pouvoirs publics », la liste de confiance est cette source — et réussir sa validation est tout le travail.

eIDAS Pro fournit une vérification d'âge et d'identité prête pour l'EUDI, centrée sur la confidentialité, pour les plateformes européennes — validation par liste de confiance, eID en couches et API à sortie booléenne, sans stockage de données personnelles. Réserver une consultation →

Cet article fournit des informations techniques générales, et non un avis juridique. Travaillez toujours à partir des spécifications européennes de vérification d'âge en vigueur et avec vos propres conseils en conformité.