Attestations eIDAS (Jinnove / Certigna)

Note

Blockchain retirée depuis v1.3. SESHAT n’utilise plus EAS / Base L2. Les colonnes eas_uid / tx_hash du ledger sont conservées en lecture pour les données historiques. L’ancrage qualifié passe désormais par Jinnove (Certigna, eIDAS QTSP).

Architecture des attestations

SESHAT produit des preuves en deux couches indépendantes :

Couche	Activation	Ce qu’elle prouve
Sceau local	Toujours actif	SHA-512 + date d’insertion SQLite. Preuve interne.
Certificat eIDAS	IP_SECURE_API_KEY configuré	Horodatage qualifié Certigna. Preuve juridiquement opposable aux tiers.

Jinnove / Certigna

Jinnove est la plateforme IP Secure qui orchestre l’ancrage. Elle utilise Certigna comme QTSP (Qualified Trust Service Provider) inscrit sur la Trusted List européenne (EUTL) — le même niveau de confiance qu’une signature qualifiée d’avocat ou de notaire électronique en droit européen.

Le certificat résultant :

• Est conforme au Règlement UE 910/2014 (eIDAS)
• Inclut un timestamp qualifié RFC 3161 émis par Certigna
• Est vérifiable sans SESHAT (les standards PKI suffisent)
• Reste valide même si Jinnove ou SESHAT cessent d’exister

Cycle de vie d’une attestation

1. Contenu créé

   Vous écrivez du code, des notes, mergez une PR.

2. Hash calculé localement

   SESHAT calcule l’empreinte SHA-512 du contenu. Ce hash n’est jamais transmis en clair — seule l’empreinte part vers Jinnove.

3. Contribution soumise à Jinnove

   SESHAT envoie la contribution (fingerprint, métadonnées, catégorie) à l’API Jinnove via HTTPS signé.

4. Certigna horodate

   Jinnove transmet à Certigna qui applique un timestamp qualifié et génère le certificat eIDAS.

5. Ledger SQLite mis à jour

   L’ipsecure_contribution_id est stocké — c’est la source de vérité sur l’ancrage.

6. Certificat récupéré

   Le certificat (ipsecure_certificate_url) est disponible quelques minutes après via fetch_certificate. Il est ensuite persisté dans le ledger.

Comportement asynchrone

Jinnove génère le certificat en arrière-plan. À l’instant T du scellement, ipsecure_certificate_url est null. Pour le récupérer :

Récupère le certificat eIDAS pour l'entrée ledger #42

L’outil fetch_certificate interroge Jinnove et persiste l’URL si le certificat est prêt. Statuts : ready, already_persisted, pending, not_configured.

Vérification d’une attestation

# Recompute the SHA-512 fingerprint
shasum -a 512 votre-fichier.pdf

# Compare with the stored fingerprint
seshat verify votre-fichier.pdf

# The certificate URL points to the eIDAS document
# No SESHAT installation needed for verification

Astuce

Le certificat Certigna est auto-porteur : un auditeur peut vérifier son authenticité avec les outils PKI standard (openssl, Adobe Acrobat, etc.) sans aucune dépendance à SESHAT ou Jinnove.

Sans IP Secure

Sans IP_SECURE_API_KEY, SESHAT fonctionne en mode souverain local :

• SHA-512 + ledger SQLite uniquement
• Pas de certificat tiers
• Suffisant pour preuve interne (audit, contentieux entre parties qui font confiance au ledger)
• L’ipsecure_contribution_id reste null

Ce mode est le défaut — l’eIDAS est une option, pas un prérequis.