The EUDI Wallet Deadline Is Here: What API Teams Must Build Before December 2026

Un concepteur d’API et spécialiste de l’identité numérique sait qu’il reste peu de temps pour intégrer l’EUDI Wallet avant la date butoir (31 décembre 2026). La réglementation eIDAS 2.0 impose que chaque État membre offre un portefeuille numérique conforme d’ici cette échéance. Pour les équipes API (éditeurs de services publics et privés), cela signifie une course contre la montre : les passerelles d’authentification et d’attestations doivent être construites, testées et validées bien avant la fin 2026, sinon services et obligations de conformité seront compromis. Cet article détaillé se destine aux architectes et développeurs d’API prêts à implémenter aujourd’hui des RP (« relying parties »), émetteurs et vérificateurs compatibles avec l’EUDI Wallet. Nous décrirons l’architecture cible, les protocoles OpenID4VP/OpenID4VCI, les formats de credentials et l’infrastructure de confiance requise, avec des exemples de flux, des tables de décision, des critères de conformité et un plan de déploiement réaliste menant au déploiement avant l’échéance.

1. Le délai de décembre 2026 est un problème de livraison d’API

La loi européenne (eIDAS modifié) impose un calendrier fixe : « Chaque État membre offrira au moins une version du Portefeuille d’Identité Numérique d’ici 2026 ». Ce n’est pas une spéculation marketing, c’est une obligation de service public. Les équipes API doivent traiter 2026 comme une échéance de mise en production finale. Comme pour tout projet API critique, il faut planifier en aval : spécifications claires, découpage par phases (prototype, test, pré-production, production) et vérifications de sécurité. Par exemple, des examens d’architecture et des preuves de concept (Proof of Concept, POC) à court terme (Q4 2024 – Q1 2025) permettront d’identifier les ajustements nécessaires. Ensuite, le développement des flux (OpenID4VP pour présentation, OpenID4VCI pour émission) doit s’achever mi-2026 pour laisser la place aux tests d’interopérabilité et de conformité. L’échéance représente un risque de migration et d’intégration : comme pour un changement de version d’API, il faut veiller à ce que les services existants acceptent les nouveaux jetons et données du portefeuille numérique. En clair, si vous attendez 2025 pour démarrer, vous risquez de manquer la fenêtre de certification.

2. Connaître votre rôle dans l’écosystème du Portefeuille EUDI

Dans l’écosystème EUDI Wallet, plusieurs acteurs coexistent : l’utilisateur (titulaire du portefeuille), le Wallet (appli mobile), l’Émetteur (issuer, qui fournit les attestations), le Vérificateur/Relying Party (RP) qui demande des données, et possiblement un backend de service (voir portail ou app web du RP). Votre responsabilité principale en tant qu’équipe API est celle du Relying Party et de l’intégrateur : vous devez enregistrer le service (voir la sous-section suivante), interagir avec le Wallet via OpenID4VP pour obtenir des attestations, et consommer les API d’émission et de vérification.

Enregistrement, identité et confiance du Relying Party

Le RP doit d’abord s’enregistrer dans l’infrastructure EUDI (implémentation du CIR 2025/848) afin d’obtenir un identifiant et des métadonnées (URI de redirection, JWKS) qu’il publiera dans la liste de confiance. Le RP construit ensuite l’URL d’OpenID4VP (flux de présentation) avec son propre client_id et scope approprié. Lorsqu’un utilisateur revient avec un vp_token (token de présentation), le backend du RP doit vérifier la signature, valider les champs iss, aud, nonce et restituer l’attribut (p. ex. pseudonyme ou attestations) à l’application. À noter que le Wallet authentifiera l’utilisateur (éventuellement en se basant sur l’identité nationale) et engagera le consentement de l’utilisateur avant tout partage. Côté API, prévoyez la gestion d’erreurs OAuth standard (invalid_request, unauthorized_client, etc.) et des réponses d’erreur, par exemple :

HTTP/1.1 400 Bad Request
Content-Type: application/json

{
  "error": "invalid_request",
  "error_description": "Missing required parameter: scope"
}

Pour vous préparer aux rôles d’API, l’article API Developer Roadmap with Python, Node.js, or Go illustre les compétences back-end nécessaires (authentification, versioning, sécurité, etc.). En particulier, la logique métier de votre API RP doit isoler l’identité pseudonymisée de l’utilisateur (quitte à ne jamais manipuler directement l’identifiant national du citoyen) et consommer les attestations reçues du wallet. Les logs générés devront lier l’événement de partage d’attributs au pseudonyme, tout en respectant la vie privée (voir section 11 pour un exemple de journalisation).

Émetteur, Wallet, vérificateur et frontières du backend

