Préparer une application web à l'e-ID suisse
L'e-ID a du retard. Ce qu'une application web recevra d'un wallet, ce qu'il faut changer dès maintenant dans votre modèle de comptes, ce qu'offre la sandbox.
La Suisse a voté pour une identité électronique étatique, et la Confédération la construit. Le 30 juin 2026, l'Office fédéral de la justice a repoussé le lancement, prévu pour le second semestre de cette année, sans nouvelle date : celle-ci sera annoncée une fois que d'autres travaux de sécurité, notamment contre les deepfakes et les logiciels malveillants, seront en grande partie terminés. L'infrastructure de confiance qui la porte, appelée swiyu, suit son propre calendrier et devrait fonctionner au premier semestre 2027. Si votre application sert des clients suisses, la question « peut-on se connecter avec l'e-ID ? » arrivera avant l'e-ID. Voici ce que la réponse implique, et ce qui peut être fait avant l'une ou l'autre date.
Ce que vous remet un wallet
L'e-ID n'est pas un fournisseur de connexion. Personne n'est redirigé vers une page de l'administration pour en revenir avec un token. C'est un justificatif dans une application de wallet sur le téléphone, et le flux est une présentation : votre application demande des attributs précis, le wallet montre à la personne ce qui est demandé, la personne accepte, et le wallet envoie une présentation signée. De votre côté, vous vérifiez trois choses : la signature de l'émetteur sur le justificatif, la preuve que ce wallet le détient, et le fait qu'il n'a pas été révoqué.
Les formats sont publics et n'ont rien d'exotique. Les justificatifs sont des SD-JWT VC : un JSON Web Token dans lequel chaque attribut divulgable séparément est remplacé par un condensé, ce qui permet au wallet de révéler le nom de famille sans la date de naissance. Émetteurs et vérificateurs sont identifiés par des DID du type did:webvh, publiés dans un registre de base que gère la Confédération. La vérification passe par OpenID4VP 1.0, une requête et une réponse, avec un langage de requête, DCQL, qui nomme les attributs voulus. La révocation passe par une token status list, signée par l'émetteur et hébergée dans le même registre. Qui a déjà implémenté OpenID Connect trouvera les formes familières et les détails nouveaux.
Ce que vous recevez, et ce que vous ne recevez pas
Vous recevez les attributs que vous avez demandés et que la personne a acceptés : un nom de famille, des prénoms, une date de naissance ou, si le justificatif le prévoit, seulement le fait que la personne a plus de 18 ans. Vous ne recevez pas d'adresse e-mail, parce que l'e-ID n'en contient pas. Vous ne recevez ni mot de passe, ni session, ni fiche utilisateur ; tout cela, c'est à vous de le créer.
Ce seul fait façonne le modèle de données. Une application qui identifie les gens par leur adresse e-mail doit apprendre qu'une personne peut arriver avec un nom vérifié et aucune adresse, et que deux personnes peuvent avoir le même nom et la même date de naissance. Quel attribut permettra de reconnaître la même personne la fois suivante, le protocole vous laisse le décider, et cela mérite du soin. Si le justificatif propose un numéro personnel, un identifiant qui suit la personne dans tous les autres systèmes est plus que ce dont une connexion a besoin ; vérifiez ce que la loi permet avant d'en stocker un.
Ce qu'il faut avoir prêt
- Une place pour un identifiant externe à côté de l'adresse. Un compte peut avoir zéro ou plusieurs identités liées ; l'e-ID en serait une, à côté d'une passkey et de « connecté avec Google ». Si votre table d'utilisateurs a une seule colonne
emailet un hash de mot de passe, c'est là qu'il faut changer. - Une distinction entre ce que la personne a saisi et ce qui a été vérifié. Un nom de famille vérifié vaut plus qu'un nom saisi, et vous voudrez savoir plus tard lequel est lequel, pour une signature, un contrat ou un contrôle d'âge.
- Une règle de step-up. La plus grande partie d'une application n'a pas besoin d'une identité vérifiée ; un paiement, une signature ou un changement de compte bancaire, peut-être. Décidez avant l'arrivée de l'e-ID quelles actions l'exigeront et lesquelles se contentent d'un mot de passe, pour que ce soit une règle et pas un débat à chaque fonctionnalité.
- Un moyen de lier un compte existant. Vos clients ont déjà des comptes. La première connexion avec l'e-ID doit proposer « c'est moi, liez-le » plutôt que de créer un doublon.
- Une autre voie pour tous les autres. L'e-ID est facultative, un complément à la carte d'identité. Chaque action qui la demande doit offrir un autre chemin aux personnes qui ne l'ont pas.
Rien de tout cela n'exige que l'e-ID existe. Tout cela est plus facile avant que le premier client ne pose la question.
Ce qu'on peut essayer aujourd'hui
La Confédération exploite une sandbox, un environnement de test de l'infrastructure de confiance, sans limite de participants. Elle publie des logiciels de référence : un vérificateur générique et un émetteur générique, prêts à tourner, et une DID toolbox pour les clés. L'application swiyu Sandbox Wallet contient des identités de test, parmi lesquelles une Beta-ID, qui a les caractéristiques techniques de la future e-ID et aucune valeur juridique.
Une vérification qui fonctionne demande quatre étapes de mise en place : installer le wallet de la sandbox, enregistrer votre organisation sur le portail swiyu, générer des clés et un DID avec la toolbox, et lancer le vérificateur générique. Ensuite, vous créez une vérification via son API de gestion avec une requête DCQL, vous transformez le deep link qu'elle renvoie en code QR, vous le scannez avec le wallet, et vous interrogez le vérificateur jusqu'à ce qu'il ait un résultat. Le cookbook de la Confédération décrit chaque étape. Ce qui revient est exactement ce que votre modèle de comptes devra accueillir, ce qui en fait une revue de conception bon marché.
Où en est EAuth
EAuth ne prend pas en charge l'e-ID aujourd'hui, et je ne donnerai pas de date pour une chose dont la propre date n'est pas fixée. Ce qui existe, c'est de la préparation : une conception écrite et les lectures derrière cet article. L'intention, et non un engagement, est qu'une application sur EAuth reçoive l'e-ID par la connexion OpenID Connect qu'elle utilise déjà, sans faire tourner de vérificateur à elle. Quand il y aura quelque chose à essayer, la documentation et ce journal le diront.
D'ici là, le travail décrit plus haut est le même, quel que soit celui qui vérifiera la présentation au bout du compte, et rien de tout cela n'attend Berne.
Sources
- Neuer Zeitplan für die Einführung der E-ID und der Vertrauensinfrastruktur, Federal Office of Justice, consulté le
- Sandbox, Swiss Confederation, consulté le
- Technology Stack, swiyu technical documentation, Swiss Confederation, consulté le
- How to integrate the swiyu Generic Verifier, Swiss Confederation, consulté le
- OpenID for Verifiable Presentations 1.0, OpenID Foundation, consulté le
- RFC 9901: Selective Disclosure for JSON Web Tokens, IETF, consulté le
Écrit par Samuel Krauss, Founder. Classé sous e-id, swiyu, identity, switzerland, eauth.
Traduit de l’anglais. Lire l’original anglais