Conformance et standards

Toutes les spécifications implémentées par Tessaliq, avec un lien vers leur version publique, ainsi que les résultats de tests externes publiquement vérifiables.

Choix architectural — vérifier, jamais stocker

Tessaliq repose sur un invariant : le vérificateur ne stocke jamais de données d'identité personnelles. Ni hash, ni dérivé, ni cache « au cas où ». Le vérificateur reçoit une présentation cryptographique du portefeuille, la contrôle contre la politique, émet un reçu signé, puis écarte le contenu de la présentation.

C'est un choix délibéré, pas une feature. Une base serveur contenant des informations identifiantes est, par construction, un point unique de compromission. Quand elle est attaquée, tous les enregistrements qu'elle détient sont exposés d'un coup — l'opérateur n'a pas eu besoin de les utiliser à tort, l'attaquant l'a fait à sa place. Chaque trimestre apporte un nouvel exemple. La réponse architecturale, c'est de ne pas construire la base en premier lieu.

Un vérificateur adossé à un portefeuille EUDI élimine ce vecteur. Il n'y a pas de base d'identité centrale à compromettre chez Tessaliq. Le credential de l'utilisateur reste dans son portefeuille ; seul l'attribut dérivé demandé par la partie relyante (par exemple age_over_18 : true) transite sur le réseau ; le reçu signé scelle le fait de vérification sans le contenu identifiant. Une compromission du vérificateur exposerait au pire le catalogue de politiques et des métadonnées de session (identifiants, horodatages) — aucune ne permet d'identifier un utilisateur.

C'est la même propriété qui rend possible la vérification hors-ligne des reçus : n'importe quel tiers peut auditer un reçu via le JWKS public, sans accès à une base d'identité centralisée. Voir le vérificateur interactif pour l'essayer.

Protocoles

• OpenID for Verifiable Presentations 1.0 Final — côté vérificateur
  Spécification
• High Assurance Interoperability Profile (HAIP) 1.0 Final
  Spécification
• W3C Digital Credentials API — parcours Chrome et Safari
  Working draft

Formats de credentials

• ISO/IEC 18013-5 — mdoc / permis de conduire mobile, vérification du session transcript
  Partie du blueprint européen de vérification d'âge.
• ISO/IEC 18013-7 1ed — présentation en ligne d'un mDL ISO/IEC 18013-5.
• SD-JWT-VC — draft IETF, divulgation sélective avec key-binding JWT optionnel
  Draft IETF
• eu.europa.ec.av.1 — profil européen de vérification d'âge
  Blueprint publié par la Commission européenne pour les sept États pilotes (France, Danemark, Grèce, Italie, Espagne, Chypre, Irlande).

Cryptographie

• RFC 9180 HPKE — Hybrid Public Key Encryption, ECDH-ES + AES-128-GCM / AES-256-GCM, courbe P-256.
• JWE — JSON Web Encryption pour le wrapping des réponses Digital Credentials API.
• ES256 — signatures ECDSA P-256 pour les reçus et la signature JAR.
• X.509 SAN DNS / X.509 hash — deux schémas de client ID prefix pour l'authentification JAR OID4VP.
• Noir / Barretenberg — preuves zero-knowledge pour la vérification d'âge (alpha).

Conformance OpenID Foundation

Tous les plans sont immutables et publiquement accessibles sur le site de certification de l'OpenID Foundation. Cliquer sur un plan ouvre la liste complète des modules avec leur statut.

Total : 24/24 modules passés, zéro warning, couvrant la matrice 2×2 SD-JWT-VC + mdoc × standard + HAIP.

Déclaration d'auto-certification

L'OpenID Foundation a lancé l'auto-certification pour OpenID4VP 1.0, OpenID4VCI 1.0 et HAIP 1.0 le 26 février 2026. Tessaliq s'auto-certifie conforme sur les quatre plans listés ci-dessus. Les plans sont immutables et vérifiables indépendamment sur la plateforme de test de l'OpenID Foundation — n'importe qui peut cliquer un lien de plan, lire la liste des modules, et confirmer le statut pass/fail sans nous contacter.

Tessaliq n'a pas encore soumis les plans à la revue formelle de la Foundation (étape qui implique des frais par spécification et qui est prévue après la création de la SASU). La déclaration d'auto-certification repose sur les plans immutables publiquement vérifiables.

Vérification de receipt

Chaque vérification renvoie un receipt JWT signé qui peut être contrôlé cryptographiquement par un tiers — un auditeur, un RP, un régulateur — en utilisant uniquement le endpoint JWKS public. Pas besoin d'appeler l'API Tessaliq.

• Spécification du receipt — format, claims, signature, procédure de vérification, garanties et limitations.
  Spec v1 draft
• Librairie de vérification open-source — @tessaliq/receipt-verifier, MIT, utilisable hors-ligne.
  Code source
• Vérification interactive — collez ou déposez un receipt JWT et contrôlez-le dans votre navigateur.
  Vérifier un receipt ↗

Déclarations de finalité et base légale (DPV)

Chaque policy Tessaliq porte une déclaration W3C Data Privacy Vocabulary lisible par machine : finalité, base légale, rétention. La déclaration est exposée sur GET /v1/policies pour que les auditeurs puissent découvrir la posture privacy de chaque policy sans exécuter le verifier, et embarquée en JSON-LD dans chaque receipt signé pour que la posture soit cryptographiquement attestée à chaque vérification — pas une promesse en texte libre sur une page privacy.

Défauts Tessaliq : rétention P0D (zéro rétention par design), base légale LegalObligation (la relying party précise quelle obligation elle invoque — typiquement ARCOM SREN pour vérification d'âge, ou AMLR Art. 24 pour identité). Les relying parties peuvent surcharger en configurant leur policy.

Cadres réglementaires

• Règlement (UE) 2024/1183 — eIDAS 2.0, amendant le règlement eIDAS pour le cadre européen d'identité numérique.
• Règlement d'exécution (UE) 2025/848 — règles détaillées pour les registres nationaux des relying parties (article 5c(8)).
• Règlement d'exécution (UE) 2026/798 — onboarding à distance des utilisateurs vers les portefeuilles européens.
• Blueprint européen de vérification d'âge — profil `eu.europa.ec.av.1`, adopté par sept États pilotes (FR, DK, GR, IT, ES, CY, IE).
• Loi SREN (France) — cadre de vérification d'âge pour l'accès aux contenus adultes en ligne, supervisé par l'ARCOM.

Contributions externes

Consultation publique ENISA sur le schéma de certification cybersécurité EUDIW — position paper soumis le 2026-04-17 sur le draft scheme v0.4.614 et les security requirements v0.5.614 (deadline 30 avril 2026). Trois recommandations autour de l'exclusion du scope des relying parties (Annexe X, Note X.2.1, p. 91) et de la menace de collusion (TR84).