Intégrer l'attestation de preuve d'âge de l'UE : guide du développeur sur l'espace de noms eu.europa.ec.av.1

Si vous intégrez la vérification d'âge face à la solution de l'UE, une chaîne de caractères apparaîtra dans votre code plus que toute autre : eu.europa.ec.av.1. C'est l'espace de noms de l'attestation « Proof of Age », et comprendre ce qu'il est — et ce qu'il n'est délibérément pas — constitue le fondement d'une intégration correcte.

Ce guide est le pendant pratique de notre décryptage conceptuel de l'application de vérification d'âge de l'UE. Ici, nous restons au niveau du protocole et du modèle de données : le format du justificatif, le flux d'émission, et la façon de connecter votre code à l'émetteur de référence en ligne.

L'attestation, avec précision

L'émetteur officiel de vérification d'âge de l'UE est un fournisseur de (Q)EAA — un fournisseur d'attestations électroniques (qualifiées) d'attributs, au sens d'eIDAS 2.0. Il met en œuvre la spécification de vérification d'âge et délivre une attestation « Proof of Age » présentant les propriétés caractéristiques suivantes :

• Format : mso_mdoc — le format de document mobile ISO/IEC 18013-5, la même famille que celle utilisée par les permis de conduire mobiles et le PID du portefeuille EUDI. Si vous avez lu Comment fonctionne la vérification eIDAS, c'est le format de justificatif qui le sous-tend.
• Espace de noms : eu.europa.ec.av.1. Chaque revendication de l'attestation est qualifiée par cet espace de noms. La version est inscrite dans l'espace de noms lui-même — le .1 final — de sorte qu'un futur changement de rupture deviendra eu.europa.ec.av.2, et votre code pourra brancher dessus.
• Sémantique : elle confirme que le porteur est au-dessus d'un seuil d'âge donné sans divulguer la date de naissance. C'est tout l'enjeu. L'attestation répond à « cette personne a-t-elle plus de N ans ? » et rien de plus.

En termes eIDAS, il s'agit d'une attestation électronique d'attributs au titre de l'article 3, point 44) du règlement. Cet ancrage juridique n'est pas décoratif — c'est lui qui permet à une présentation de preuve d'âge de porter une valeur juridique transfrontalière, de la même manière qu'une vérification transfrontalière d'identité.

Pourquoi un espace de noms plutôt qu'un simple « âge ≥ 18 »

Les nouveaux venus demandent souvent pourquoi l'UE a enveloppé une chose aussi simple qu'un booléen « plus de 18 ans » dans un espace de noms mdoc formel. Trois raisons, dont chacune vous épargne du travail par la suite :

1. Plusieurs seuils, un seul modèle. Les barrières d'âge ne sont pas toutes à 18 ans. L'alcool, les jeux d'argent, certains contenus et les règles relatives aux « services destinés aux enfants » utilisent 16, 18, 21 et d'autres seuils. Une attestation à espace de noms peut exprimer les revendications de seuil de manière uniforme, plutôt que de forcer chaque partie utilisatrice à inventer son propre encodage.
2. Provenance vérifiable. Parce que la revendication se trouve à l'intérieur d'un mdoc signé, votre vérificateur contrôle une signature et une chaîne de confiance — et non une valeur auto-déclarée. La signature est ce qui rend cela fondamentalement différent de la case à cocher d'âge qu'elle remplace.
3. Non-corrélation par construction. L'attestation standard est à usage unique et émise par lots précisément pour que des présentations répétées ne puissent être corrélées en un profil. Nous y revenons plus bas, car c'est la propriété du système la plus fréquemment sur-revendiquée.

Émission : OpenID4VCI

L'émetteur suit OpenID for Verifiable Credential Issuance (OpenID4VCI). Si votre équipe a travaillé avec OpenID4VP pour la présentation, VCI en est le frère du côté émission : là où VP est la façon dont un justificatif vous est présenté, VCI est la façon dont il arrive dans le portefeuille en premier lieu.

Le flux, au niveau où vous avez besoin de le raisonner :

1. Un utilisateur s'inscrit sur l'application de vérification d'âge ou sur le portefeuille, prouvant son âge une seule fois via une source de confiance (un eID, ou — depuis le blueprint v2 — un passeport ou une carte nationale d'identité).
2. Le portefeuille exécute un échange OpenID4VCI avec l'émetteur pour obtenir un lot d'attestations Proof of Age.
3. Chaque attestation du lot est à usage unique. À mesure que l'utilisateur présente des preuves au fil du temps, le portefeuille puise dans le lot et le renouvelle selon les besoins.