La séparation de responsabilités est cruciale. Le Wallet est une application de confiance côté client : il gère les clés cryptographiques du titulaire, présente l’interface de consentement et exécute les flux OpenID en local. L’Émetteur (par exemple, un service d’enregistrement de permis de conduire, un service public ou un fournisseur d’attestations), implémente OpenID4VCI pour émettre des credentials conformes (SD-JWT VC ou mdoc). Le Backend du RP (API du service qui consomme l’identité) reste isolé : il ne connaît ni les méthodes internes du wallet ni le processus complet d’émission, il reçoit uniquement les présentations finales sous forme de JSON signé. Par exemple, un RP santé qui demande un titre de séjour n’a pas besoin d’appeler directement l’émetteur de ce titre ; il se contente de valider le vp_token que le wallet lui renvoie. Cette délimitation rappelle qu’il ne faut pas construire un monolithe tout-en-un. Comme l’illustre le comparatif GraphQL Federation vs Monolithic API, il vaut mieux exposer des services spécialisés (émission, vérification, userinfo) reliés par des API OAuth/OpenID4VCI/OpenID4VP, plutôt que de coupler fonctions disparates dans un seul point d’entrée.

3. Lire l’ARF 3.0 comme un contrat d’implémentation

L’Architecture & Reference Framework (ARF) 3.0.0 (publié juillet 2026) est la bible technique de l’EUDI Wallet. Cette version, alignée sur la réglementation eIDAS (Règlement (UE) 910/2014 modifié par 2024/1183), détaille les exigences et flux indispensables. Il faut le lire comme un contrat d’implémentation : tout ce qui est dit en « DOIT », « SHOULD » dans l’ARF est à considérer sérieusement. Par exemple, l’ARF définit le modèle de confiance et impose que chaque requête passe par les listes de confiance officielles. Il couvre aussi les exigences du RGPD en matière de minimisation des données et les contrôles de conformité fonctionnelle.

Dans la pratique : assimilez dès maintenant l’ARF 3.0.0 en étudiant les sections clés (architecture globale chapitre 4, flux du chapitre 5, confiance du chapitre 6). Par exemple, la section 1.1 rappelle la portée : « L’EUDI Wallet est une application sécurisée, pilotée par l’utilisateur… il permet de demander des informations vérifiées (“attestations”) auprès d’émetteurs de confiance… et de les présenter à des Relying Parties tout en préservant la vie privée ». Chaque paragraphe ARF nourrit votre implémentation : interfaces, métadonnées, profils d’algorithmes, etc. Ne sur-interprétez pas la loi : l’ARF est informatif (non contraignant légalement) mais ses guides sont indispensables pour passer la certification. Pour un parallèle sur la conception d’API, voyez comment des architectes comparent les modèles de communication dans API Design for AI Agents: MCP vs A2A vs OpenAPI. De la même façon, vous devez décider et documenter précisément vos flux de bout en bout.

4. Concevoir le flux de présentation OpenID4VP

Pour que le Wallet présente des attestations au RP, on utilise OpenID4VP (version 1.0, juil. 2025). Il existe deux manières principales de déclencher ce flux :

• Flux de redirection (OpenID Connect) : Le cas classique : votre site RP génère une requête d’authentification OpenID4VP (scope=openid etc.) et redirige l’utilisateur vers l’URL du wallet. Exemple d’URI d’authentification :
  

    GET /authorize?client_id=RP&response_type=vp_token
    &scope=openid%20vp_token
    &redirect_uri=https://rp.example.com/callback
    &state=xyz
    &nonce=abc&dcql_query=...

