Par Olivier Meunier — développeur indépendant construisant Tessaliq, un verifier EUDI Wallet orienté vérification d’âge sous le cadre ARCOM français.
TL;DR
L’ENISA a ouvert jusqu’au 30 avril 2026 une consultation publique sur le Draft Candidate EUDIW Cybersecurity Certification Scheme v0.4.614. Le document est sérieux, structuré, et dans l’ensemble plutôt bon. Il a pourtant un angle mort structurel : il certifie soigneusement le wallet (niveau d’assurance élevé, composants critiques couverts) et exclut explicitement les relying parties du scope de certification — alors que les mêmes relying parties apparaissent comme adversaires ou victimes dans au moins 7 menaces de la spec de sécurité associée. J’ai soumis un position paper qui propose de combler ce trou, sans imposer d’obligation nouvelle aux acteurs qui ne peuvent pas la porter.
Ce post explique d’où je parle, ce que contient concrètement ma contribution, et pourquoi un implémenteur solo a intérêt à participer à une consultation ENISA même quand il n’a pas d’équipe juridique derrière lui.
D’où je parle
Tessaliq est un verifier EUDI Wallet privacy-preserving que je développe seul, à titre personnel, en pré-création d’entreprise. Le chemin de production aujourd’hui est l’attribute check mdoc aligné sur le profil eu.europa.ec.av.1 du blueprint UE de vérification d’âge. Côté conformance, le verifier a passé 24 modules applicables de la suite OpenID Foundation pour OID4VP 1.0 Final, répartis sur 4 plans immutables publics couvrant la matrice 2×2 (SD-JWT-VC × mdoc × standard × HAIP). Les retours d’expérience techniques sont publiés séparément sur ce blog.
Ce qui est important pour la suite : je ne suis pas un wallet provider, pas un PID provider, pas un laboratoire d’évaluation, pas un fournisseur commercial institutionnel. Je suis un implémenteur individuel — et du point de vue du schéma ENISA, je suis exactement dans la catégorie qui est placée hors scope : une relying party potentielle.
L’angle de la contribution : une asymétrie qui mérite d’être nommée
Le scheme v0.4.614 est explicite sur son traitement des relying parties. Annexe X, Note X.2.1, page 91 :
« all requirements applying to relying parties are considered out of scope »
C’est une décision compréhensible. Les relying parties sont hétérogènes : administrations, banques, éditeurs SaaS, startups solo. Leur imposer une certification uniforme ralentirait l’adoption EUDI au pire moment. Premier ordre, c’est le bon choix.
Mais le document compagnon — le Draft EUDIW Security Requirements v0.5.614 — raconte une histoire différente. On y trouve au moins 7 menaces dans lesquelles la relying party est soit l’adversaire, soit la victime : TR37 (RP compromise → disclosure), TR40 (RP multi-entités partageant des données en interne), TR76 (abus de requêtes par une RP), TR83 (dérivation d’identité → surveillance), TR84 (collusion de RP pour corréler les présentations), TR91 (replay), TR103 (usurpation d’identité derrière une RP).
Le schéma construit donc un modèle détaillé de la relying party comme adversaire potentiel — il exige du wallet qu’il authentifie la RP, qu’il affiche son identité à l’utilisateur, qu’il restreigne ce qui peut être disclosé, qu’il utilise des credentials rotatifs per-RP — puis il place toutes les exigences qui porteraient sur la RP elle-même hors de son scope.
Conséquence pratique : le niveau d’assurance effectif offert à l’utilisateur final est le minimum entre la certification du wallet (soigneusement définie) et la posture de sécurité du verifier (non contrainte). Le deuxième terme est non borné. Autrement dit, une propriété de cybersécurité affirmée dans le modèle de menace n’est pas vérifiable au moment de la certification, faute d’un acteur à certifier.
C’est le cœur du papier.
Les trois recommandations concrètes
1. Une certification optionnelle et volontaire pour les relying parties
Pas obligatoire — optionnelle. Une RP qui accepte de s’engager sur un standard plus élevé de privacy et de sécurité devrait pouvoir être formellement reconnue pour ça, pour que les utilisateurs, les wallets et les régulateurs puissent la distinguer d’une RP qui fait le strict minimum. Le baseline proposé est léger : minimisation par construction (demander age_over_18, pas la date de naissance), non-rétention des attributs présentés, conformité cryptographique démontrable contre la suite OIDF, posture de confiance transparente et machine-lisible, divulgation coordonnée des vulnérabilités. ETSI EN 319 401, déjà référencée par le scheme actuel, fournit un point de départ mature pour les exigences organisationnelles.
2. Clarifier et étendre l’Annexe I.6 du scheme
L’Annexe I.6 décrit un « service de validation de wallets et de relying parties » comme l’un des quatre services ICT certifiables. Dans sa forme actuelle, elle est sous-spécifiée sur deux points qui comptent. D’abord, sa relation à un registre public de relying parties n’est pas décrite (contenu, mise à jour, inspection). Ensuite, son seul ancrage normatif est l’article 5c(8) d’eIDAS, qui mandate un mécanisme de registre mais ne spécifie rien sur la posture de sécurité attendue des RP. Ma recommandation : définir le contenu minimal d’une entrée de registre (identité légale de la RP, liste d’attributs autorisés + finalité, contact pour divulgation de vulnérabilités, statut de certification si la Recommandation 1 est adoptée, politique de rétention déclarée). Sans ça, le service de validation reste une recherche de lookup sans garantie attachée.
3. Traiter la collusion RP (TR84) au niveau protocole, pas seulement wallet
La menace TR84 est reconnue comme un risque de grade surveillance. Les contre-mesures actuelles sont toutes côté wallet : credentials rotatifs, per-RP. Elles sont correctes mais incomplètes. Elles empêchent deux RP d’observer le même identifiant cryptographique, mais elles n’empêchent pas la corrélation comportementale sur les logs serveur. Deux RP qui reçoivent légitimement chacune une attestation d’âge, un pseudonyme et un timestamp peuvent corréler leurs logs post-présentation sans violer aucune règle protocolaire. Si les deux services touchent la même population — par exemple deux opérateurs français soumis au même référentiel ARCOM — la corrélation est triviale même avec une rotation cryptographique parfaite. C’est un gap cybersécurité au sens strict, qui demande une règle au niveau protocole (journalisation minimale obligatoire pour les RP certifiées, interdiction du partage inter-RP à des fins de profilage, binding cryptographique du statut de certification dans les logs de transaction).
Et en bref, une Recommandation 4 : acknowledger l’age verification comme premier use case concret de déploiement EUDI à l’échelle, et s’en servir comme banc de test opérationnel pour les principes du scheme.
Pourquoi un implémenteur solo le fait
Un implémenteur solo qui passe une consultation ENISA en silence laisse le terrain à des positions qui ne sont pas écrites par des gens qui implémentent vraiment. Le coût marginal d’écrire dix pages quand on a déjà fait le travail technique est très bas. Le coût de ne pas le faire — voir une recommandation finale qui ne tient pas compte de la réalité de l’implémentation — est plus élevé, parce que les textes européens de certification s’écrivent une fois et vivent cinq ans.
Il y a aussi un effet secondaire utile que je ne cache pas : la contribution entre dans le registre public des contributeurs ENISA, ce qui constitue un signal de sérieux intéressant à montrer ensuite à un prospect ou à un partenaire institutionnel. Ce n’est pas la raison pour laquelle j’ai écrit le papier, mais ce serait malhonnête de prétendre que c’est un non-facteur.
Les preuves techniques sur lesquelles s’appuie le papier — 24/24 modules OIDF passés sur 4 plans, implémentation mdoc du profil eu.europa.ec.av.1, HPKE/JWE pour le Digital Credentials API — sont toutes référencées en annexe et disponibles pour review sur demande. Sans ces preuves, le papier serait une note de lecture de plus. Avec elles, c’est une contribution qu’un reviewer ENISA averti peut vérifier avant de décider quoi en faire.
Si tu veux suivre ou échanger
Le PDF de la contribution soumise à l’EUSurvey est disponible à la demande à contact [at] tessaliq [dot] com. Si tu travailles sur un verifier EUDI, sur une offre de conseil eIDAS 2.0, ou simplement sur la conformité ARCOM et que tu as croisé des problèmes similaires sur l’asymétrie wallet certifié / verifier non certifié, je suis content d’en discuter — c’est exactement ce genre d’échanges qui rend la prochaine consultation plus utile que la précédente.
À propos
Olivier Meunier est un développeur indépendant basé à Tiercé, en Maine-et-Loire. Tessaliq est un verifier EUDI Wallet privacy-preserving qu’il développe à titre personnel pour confronter les standards techniques de l’EUDI Wallet aux décisions concrètes que doit prendre un implémenteur. C’est un projet en pré-création d’entreprise. Open-core : le cœur du verifier est privé, les composants périphériques (circuits Noir, SDK Web, bibliothèque SD-JWT, utilitaires partagés) sont publiés sous licence MIT à github.com/Tessaliq/tessaliq-open. Contact : contact [at] tessaliq [dot] com.