En tant que partie utilisatrice intégratrice, vous n'exploitez généralement pas le côté émission — c'est le rôle du fournisseur de (Q)EAA. Mais le comprendre explique les propriétés que vous observerez au moment de la présentation : des preuves éphémères, à usage unique, sans identifiant stable sur lequel s'appuyer.

L'émetteur de référence en ligne — et la réserve qui compte

L'UE publie une implémentation de référence fonctionnelle. Le back end de l'émetteur (av-srv-web-issuing-avw-py) est open source au sein de l'organisation GitHub officielle EU Digital Identity Wallet, sous copyright de la Commission européenne, et il existe un émetteur de référence en ligne, hébergé publiquement, que vous pouvez solliciter pendant le développement.

Lisez ceci attentivement : il s'agit d'une implémentation de référence et de test. Ce n'est explicitement pas un émetteur complet de niveau production, destiné aux citoyens. Utilisez-le pour valider votre intégration, votre analyse syntaxique des justificatifs et votre flux de présentation. Ne construisez pas un plan de lancement qui suppose qu'il s'agit du point d'accès de production que vos véritables utilisateurs solliciteront — ce point d'accès sera celui des applications et portefeuilles nationaux de vérification d'âge que déploient les États membres précurseurs. Traitez l'émetteur de référence comme vous le feriez de tout sandbox : inestimable pour construire, mais pas une dépendance de production.

La revendication de confidentialité, énoncée avec exactitude

C'est ici que les ingénieurs rigoureux se distinguent du discours marketing. Vous lirez que la solution de vérification d'âge de l'UE utilise des preuves à divulgation nulle de connaissance (ZKP) afin qu'une partie utilisatrice n'apprenne qu'une réponse oui/non, sans aucune possibilité de corrélation. Soyez précis :

• Ce qui est solide : l'attestation mdoc standard est à usage unique et émise par lots précisément pour contrarier la traçabilité. La preuve révèle le statut au-dessus du seuil, non la date de naissance ni l'identité. C'est une propriété de confidentialité authentique et effectivement livrée.
• Ce avec quoi il faut être prudent : la ZKP est décrite comme un type de preuve pris en charge et préféré dans les recommandations destinées aux vérificateurs — et non comme une garantie universellement livrée et pleinement non-corrélable, spécifiée dans une quelconque annexe. N'écrivez pas une documentation affirmant « le système est à divulgation nulle de connaissance, donc la corrélation est impossible. » Écrivez : « la non-corrélation est obtenue grâce à des preuves à usage unique, émises par lots ; la ZKP est prise en charge en tant que type de preuve renforcé. »

Ce n'est pas du pédantisme. Si votre discours de conformité revendique une garantie cryptographique que le système déployé ne fournit pas encore uniformément, c'est sur cette revendication qu'un auditeur tirera. La version honnête reste un excellent argument de confidentialité — voyez Vérification d'âge respectueuse de la vie privée pour la manière dont nous la formulons.

Une liste de contrôle d'intégration minimale

L'étape 6 relie cette tâche de développeur aux obligations d'enregistrement des parties utilisatrices et de WRPAC. Une partie utilisatrice qui s'enregistre uniquement pour la preuve d'âge est structurellement incapable de demander plus — ce qui constitue la réponse la plus nette possible à un régulateur de la protection des données.

En résumé

L'espace de noms eu.europa.ec.av.1 est petit en taille et grand en conséquences. C'est une attestation mso_mdoc, au titre de l'article 3, point 44), émise via OpenID4VCI, qui prouve un seuil d'âge et rien d'autre. Construisez face à l'émetteur de référence en ligne pour calibrer correctement votre analyse syntaxique et votre flux de présentation — mais traitez-le comme un sandbox, non comme la production. Et lorsque vous documentez les propriétés de confidentialité, décrivez ce qui est livré (usage unique, émission par lots, seuil uniquement) plutôt que ce qui relève de l'aspiration (ZKP universelle). Réussissez ces deux points et votre intégration survivra au contact aussi bien des vrais portefeuilles que des vrais auditeurs.

Cet article reflète la spécification de vérification d'âge de l'UE et son implémentation de référence en date de juin 2026. L'émetteur de référence est une implémentation de test, non de production. Vérifiez le schéma du justificatif par rapport au dépôt officiel de l'émetteur avant de construire.