Spécification des preuves ArkForge

Le format ouvert de chaque preuve Trust Layer. Il définit ce que contient une preuve et comment n’importe quelle partie, client, auditeur ou régulateur, la recalcule et la vérifie sans le code ni l’infrastructure d’ArkForge.

Version

3.1.1

Statut

Brouillon, ouvert à d’autres implémentations

Licence

CC BY 4.0 (spécification), MIT (implémentation de référence)

Source

github.com/ark-forge/proof-spec (en anglais)

Ce que contient une preuve

Une preuve est un enregistrement JSON émis par le proxy Trust Layer pour un échange entre un agent et une API. Voici les champs utiles à un vérificateur. La liste complète, champs optionnels et informatifs compris, figure à la section 1 de la spécification.

Champ	Contenu
`hashes.request`, `hashes.response`	SHA-256 du JSON canonique de la requête et de la réponse.
`commitments`	Un engagement par champ (hashes de requête et de réponse, date, parties, identité), chacun construit avec son propre nonce aléatoire de 32 octets.
`hashes.chain`	Racine de Merkle RFC 6962 des engagements. Un tiers la recalcule à partir des seuls engagements publiés, sans voir aucune valeur.
`arkforge_signature`	Signature Ed25519 du hash de chaîne par ArkForge. La clé publique est aussi servie sur `/.well-known/did.json`.
`batch_anchor`	Chemin d’inclusion du hash de chaîne jusqu’à la racine du lot ancré. Un lot se ferme à 100 preuves ou après 10 minutes.
`timestamp_authority`	Jeton RFC 3161 sur la racine du lot, intégré à la preuve (`tsr_base64`).
`transparency_log`	Entrée Sigstore Rekor de la racine du lot : index et URL de l’entrée.
`disclosed`	Nonces et valeurs des champs d’identité, publiés pour que chacun puisse ouvrir ces engagements.

Comment vérifier une preuve

Le vérificateur de référence est un script unique. Il n’a besoin que de la bibliothèque standard Python et du binaire openssl, pour qu’une partie en litige puisse le lancer sur une machine ordinaire.

Terminal

curl -O https://raw.githubusercontent.com/ark-forge/trust-layer/main/scripts/verify_proof.py
python3 verify_proof.py prf_20260914_194825_a747d0
python3 verify_proof.py --file proof.json    # depuis une copie conservée

Contrôle	Ce qu’il établit	Indépendant d’ArkForge
1. Hash de chaîne	La preuve est cohérente. Seul, ce n’est pas une preuve : qui fabrique une preuve produit des hashes cohérents.	Non
2. Signature Ed25519	ArkForge a émis la preuve.	Non
3. Ancrage par lot	Le hash de chaîne appartient au lot ancré. C’est ce qui relie les contrôles 4 et 5 à la preuve individuelle.	Non
4. Horodatage RFC 3161	Une autorité d’horodatage tierce a signé la racine du lot à une date donnée.	Oui
5. Sigstore Rekor	La racine du lot figure dans un registre public en ajout seul, avec une preuve d’inclusion rattachée à un point de contrôle signé.	Oui

Le script ne renvoie le code 0 que si tous les contrôles applicables passent. Une preuve dont le lot n’est pas encore ancré est signalée en attente, jamais comme altérée.

Ce que la vérification n’établit pas

Précisé aux sections 2, 5 et 6 de la spécification.

Que le contenu de la réponse est juste La vérification montre ce que le service a renvoyé, pas si c’était exact.

Qu’aucun appel n’a contourné le proxy Une preuve couvre les échanges passés par Trust Layer, et seulement ceux-là.

L’indépendance avant la clôture du lot Entre l’émission et la clôture du lot, une preuve n’a aucun ancrage externe : seule la signature d’ArkForge la garantit.

Les champs en clair d’une preuve publique Une réponse publique affiche certaines valeurs en clair, mais seuls leurs engagements sont ancrés. Pour vous fier à une valeur, ouvrez son engagement avec le nonce détenu par le propriétaire de la preuve.

Que la liaison d’identité de l’agent a eu lieu L’identité déclarée est engagée et ne peut plus être modifiée, mais aucun artefact public ne prouve que le défi DID a eu lieu. Résolvez le DID vous-même si vous en avez besoin.

Les métadonnées modifiables Des champs comme transaction_success, upstream_status_code ou disputed sont informatifs et peuvent changer après l’émission.

Un horodatage électronique qualifié Les jetons RFC 3161 viennent de FreeTSA, DigiCert ou Sectigo et ne sont pas qualifiés au sens du règlement eIDAS.

Versions

La spécification suit le versionnage sémantique. Chaque preuve indique sa spec_version, qui détermine l’algorithme du hash de chaîne : les preuves émises sous une version antérieure gardent leur algorithme et restent vérifiables, rien n’est recalculé ni ré-ancré après coup.

Les évolutions, questions et implémentations indépendantes passent par les issues GitHub. Une implémentation doit passer tous les vecteurs de test pour se déclarer conforme. Voir le CHANGELOG pour l'historique des versions.