Le wallet s’ouvre (sur le même appareil ou après scan QR code) et affiche la demande à l’utilisateur. Celui-ci consent alors à partager (via l’interface Wallet) les attestations demandées. Le Wallet renvoie ensuite au RP un token de présentation (vp_token), signé et éventuellement chiffré. Le backend RP récupère le token, vérifie sa signature (voir section 8) puis extrait les claims utiles. Ce mode redirection est mature et compatible avec la plupart des navigateurs et wallets existants. Son inconvénient : sur mobile, l’utilisateur change de contexte entre le navigateur et l’application, d’où des risques de session non liée (voir section 9). Par ailleurs, l’utilisation de schémas d’URI (par ex. openid4vp://) dépend de la prise en charge par le système d’exploitation.

• Digital Credentials API (DCP via navigateur) : Pour les cas cross-device ou besoins d’intégration « dans la page », l’ARF propose d’utiliser la Digital Credentials API du Web (WICG Digital Credentials API). Cette API (encore à l’état de projet de spécification, supportée notamment sur Chrome) permet au navigateur d’appeler directement le wallet du téléphone via le standard navigator.credentials.get(...). Avantages : on gagne en sécurité et UX, car le navigateur transmet l’origine du site et gère le déplacement du contexte entre navigateur et wallet sans URI personnalisées. Par exemple, en JS :

// Exemple illustratif : déclencher le Wallet pour partager un credential
const presentation = await navigator.credentials.get({
  name: 'digital-identity-wallet',
  request: { type: 'openid4vp', query: {/* DCQL JSON */} }
});
// presentation contient le vp_token JSON

Le DCP résout plusieurs défis cités par l’ARF : flux cross-device sécurisés (contact proche Bluetooth), authentification claire de l’origine, et mécanisme intégré de liaison de session entre navigateur et Wallet. En revanche, tous les wallets ne supportent pas encore cette API. Prévoyez donc un mécanisme de repli sur le mode de redirection si DCP n’est pas disponible.

Le choix dépendra du cas d’usage : table de comparaison (flux de redirection et Digital Credentials API)

En pratique, commencez par implémenter le flux standard OpenID4VP (redirection). Ensuite, envisagez progressivement d’ajouter l’API DCP pour les cas compatibles. Chaque approche requiert une gestion correspondante des réponses et des erreurs (par ex. si l’utilisateur ferme le wallet sans partager, renvoyer une erreur access_denied).

Flux de redirection et Digital Credentials API

Pour décider entre les deux, considérez :

• Cas d’usage du service : un portail interne où l’utilisateur travaille toujours sur le même appareil (bureau public, guichet) pourra se contenter de la redirection. Un site grand public (loisirs, tourisme) doit impérativement gérer le cross-device (le citoyen scanne depuis son smartphone), et le DCP peut simplifier ce scénario.

• Niveau de support utilisateur : le DCP est plus élaboré techniquement et peut nécessiter un guide utilisateur (ex. plugin Chrome ou accepter la notification). En revanche, il élimine les URL personnalisées, uniformisant l’expérience.

• Délais réglementaires : l’ARF spécifie les deux possibilités, donc pour votre audit de conformité il faudra au moins un flux fonctionnel. Vous pouvez déclarer DCP comme « SHOULD » et OpenID4VP comme « MUST », ou vice versa, mais ne jamais laisser tous les utilisateurs sur une implémentation non certifiée.

En résumé, implémentez le flux OpenID4VP standard d’abord, puis ajoutez la Digital Credentials API pour améliorer cross-device et sécurité de session. Les deux méthodes doivent finalement converger vers un même modèle de données et de vérification du token reçu.

5. Implémenter l’émission OpenID4VCI sans tout coupler

Quand le RP ou le Wallet doit obtenir un credential (par ex. un permis de conduire numérique, une attestation de diplômes, etc.), on utilise OpenID4VCI 1.0 (final, sept. 2025). Toutefois, ne reconstruisez pas un « monolithe » reliant à la fois authentification, émission et dossier utilisateur. Au contraire, gardez les services découplés.

Le principe : un utilisateur obtient ses credentials via une interaction avec l’émetteur indépendant. Par exemple, une fois identifié par l’administration, le Wallet renvoie chez l’émetteur un authorization request (ou utilise un pre-authorized code). L’émetteur confirme la demande d’émission. Ensuite, le Wallet interroge l’endpoint /token avec le code pour recevoir la ou les attestations (généralement sous forme de SD-JWT VC). Le schéma général :

1. Offre d’attestation (Issuer) : L’émetteur expose un credential offer. Celui-ci peut être « par référence » (URI) ou inclus dans un QR code scanné. L’exemple suivant montre un Credential Offer JSON :

{
  "credential_issuer": "https://issuer.ex",
  "credential_configuration_ids": ["EU_DriverLicense"],
  "grants": {
    "authorization_code": {
      "issuer_state": "eyJhbGciOi...FYUaBy"
    }
  }
}

Cet objet indique au Wallet quel credential demander.

2. Requête d’autorisation : Le Wallet redirige l’utilisateur (ou fait un PAR) vers l’endpoint /authorize de l’émetteur, avec l’authorization_details définissant le type de credential (« openid_credential », ID de configuration) et le redirect_uri du Wallet. L’utilisateur s’authentifie auprès de l’émetteur (ex. login eIDAS) et donne son consentement à recevoir le credential. L’émetteur renvoie un code d’autorisation au Wallet (via redirection).

3. Requête de jeton d’émission : Le Wallet exécute une requête POST vers /token de l’émetteur :

POST /token
grant_type=authorization_code
&code=AUTH_CODE_FROM_PREVIOUS_STEP
&client_id=wallet-client-id
&redirect_uri=https://wallet/app/callback

Il est fortement recommandé d’utiliser PKCE et JAR/PAR pour renforcer la sécurité OAuth. Si vous utilisez un pre-authorized code (flux sans redirection, puisque l’utilisateur a déjà prouvé son identité), le corps sera grant_type=urn:ietf:params:oauth:grant-type:pre-authorized_code&pre-authorized_code=XYZ.

4. Réponse de credential : L’émetteur répond avec un objet JSON contenant le(s) credential(s) délivré(s). Par exemple (format non-normatif) :

{
  "credentials": [
    {
      "format": "openid_4vc_sd_jwt_vc",
      "credential": "<base64-encoded SD-JWT>",
      "authorization": "<JWS binding public key>"
    }
  ]
}

Chaque credential est signé (et peut être chiffré) par l’émetteur. Le Wallet stocke ces credentials pour l’utilisateur.

L’important : ne faites pas du Wallet backend un pont direct vers tous les services internes. Par exemple, n’appelez pas un service métier interne dans /token; l’émission OAuth4VCI se limite au credential. Autrement dit, « sans tout coupler », séparez l’étape authentification de l’utilisateur chez l’émetteur et l’étape envoi des données métier. Le credential émis contient déjà les données validées (p. ex. l’identité, l’attribut permis). Vous devez seulement vérifier cryptographiquement l’attestation (voir H8) et stocker ou utiliser les claims.

Modèle de décision :

De plus, considérez l’orchestration : un pattern Backend-for-Frontend est souvent utile. Par exemple, l’API RP (backend) peut invoquer l’API d’émission après avoir validé l’identité de l’utilisateur via le wallet, plutôt que de laisser tout côté client. Cela simplifie la prise de décision et le logging.

6. Supporter les formats de credential et profils d’algorithmes

L’EUDI ARF exige de prendre en charge les formats de credential prescrits, notamment SD-JWT VC (standard IETF pour JWT à divulgation sélective) et ISO mdoc (mDL), le format pour les permis de conduire mobiles. Les tests de conformité OpenID confirment ce focus : la suite de tests couvre à la fois SD-JWT et mdoc, l’émission SD-JWT étant supportée dès le début (et mdoc prévu bientôt). Vous devez donc être capable de traiter ces formats – par exemple, valider un SD-JWT Verifiable Credential et gérer son liaison de clé JWT (clé du titulaire).

Un petit tableau récapitulatif :

Du côté crypto, adoptez des algorithmes standards modernes : EdDSA (Ed25519) et ECDSA P-256 sont attendus pour les signatures (la liste de confiance utilise des clés publiques dérivées de certificats X.509 conformes à ES256, entre autres). L’ARF et les tests reposent sur ces algorithmes (par exemple le projet de spécification SD-JWT VC utilise EdDSA par défaut). Préparez-vous aussi à gérer des formats chiffrés (JWE) pour les transmissions sensibles. Toutes ces informations se reflètent dans les métadonnées des clients et des émetteurs (voir l’extension de la RFC 8414 pour OpenID4VCI).

Enfin, attention au profil de version : les formats évoluent. ARF 3.0.0 pourrait préciser par exemple ld-JWT ou autres dans les versions futures. Gérez les versions de vos analyseurs en interne pour accepter plusieurs variantes, et testez contre les dernières spécifications. À terme, les listes de confiance fourniront, via le credential_format dans les métadonnées de l’émetteur, les formats pris en charge.

7. Appliquer la divulgation sélective et la minimisation de données

Le cœur de l’approche EUDI est la minimisation des données. Les RP doivent se contenter du strict nécessaire, et le Wallet ne doit partager que ce qui a été explicitement demandé et approuvé par l’utilisateur. Cela s’appuie sur deux piliers : le protocole (DCQL et SD-JWT) et l’UX de consentement.

• Protocole de requête (DCQL) : Dans l’Authorization Request OpenID4VP, le RP spécifie précisément les attributs voulus via le DCQL (par exemple, uniquement le champ age_over_18 d’une attestation de naissance). Le Wallet ne renvoie que ces portions (via mécanisme de salted hash en SD-JWT). Comme le décrit la spécification OpenID4VP, le Wallet récupère les Credentials disponibles, authentifie l’utilisateur et recueille son consentement pour présenter les Credentials requis. Les règles de la RFC SD-JWT indiquent aussi que seuls les claims marqués comme « nécessaires » seront inclus. Implémentez cette logique : les métadonnées de l’issuer et la requête doivent indiquer clairement les claims attendus, et le backend RP doit refuser toute donnée supplémentaire.

L’UX de consentement fait partie de la frontière de sécurité

L’interface utilisateur du Wallet fait partie de la frontière de sécurité. Le Wallet affichera toujours la liste des données demandées et fera approuver chaque item. À nous de concevoir l’API de manière à transférer cette exigence : par ex. en incluant dans les pages du RP un résumé des données demandées (récupérées du token ou des scopes) afin que l’utilisateur comprenne pourquoi il se fait « envoyer » vers le wallet. Par ailleurs, le backend RP doit enregistrer dans ses logs exactement ce qui a été présenté et consenti (champs et valeurs). Un exemple de log structuré :

{
  "event": "data_shared",
  "user_pseudonym": "user123-v2",
  "rp": "exampleservice",
  "claims_requested": ["given_name", "birthdate"],
  "claims_shared": ["given_name", "birthdate"],
  "timestamp": "2026-08-27T11:30:00Z"
}

Enfin, refusez de requérir des données non essentielles. Par exemple, pour vérifier l’âge, demandez juste la date de naissance ou un jeton attestant “plus de 18 ans”. Ceci est explicitement encouragé par la réglementation (principe de privacy by design). Les spécifications précisent : « Le DCQL permet au vérificateur de spécifier les claims qui l’intéressent, laissant le Wallet divulguer uniquement ceux-ci». Toute violation de cette règle (par ex. un wallet ou RP qui extrait plus d’informations) doit être prise comme un incident de sécurité. Nous recommandons d’inclure dans vos tests unitaires des scénarios négatifs où le Wallet reçoit une demande de données et tente d’envoyer plus que nécessaire : le RP doit alors rejeter.

En résumé : le consentement utilisateur est votre pare-feu de privacy. Renforcez l’UX pour qu’on ne peut pas ignorer une demande de partage, et programmez le backend pour qu’il n’utilise que les données explicitement fournies. Ce double contrôle (frontend sécurisé + backend strictement contrôlé) est indispensable pour ne pas violer la RGPD et les règles EUDI.

8. Construire la validation de trust-list, certificats et métadonnées

Pour la confiance des credentials et des clients, l’ARF impose un modèle basé sur les listes officielles. En pratique, cela veut dire que votre API RP doit récupérer et valider les clés publiques depuis les listes de confiance publiées (norme ETSI TS 119 612 pour Portefeuilles et Service Provider, TS 119 602 pour entités). Voici les principales tâches :

• Installation du trust store : Importez les certificats racines des listes de confiance officielles (autorisations d’un wallet ou issuer, eIDAS QWAC, etc.). Par exemple, utilisez les services OCSP/CRL fournis pour vérifier que les clés n’ont pas été révoquées. L’ARF 3.0.0 précise que Wallet, RP et Issuer devront gérer ces trust anchors depuis les listes de confiance (TS 119 612) et les Listes d’Entités (LoTE, TS 119 602).

• Validation d’authenticité : Quand vous recevez un vp_token signé, vérifiez d’abord le certificat ou la clé publique utilisée (via la chaîne PKI) contre vos trust anchors. Par exemple, si le credential est signé selon le profil issu des eIDAS, vérifiez le certificat X.509 de l’issuer avec la chaîne de la liste de confiance. Sinon, s’il s’agit d’une JWK publiée, assurez-vous qu’elle correspond à l’un de vos certificats racines. De même, pour l’OpenID4VCI, validez les client_id et métadonnées de l’issuer via sa discovery.

• Métadonnées OAuth : Chargez les métadonnées du Wallet (AS) et de l’émetteur (serveur d’autorisation) pour connaître leurs points de terminaison. Vérifiez que ces documents proviennent des autorités respectives (utilisez HTTPS + certif. PKI). Concrètement, intégrez un client OpenID Connect qui fait un GET /.well-known/openid-configuration et contrôle que l’émetteur qui y figure correspond bien à la liste de confiance.

• Renouvellement et rotation : Prévoyez un mécanisme pour actualiser automatiquement vos trust anchors et métadonnées (par exemple, une tâche cron qui télécharge les mises à jour des listes ETSI TS 119 612 et TS 119 602 quotidiennement). Documentez ce processus et archivez les versions antérieures pour pouvoir enquêter en cas d’incident.

En résumé, ne faites pas confiance à une clé jusqu’à preuve du contraire : utilisez les listes de confiance comme « annuaire PKI ». Par exemple, si votre RP voit un issuer pour la première fois, vous devez vérifier ce nom dans la liste d’entités approuvées. Tout accès API (authorize, token, callback) doit se faire en TLS avec validation mutuelle de l’identité au moyen d’une validation PKI rigoureuse.

9. Modéliser les menaces sur toute la session Wallet

Il est essentiel de construire une liste de risques (« threat model ») couvrant le parcours complet : du clic initial sur le bouton “Se connecter avec mon Wallet” jusqu’à la fin de la transaction. Voici quelques scénarios clés, illustrés par l’ARF :

Rejeu, phishing, liaison de session et risques cross-device

• Phishing et approbation malveillante : Un attaquant pourrait essayer de présenter une fausse requête au Wallet ou de tromper l’utilisateur pour qu’il approuve sans comprendre (par ex. TR28 dans l’ARF : phishing). Pour s’en prémunir, l’UI du wallet doit toujours afficher clairement le nom du RP et les données demandées. Assurez-vous que le wallet et le navigateur (via DCP ou via une indication) montrent à l’utilisateur le domaine du RP légitime.

• Rejeu (replay) de token : Protégez-vous contre le détournement d’un vp_token. Vérifiez la validité temporelle (iat, exp) et l’unicité (nonce, ou tout autre jeton de session) dans votre backend. Refusez les tokens périmés ou déjà consommés. Les spécs OAuth recommandent l’utilisation de PKCE et de paramètres d’état (state) pour limiter les attaques par interception.

• Attaques « Man-in-the-Middle » (MITM) : Toutes les communications (RP-wallet, RP-émetteur et wallet-émetteur) doivent se faire sur HTTPS/TLS. L’ARF rappelle explicitement de faire des PAR/JAR pour garantir l’intégrité des requêtes. Vos API devraient refuser les requêtes malformées et les certificats non valides. Pensez aussi aux attaques cross-device : par exemple, lors d’un scan QR code, vérifiez que l’adresse fournie est bien celle de l’émetteur ou du RP autorisé (le contenu du QR doit pointer vers l’origine attendue).

• Intrusion dans la session utilisateur : Par exemple, l’ARF signale que l’utilisateur qui interagit avec le RP et celui avec le Wallet pourraient être différents (TR103). Utilisez des mécanismes de liaison de session : dans OpenID4VP même-appareil, le paramètre nonce ou state lie l’authentification au flux. Avec le DCP, exploitez les métadonnées de session embarquées par le navigateur.

• Fuite de données : L’ARF liste plusieurs menaces où un attaquant essaie d’extraire plus d’attributs qu’autorisé (TR29, TR50…). Là encore, limitez strictement votre API à n’ingérer que ce qui est requis. Évitez par exemple que les tests ou logs de développement exposent du PII.

• Perturbation de service : Des requêtes invalides ou répétées (TR76, TR80) pourraient dégrader votre API. Mettez en place du throttling, des validations strictes et des réponses HTTP appropriées (p.ex. 429 Too Many Requests).

• Perte de clés : Prévoyez un plan de rotation de vos clés privées (signature des tokens RP, stockage des clés pre-shared) et d’urgence en cas de compromission. Au minimum, utilisez des HSM (cloud ou hardware) pour isoler les secrets OAuth et TLS.

Pour aborder ces menaces, assurez-vous que vos développeurs possèdent un solide bagage sécurité. Par exemple, une équipe certifiée en sécurité cloud ou en développement sécurisé (voir guide de Refonte sur les certifications cloud) pourra implémenter correctement ces contre-mesures. De plus, la revue de sécurité (audit interne/tiers) doit inclure des tests d’intrusion ciblés sur les endpoints /authorize, /token, et vos propres APIs métier liées au Wallet.

10. Faire des tests de conformité une barrière de sortie (Release Gate)

La conformité technique n’est pas optionnelle. Tout service se réclamant de l’EUDI Wallet devra passer les suites de tests OpenID4VP et OpenID4VCI. L’OpenID Foundation a publié en 2026 des outils gratuits pour s’auto-certifier (OpenID Self-Certification). Voici le processus recommandé :

1. Automatiser les tests – Intégrez les test suites OIDF dans votre pipeline CI/CD. Faites tourner les tests OpenID4VP (présentation) et OpenID4VCI (émission) dès Q3 2026. Ces suites valident la conformité aux specs et profils (y compris SD-JWT et mdoc).

2. Atteindre les seuils : Fixez des critères mesurables avant chaque mise en production : par exemple, « tous les tests critiques OpenID4VP doivent passer à 100 % » et « 100 % des tests fondamentaux OpenID4VCI réussissent ». Puisque les événements d’interop ont montré environ 87 à 98 % de réussite en juin 2025, visez l’excellence en satisfaisant tous les cas normatifs.

3. Corriger et re-tester – Ne publiez pas avant d’avoir corrigé les échecs. Documentez les écarts éventuels. Par exemple, si un Wallet tiers demande des claims ou formats inattendus, ajoutez-les à votre implémentation ou déclarez-les comme non-supportés avec un message d’erreur clair.

4. Sortie de production (exit criteria) – Avant de porter en prod, vérifiez que : tous les tests OpenID4VP/VCI sont passés, que l’architecture réseau (ports, firewall, DNS) autorise les appels vers les endpoints OIDC, et que la liste de confiance est à jour. Utilisez un tableau de critères d’acceptation (ci-dessous).

Traitez ce tableau comme un plan de déploiement agile. Par exemple, à mi-2026, prévoyez une revue de jalon : tous les tests passés sur un environnement de pré-prod, rapport de tests documenté (pas seulement « OK ») et version candidate prête. Ne laissez pas de tests facultatifs (par ex. émetteurs non utilisés dans votre pays) bloquer la mise en production ; concentrez-vous sur les tests critiques à votre profil d’organisation (le HAIP 1.0 n’est pas nécessairement indispensable, par exemple).

11. Définir contrats d’API, erreurs, journaux et preuves d’audit

Une intégration robuste passe par des contrats API clairs et une bonne instrumentation. Voici quelques artefacts conseillés :

• Contrats et modèles de données : Documentez les endpoints OpenID4VP (authorize, token) et OpenID4VCI de votre RP. Par exemple, décrivez en pseudo-API REST :
  

  POST /token
  Content-Type: application/x-www-form-urlencoded
  # paramètres requis
  grant_type: "authorization_code"
  code: (string)
  client_id: (string)
  redirect_uri: (string)

Listez les erreurs possibles (code HTTP 400/401, code OAuth invalid_grant, consent_required, etc.) et leurs significations. Pour la Digital Credentials API, spécifiez le payload JS (comme montré plus haut). Un exemple d’erreur JSON d’OpenID4VCI peut être :

{
  "error": "invalid_request",
  "error_description": "Missing credential_offer_uri"
}

• Formats de logs et données d’audit : Prévoyez de tracer chaque étape critique. Par exemple : authentification de l’utilisateur (ID de session vs pseudonyme), requête d’autorisation envoyée au wallet (URI, timestamp), réponse reçue, identifiants de transaction uniques. Utilisez un format structuré (JSON) avec un champ event et horodatage standardisé. Exemple de ligne (production) :

{
  "timestamp": "2026-08-27T15:45:00Z",
  "event": "auth_response_received",
  "user_pseudonym": "xyz-123",
  "service": "my-finance-app",
  "claims_returned": ["birthDate", "nationality"],
  "client_ip": "203.0.113.45"
}

Ce type de log facilite l’audit (vérifier qui a vu quoi). En complément, enregistrez les réponses d’erreur (IP, agent utilisateur) pour diagnostiquer les anomalies ou attaques. Assurez-vous que les journaux sensibles restent chiffrés au repos et en transit et ne contiennent pas d’informations d’authentification brutes.

• Exemples de réponses d’API : Fournissez un petit exemple JSON de présentation (vp_token) pour aider les développeurs back-end à les analyser. De même, une réponse de token d’émission. Cela clarifie le schéma de données attendu.

En bref : standardisez vos contrats comme vous le feriez pour n’importe quelle API d’entreprise, mais incluez les paramètres OpenID spécifiques (client_id, redirect_uri, scope, etc.) et les objets métier (credentials JSON) définis par l’ARF. Fournissez une couverture de tests unitaires de ces contrats (tests d’invalidité, d’erreurs OAuth, etc.).

12. Planifier les profils et dérives par État membre

Exigences locales sans forker la plateforme

L’ARF fournit la « baseline » EUDI, mais chaque pays pourra ajouter des exigences locales (ex. attributs nationaux, profils de HSM, règles légales). Pour éviter de forker la plate-forme, adoptez une architecture modulable :

• Configurations par profil : Conservez un cœur d’API commun et injectez les différences via configuration. Par exemple, supportez plusieurs scopes ou claim_sets selon le pays (une config YAML/XML « attributs requis FR », « attributs ES », etc.). Vos règles métiers peuvent charger dynamiquement le schéma d’attestation local.

• Extensions gérées : Si un État exige des formats additionnels (ex. un OID issu d’une attestation particulière), implémentez-les comme modules ou microservices séparés, pas dans le cœur. Par exemple, ajoutez un module “eID belge” qui valide les certificats spécifiques belges, sans perturber le chemin principal.

• Versioning et compatibilité : Définissez un schéma de version d’API (par ex. v1, v2) pour vos endpoints, afin de pouvoir introduire de nouvelles fonctionnalités spécifiques (et lire des documents ou profils plus récents de l’ARF) sans casser les clients existants. De même, versionnez vos métadonnées OIDC (métadonnées du client RP), car les autorités nationales peuvent demander des attributs supplémentaires (pseudonymes, mécanismes FIDO, etc.).

• Synchronisation EUDI-Local : Créez un canal de veille (par ex. une veille GitHub sur le dépôt ARF) pour suivre les évolutions des Rulebooks locaux (ex. Rulebook PID, mDL) et mises à jour du CIR. Planifiez de courts cycles d’intégration (par exemple, chaque trimestre en 2025-2026, réviser la conformité aux nouvelles exigences) sans repartir de zéro.

Voici un extrait de plan d’implémentation par onde de déploiement :

Chaque membre de l’équipe doit avoir des tâches claires (par exemple une équipe backend OAuth, une équipe sécurité PKI, une équipe front-end UX wallet). Le plan ci-dessus peut être détaillé dans votre backlog Agile, avec des User Stories pour les cas d’usage (ex. « En tant que RP, je veux obtenir les attestations minimales d’un citoyen via mon Wallet »). Au besoin, un outil de gestion de projet affichant ce planning (chronologie ou kanban) est recommandé.

13. Construire, acheter ou sous-traiter : peser les options

Une fois le cahier des charges posé, décidez du mode de réalisation :

• Construire en interne : Si votre équipe maîtrise OAuth 2.0, OpenID Connect, la sécurité Web et eIDAS, le développement interne garantit la personnalisation et l’indépendance, au prix d’un délai plus long. Travaillez par itérations, du MVP aux fonctions avancées. Prévoyez une formation approfondie sur OAuth 2.0 et OpenID, puis conservez un backlog de sécurité pour corriger les écarts révélés par les tests.

• Acheter ou préconfigurer : Plusieurs solutions prêtes à intégrer, commerciales ou open source, commencent à émerger. Vous pouvez évaluer une implémentation de référence ou une solution déjà testée. Les avantages sont le gain de temps et l’accès à une expertise spécialisée ; les inconvénients sont le coût et la dépendance. Vérifiez dès le départ si la solution fournit des résultats d’auto-certification OIDF, prend en charge SD-JWT VC et mdoc, et documente ses flux OAuth. Conservez aussi la capacité de la personnaliser et évitez les boîtes noires.

• Sous-traiter une API Gateway ou des tests : Par exemple, vous pouvez intégrer un fournisseur de services GRC/API qui a déjà un trust store à jour et des modèles d’API eIDAS. Cela simplifie le déploiement, mais attention à la chaîne de responsabilité. Même si le prestataire tiers « gère » le portefeuille pour vous, vous restez responsable de la conformité réglementaire. Demandez-leur de vous fournir les logs et une preuve de test (audits, rapports d’auto-certification).

• Envisager des approches hybrides : Par exemple, utilisez une bibliothèque ou un microservice d’analyse SD-JWT (par exemple, le SDK SD-JWT de MATTR) et déployez votre propre façade OAuth. Vous pouvez aussi externaliser l’interface du Wallet (par exemple, un composant React) tout en conservant les backends en interne.

Table de décision :

Le choix dépendra de votre contexte (taille de l’équipe, budget, priorités). Dans tous les cas, il est préférable de commencer dès que possible le prototypage plutôt que d’attendre la « version finale » des standards. Des implémentations précoces (même en test) vous permettront de déceler tôt les ajustements à prévoir (ex. impératifs nationaux spécifiques ou limitations de certains wallets).

14. Exécuter un plan d’implémentation piloté par la date butoir

Pour tenir le délai, planifiez de façon rigoureuse. Voici les premiers pas immédiats :

1. Formation et montée en compétences (jusqu’en Q1 2025) : Assurez-vous que l’équipe connaît bien OAuth2/OpenID (par ex. formateurs externes ou cours en ligne). Un point important : créez un glossaire interne (RP, Issuer, Proof-of-Possession, SD-JWT, etc.) pour éviter les confusions.

2. Mise en place d’un environnement de test EUDI (fin 2024) : Déployez une sandbox interne avec un OP RP factice et un identifiant test (par exemple, un serveur Keycloak avec plugin VCIssuance). Apprenez à générer un credential vérifiable SD-JWT pour vos propres tests. Cela servira à valider vos premiers flux OpenID4VP et OpenID4VCI.

3. Découverte ARF + Documentation (Q1 2025) : Parcourez en détail l’ARF 3.0.0, en vous concentrant sur le chapitre 6 (confiance) et les annexes (formats). Mettez en place un document de conception référençant les sections ARF pertinentes (par exemple, « Annexe 3.02 – mDL : format ISO 18013-5 pour permis de conduire »).

4. Prototype de flux 4VP (Q2 2025) : Codez rapidement un flux minimal RP à wallet, juste pour valider : rediriger vers un Wallet de démonstration, renvoyer un vp_token valide. Identifiez et documentez tout écart (API manquantes, champs non supportés, etc.).

5. Sélection d’une solution Wallet / émission : Selon votre décision de construire ou d’acheter, commencez le choix d’un produit wallet ou d’un partenaire SSI compatible. L’idéal : un wallet déjà certifié OpenID4VP 1.0 et OpenID4VCI 1.0.

6. Roadmap complète 2025–2026 : Décomposez les tâches par trimestre comme suggéré en section 12. Assignez des jalons clairs (ex. « M3 2026 : test d’auto-certification OpenID4VCI OK », « M6 2026 : démo interne réussie avec un wallet du marché »). Utilisez un outil de gestion de projet pour suivre avancement et dépendances. Conservez les contrats d’API, rapports de conformité, matrices de menaces et journaux de décision pour constituer un portfolio tech prêt pour l’emploi fondé sur des preuves d’implémentation.

En résumé, commencez par la formation et la preuve de concept, puis établissez une liste de contrôle mesurable : OpenID4VP, OpenID4VCI, liste de confiance et tests unitaires.

Les systèmes doivent être prêts avant fin 2026. Priorités : maîtriser OpenID4VP, OpenID4VCI et l’ARF 3.0 ; valider un prototype de bout en bout par les tests de conformité ; instaurer une gouvernance avec responsable sécurité, calendrier et critères de sortie. Le point critique reste la liaison de session : aucun partage sans consentement explicite et aucune présentation hors de la transaction attendue. Le Refonte Learning APIs Developer Program renforce les bases utiles en conception d’API, authentification, autorisation, versioning, tests, journalisation et sécurité. Vérifiez le contenu en vigueur pour toute couverture explicite d’OpenID4VP, OpenID4VCI, HAIP ou de l’EUDI Wallet. La ressource pour choisir le meilleur stage tech virtuel aide aussi à évaluer une montée en compétences pratique.