OVELIYA · Scellé

Protocole OVELIYA-SCELLE v2

Spécification de vérification — figée · version 2 · publiée le 29 juin 2026

Ce document décrit, de façon stable et autonome, comment vérifier l'authenticité d'un Scellé OVELIYA. Il est volontairement minimal : un tiers peut réimplémenter la vérification à partir de cette seule page, sans accès au code d'OVELIYA. Une version donnée du protocole ne change jamais ; toute évolution porte un nouveau numéro.

1 · Ce qu'un Scellé atteste

Un Scellé est une signature cryptographique apposée par OVELIYA sur trois éléments : un identifiant, une empreinte du contenu, et une date. La vérification établit deux choses : que la signature provient bien de la clé d'OVELIYA, et que ces trois éléments n'ont pas été modifiés depuis. Elle n'établit pas, à elle seule, l'identité du détenteur ni la valeur juridique du contenu.

2 · Message signé

Le message signé est une chaîne de caractères UTF-8, dont les champs sont séparés par une barre verticale | :

OVELIYA-SCELLE|v2|<proof_id>|<document_hash>|<signed_at>

3 · Empreinte du contenu (recalculable)

À partir du protocole ovd-content-1, le document_hash est l'empreinte SHA-256 d'une forme canonique du contenu — sans aucun horodatage. N'importe qui possédant le contenu peut donc la recalculer à l'identique, sans dépendre d'OVELIYA. La recette :

  1. Construire l'objet { v:"ovd-content-1", profile, tier, answers, decision } où answers est la liste ordonnée des réponses ; chaque texte (réponses et décision) est découpé de ses espaces de bord (trim).
  2. Sérialiser en JSON canonique : clés de chaque objet triées par ordre alphabétique, sans espace superflu (voir la fonction canonicalJSON du vérificateur hors-ligne).
  3. Calculer le SHA-256 des octets UTF-8 de cette chaîne → document_hash.

Variante ovd-content-2 — ancrage d'identité (optionnel). Si le porteur a déclaré un ancrage d'identité, l'objet canonique devient { v:"ovd-content-2", identity, profile, tier, answers, decision }, où identity est l'identifiant déclaré, découpé de ses espaces de bord. L'ancrage est déclaratif : OVELIYA ne vérifie pas que le porteur contrôle cet identifiant ; il garantit seulement qu'il est inséparable du contenu scellé.

La date n'entre pas dans l'empreinte : elle est prouvée séparément par signed_at et la signature. Les Actes scellés avant l'introduction de ovd-content-1 restent vérifiables par leur signature, mais leur empreinte n'est pas recalculable. Le vérificateur hors-ligne intègre un outil de recalcul.

4 · Signature

La signature est produite avec l'algorithme Ed25519 (RFC 8032) sur les octets UTF-8 du message ci-dessus, puis encodée en base64. C'est la valeur signature_b64.

4 · Clé publique

La clé publique de vérification est au format SPKI (PEM ou DER). La clé en vigueur porte la référence ovd-ed25519-2026-01. Une empreinte SHA-256 de la clé permet de confirmer qu'on vérifie avec la bonne clé lorsque plusieurs coexistent au fil des années. La clé publique est, par nature, destinée à être partagée ; seule la clé privée reste secrète.

5 · Procédure de vérification

  1. Récupérer proof_id, document_hash, signed_at et signature_b64 depuis l'Acte (le PDF contient un bloc de vérification prêt à copier).
  2. Reconstruire le message exact de la section 2 — ou utiliser le signed_message fourni tel quel.
  3. Vérifier : Ed25519.verify(clé_publique, signature, message).
  4. Si le résultat est positif, le Scellé est authentique et intact. Sinon, un élément a été modifié ou la clé ne correspond pas.

Le vérificateur hors-ligne OVELIYA applique exactement cette procédure dans le navigateur, sans serveur. Il reste utilisable même si ce service disparaît, à condition d'en conserver une copie avec la clé publique.

6 · Versionnage

Le numéro de version figure dans le message signé (v2). Une version publiée est figée : sa procédure de vérification ne change pas. Une évolution du protocole reçoit un nouveau numéro et sa propre spécification ; les anciens Scellés restent vérifiables selon la spécification de leur version.