Accepter une présentation EUDI Wallet est une décision de confiance, et c'est dans le code de votre intégration que cette décision se prend. Cet article s'adresse aux parties utilisatrices (relying parties) : les communes et les prestataires de services qui accepteront des présentations issues du wallet, et non les équipes qui développent les wallets. Il énumère les questions auxquelles nous voudrions avoir des réponses avant d'ouvrir le wallet à de vrais utilisateurs, sous la forme d'une checklist de revue plutôt que d'une conception aboutie.
Identifier la spécification sur laquelle vous construisez
Le socle technique est l'Architecture and Reference Framework (ARF). Il est publié dans un dépôt GitHub public et développé dans le cadre de la Common Union Toolbox. Le dépôt indique que la dernière version faisant foi est la version taguée la plus récente. Une branche ou un résumé de blog ne fait pas foi.
La base juridique est le règlement (UE) n° 910/2014 tel que modifié par le règlement (UE) 2024/1183, ainsi que ses règlements d'exécution de la Commission. L'ARF renvoie à la liste tenue à jour de ces textes dans ses sections Introduction et References.
Les premières questions sont donc d'ordre administratif, mais elles comptent :
- Sur quelle version de l'ARF votre fournisseur ou intégrateur s'est-il appuyé ?
- Qui, chez vous, suit les nouvelles versions taguées et les règlements d'exécution, et comment les changements parviennent-ils à votre backlog ?
- Votre contrat avec le fournisseur d'identité mentionne-t-il une version précise, ou simplement « conforme à eIDAS 2.0 » ?
Questions sur l'assertion
Le wallet transmet une présentation à votre service. Avant qu'elle puisse devenir une session, vous devez savoir ce que vous avez réellement vérifié.
- Qui l'a émise ? Votre service ne doit accepter que les présentations provenant d'émetteurs auxquels vous avez décidé de faire confiance, pour les types d'attributs que vous avez décidé d'accepter. « Toute signature valide » n'est pas une politique. Consignez la liste d'acceptation par écrit, désignez un responsable et définissez la manière d'ajouter et de retirer des entrées.
- Est-elle liée à cette transaction ? Une présentation rejouable contre votre point d'accès de connexion est un identifiant volé en puissance. Confirmez avec votre fournisseur comment une présentation est rattachée à votre session, et vérifiez par un test qu'une ancienne présentation est rejetée.
- Que se passe-t-il quand la vérification échoue ou n'est pas disponible ? Décidez si vous échouez de façon sécurisée (fail closed). Vérifiez que la gestion des erreurs et les situations de charge n'orientent pas les utilisateurs vers un parcours de repli plus faible.
- Que journalisez-vous ? Il vous faut de quoi enquêter sur un incident sans stocker les données personnelles que le wallet a été conçu pour réduire au minimum.
Une précision sur le premier point : la politique d'acceptation des émetteurs et des attributs est le contrôle que nous recommandons. Ce n'est pas une exigence citée de l'ARF.
Questions sur les attributs
La Commission décrit le wallet comme un outil permettant aux utilisateurs de ne divulguer que les informations nécessaires, comme l'âge ou la nationalité, tout en conservant par-devers eux les autres données personnelles. C'est le niveau d'attente que votre intégration doit satisfaire en tant que partie utilisatrice.
Si votre service a besoin de savoir qu'une personne a dépassé un certain âge, demandez cela, pas une date de naissance. Si vous avez besoin d'un résident de votre commune, demandez l'attribut qui le prouve, pas une adresse complète. Chaque attribut supplémentaire que vous demandez accroît les données que vous devez protéger et justifier dans votre propre analyse d'impact sur la vie privée.
Demandez-vous ensuite ce que l'attribut prouve réellement. Un attribut émis par une autorité publique et un autre émis par un acteur privé peuvent cohabiter dans le même wallet et se ressembler dans votre code. Rattachez chacun à la décision qu'il soutient. Un numéro de carte de bibliothèque ne devrait pas donner accès à la déclaration d'impôts.
Une ligne de la politique d'acceptation pourrait ressembler à ceci. Les valeurs illustrent le format, elles ne constituent pas une recommandation :
| Émetteur | Attribut | Décision de la partie utilisatrice | Responsable | Fréquence de revue |
|---|---|---|---|---|
| Émetteur national d'identité (exemple) | Âge supérieur à 18 ans | Autoriser l'accès au service soumis à restriction d'âge ; ne pas stocker de date de naissance | Responsable du service | Tous les six mois |
Si vous ne parvenez pas à remplir les cinq colonnes d'une entrée, elle n'est pas prête à figurer sur la liste.
Pour les usages organisationnels, les projets pilotes testent les identités numériques d'organisation comme cas d'usage : prouver qu'une personne est un représentant légitime d'une organisation. Si vous servez des entreprises, décidez dès maintenant comment vous traiterez une personne agissant pour le compte d'une société, et comment vous saurez que son pouvoir a pris fin.
Questions sur les parcours de signature
La signature de contrats fait partie des scénarios pilotes ; traitez-la donc comme un cas d'assurance distinct de la connexion.
- De quels services dépend votre parcours de signature ou de cachet, et qui les exploite ?
- Que conservez-vous comme preuve d'une signature, et pendant combien de temps ?
- Si une signature est contestée dans deux ans, pouvez-vous démontrer ce qui a été présenté et vérifié à l'époque ?
Ne partez pas du principe qu'une connexion réussie implique une chaîne de signature valide. Ce sont deux vérifications distinctes, avec des modes de défaillance distincts. Vos équipes juridiques et sécurité doivent s'accorder sur ce qui constitue une preuve acceptable avant la signature du premier contrat.
Testez l'intégration, puis testez-la encore
Le wallet prototype de la Commission comprend des bibliothèques de code et une application d'exemple, et l'implémentation de référence est open source. Le dépôt de l'ARF renvoie vers un site de conformité. Utilisez ces ressources pour vos tests, et non comme une dépendance de production que vous n'auriez jamais examinée.
Les projets pilotes à grande échelle impliquent plus de 350 entités issues de 26 États membres, de la Norvège, de l'Islande et de l'Ukraine, et couvrent des domaines tels que les services publics, la banque et les paiements. Vos propres points d'accès, parcours de repli et gestion de session doivent néanmoins faire l'objet de leurs propres tests.
Traitez l'intégration comme du nouveau code d'authentification. Cela suppose une modélisation des menaces, des tests de cas d'abus portant sur le rejeu, les présentations malformées et les émetteurs inattendus, ainsi qu'un test d'intrusion du parcours finalisé avant le lancement. Quels que soient les tests réalisés par l'éditeur du wallet, votre service de partie utilisatrice nécessite sa propre revue.
Par où commencer
- Figez votre cible : consignez la version de l'ARF et les règlements d'exécution sur lesquels repose votre intégration, et désignez quelqu'un pour surveiller les évolutions.
- Rédigez une politique d'acceptation : listez les émetteurs et types d'attributs auxquels vous ferez confiance, la décision que chacun soutient, le responsable et la fréquence de revue.
- Réduisez vos demandes d'attributs au minimum nécessaire à chaque service, et consignez le résultat dans votre propre analyse d'impact sur la vie privée.
- Élaborez un plan de test sur l'implémentation de référence et les ressources de conformité, avec des cas de rejeu, d'émetteur inattendu, de modes de défaillance et de parcours de repli.
- Séparez la connexion de la signature : décidez des preuves que vous conservez pour chacune, et de qui les valide.
- Faites réaliser une revue indépendante avant la mise en production. Si vous souhaitez de l'aide pour la cadrer, contactez notre équipe de conseil.
