§ Transparence

Ce que nous publions sur nous-mêmes

Les receipts Tessaliq permettent à un tiers de vérifier ce qui s'est passé pour une vérification donnée. Cette page vise à couvrir la vue complémentaire — ce qui se passe à travers toutes les vérifications (volume, taux de conformité, latence, quels wallets interagissent avec le vérifieur, quelles erreurs apparaissent) — afin qu'un auditeur, un RP ou un lecteur curieux n'ait pas à se fier sur parole à ce que Tessaliq dit de son propre fonctionnement.

Rapport inaugural — Q2 2026

La première snapshot trimestrielle est visée pour début juillet 2026, couvrant avril-juin 2026. Le dashboard lui-même est en construction — cette page liste pour l'instant ce que le rapport contiendra et ce qu'il ne contiendra pas, afin que l'engagement soit public avant les données.

Document de cadrage : spec receipt §8, runbook interne docs/ops/observability.md.

Ce que le rapport contiendra

Volume de vérifications — total de sessions ayant atteint un état terminal (verified ou failed) sur la période, par format de credential (mdoc / SD-JWT-VC) et par environnement (production / staging).
Taux de conformité — part des sessions qui ont atteint verified vs celles qui ont échoué avec une classe d'erreur connue. Publié en absolu, pas comme claim marketing.
Répartition des classes d'échec — quand les sessions échouent, dans quelle classe (signature invalide / trust chain inconnue / policy non satisfaite / credential expiré / nonce rejoué / erreur format / autre).
Percentiles de latence — p50 et p95 de la durée complète /v1/sessions/:id/proof sur la période.
Couverture wallets — quels wallets / IACAs d'issuer ont émis au moins un credential que le vérifieur a accepté pendant la période, listés par subject IACA.
Commentaire trimestriel — issues d'interop rencontrées (anonymisées), non-conformances credential détectées, changements de support de version de spec (OID4VP / HAIP / DCQL), événements de sécurité le cas échéant.

Ce qui n'apparaîtra jamais dans ce rapport

Répartition par Relying Party. L'agrégation se fait au niveau du verifier entier, pas par tenant. Le trafic d'un RP ne doit pas être inférable depuis notre publication.
Identifiants par session. Session IDs, request IDs, organisation IDs n'apparaissent jamais dans les chiffres publics.
Attributs wallet user. Aucun n'est dans nos logs au départ (double anonymat ARCOM par construction), mais ça vaut la peine de le rappeler comme politique publiée.
Données temps réel. La page est une snapshot, rafraîchie à la cadence de reporting. Pas de feed live, pas de stream par événement. Réduire la surface d'attaque sur le endpoint d'observabilité lui-même est volontaire.
Adresses IP, user agents. Redactés des logs, jamais agrégés pour publication.

Règles d'anonymisation

Une classe d'échec avec moins de 10 événements sur une période est fusionnée dans « autre » plutôt que publiée séparément. Empêche l'inférence de patterns à faible population.
La couverture wallet est listée par subject IACA, pas par nombre de sessions par IACA. Empêche le classement de l'adoption wallet.
Les percentiles de latence sont dérivés sur au moins 1 000 sessions, ou reportés comme « échantillon insuffisant » sinon.

Cadence

Q2 2026 (rapport inaugural) — publié début juillet 2026, couvrant avril-juin 2026.
À partir de Q3 2026 — trimestriel, première semaine du trimestre suivant.
Notices de sécurité ponctuelles — publiées immédiatement si une rotation de clé ou une vulnérabilité vérifiée affecte le modèle de confiance, sans attendre le trimestriel.

Vérifier les receipts par vous-même, par programme

La librairie @tessaliq/receipt-verifier (sous licence MIT, source sur GitHub) permet à n'importe quel tiers — auditeur, régulateur, RP, développeur curieux — de vérifier cryptographiquement un receipt JWT Tessaliq sans coordination avec nous. La librairie ne lit que l'endpoint public et non authentifié /.well-known/jwks.json, et supporte une utilisation complètement air-gapped via un JWKS pré-fetché.

Trois lignes de TypeScript :

import { verifyReceipt } from '@tessaliq/receipt-verifier'

const result = await verifyReceipt(receiptJwt)
if (result.valid) console.log(result.claims)

La spécification du format receipt (v1.0-draft) documente chaque claim, les garanties cryptographiques (§8) et les limitations connues (§9). Elle est la source de vérité que la librairie et le signer Tessaliq implémentent en parallèle. Le CHANGELOG trace chaque évolution. Le package passera de 0.1.0-draft à 1.0.0 une fois qu'un run end-to-end avec un vrai wallet aura été vérifié à travers la librairie (cf. spec §10).

Pas encore sur npm — la publication est conditionnée à l'immatriculation Tessaliq. En attendant, installation possible via dépendance git ou clone-and-link, comme documenté dans le README du package.

Pourquoi cette page existe

La plupart des produits vérifieurs renvoient un booléen oui/non sur un appel API et conservent les logs de leur côté. Quand un auditeur demande une preuve, le vérifieur fournit un extrait — ce qui fait reposer l'audit sur l'exactitude de ces logs. Publier des métriques agrégées à cadence fixe est une façon de réduire la part de l'audit qui dépend uniquement de la parole du vérifieur.

Le receipt par vérification et ce dashboard trimestriel sont les deux surfaces qui permettent à un tiers de reconstruire la piste d'audit à partir de la cryptographie et des agrégats publiés, plutôt qu'à partir d'un accès direct aux logs internes de Tessaliq.