anchorage_layer_simple/userwallet/docs/specs.md

Synthèse

• Modèle : Messages publiés sans signatures ni clés ; signatures et clés publiées séparément ; tout adressé par hash canonique ; récupération par GET uniquement (pull).
• Objets : Service, Contrat, Champ, Action, ActionLogin, Membre, Pair, MessageBase, Hash, Signature, Validateurs, MsgChiffre, MsgSignature, MsgCle.
• Graphe : Service → Contrat → Champ → Action(login) → Membre → Pair ; contraintes « au moins 1 parent ».
• Pairing : UUID pair ↔ mots BIP32 ; pairing obligatoire pour login.
• Écrans : accueil, création/import identité, relais, pairing, sync, services, chemin login, challenge, signatures mFA, publication, résultat.
• Machine à états : S_INIT → S_HOME, S_SYNC_GLOBAL, S_PAIR_, S_LOGIN_, etc., avec erreurs récupérables / fatales.

---

Lister les étapes et ecran d'un login basé sur ce principe :

• Génération de cles secp256k1 pour signer et vérifier les signatures
• login sans serveur central par verification de conformité contrat / signature
• pairing obligatoire pour se connecter (mFA)

Contrat d'identié avec types name: au moins

Service: Contrat Type names chiffrés dont service

Contrat : Message à valider types name chiffrés dont contrat

Champ : Message à valider types name chiffrés dont champ

• contrats parents uuid, au mois 1

ActionLogin: Action Types names chiffrés dont login

Action: Message à valider types name chiffrés dont action

• Auteurs de l'action
• contrats parents uuid, au moins 1

Objets créés lors de la création :

Lors de la création d'un Pair :

• Création automatique d'un Pair (MessageBase avec types_names_chiffres incluant "pair")
• Le Pair doit être associé à au moins un Membre (membres_parents_uuid, au moins 1)

Lors de la création d'un Membre :

• Création automatique d'un Membre (MessageAValider avec types_names_chiffres incluant "membre")
• Le Membre doit être associé à au moins une Action (actions_parents_uuid, au moins 1)

Lors de la création d'un contrat de login d'un Service :

• Création automatique d'un Contrat (MessageAValider avec types_names_chiffres incluant "contrat")
• Création automatique d'une ActionLogin (Action avec types_names_chiffres incluant "login")
• Création automatique d'un Membre (MessageAValider avec types_names_chiffres incluant "membre")
• L'ActionLogin est associée au Contrat (contrats_parents_uuid incluant l'UUID du Contrat)
• Le Membre est associé à l'ActionLogin (actions_parents_uuid incluant l'UUID de l'ActionLogin)
• Le nom du contrat de login est passé en paramètre initial à l'iframe ou au site, par défaut "default"

Membre : Message à valider types name chiffrés dont membre Actions parents uuid, au moins 1

Pair : MessageBase Types names chiffrés dont pair Membres parents uuid, au moins 1

Message Base: Hash du JSON sans le hash, sans la signature uuid Version Types names chiffrés dont pair Clés de chiffrement avec tous les paramètres et l'algo Datajson dont les attributs :

• Obligatoires : services uuid, types uuid
• optionnels :label, description longue, description courte, photo, image, bannière, URL, paragraphes (couples de textes + images), tarif Timestpamp Liste de relais (IP) Hash du JSON signé du pair avec dans la signature le hash, la clé publique et la signature Version logicielle

Hash :

• Hash du JSON (sans le hash, sans les signatures, sans clés de chiffrement)
• Algo

Signature :

• hash
• clé publique
• signature cryptographique
• Nonce et autre matériel éventuel

Message à valider :

• MessageBase +
• Validateurs du message

Validateurs: Listes des membres du role, au moins 1

• Pour chacun des membres : la liste des signatures obligatoires des autres membres et/ou de lui même

Message individuel de déchiffrement :

• hash du message
• clé de chiffrement du message chiffré: + clé de chiffrement chiffrée avec tous le paramètres et algo
• df : + diffie-hellman à scanner contenant une clé de déchiffrement de la clé de déchiffrement dans le secret partagé

Message de signature :

• Signature

Les messages sont postés sans les signatures et sans les clés de chiffrement, les signatures et les cles sont postées spécifiquement après. Les messages sont tous envoyés chiffrés de type:

• hash
• Message chiffré
• datajson public

LEs signatures et les clés de chiffrement ne sont pas récupérées au get elles sont récupérées spécifiquement apres et ajoutés aux messages stockés

Tous les envois passent par des relais qui stockent et relaient entre relais (sauvegarde des hash pour ne pas relayer ceux déjà reçus) Périodiquement et par services les client font des cet pour récupérer les informations

Chacun publie pour tous sans destinataire indiqué mais chiffré. Mais un diffie hellman est possible avec tous les pairs concernés pour d'échanger par la suite des clés de déchiffrement entre clé publiques, ce matériel exploitable que par les parties concernées est envoyé lors des échanges de clés

Pour ajouter un uuid d'un pair à un un membre celui ci est converti via bip32 en une liste de mots puis reconstitué (device 2 affiche les mots, device les saisis), ainsi l'uuid est une clé qui ne sert que d'identifiant

Pour se logguer il faut founir des signatures des pairs attendues dans l'action de type login de ce membre ayant dans ses services parents uuid l'uuid du service sur lequel il veut se connecter

Pour savoir si il y a un message à récupérer et déchiffrer il faut récupérer et scanner tous (depuis la date anniversaire de création des clés)les messages de clés depuis (proposer un bloom filtrer et/ou des arbres de merkle pur gérer l'historique des hash et ne pas tout rescanner) aucun message n'est reçu ils sont tous récupérés (get) en fonction des deffie hellman

Introduction Ce qui suit décrit, de manière opérationnelle, les étapes et les écrans d’un login fondé sur des clés secp256k1, une validation “sans serveur central” (conformité des contrats et signatures), et un pairing obligatoire jouant le rôle de second facteur. La description suppose un réseau de relais stockant et relayant des objets immuables adressés par hash, avec séparation stricte entre messages, signatures et clés de chiffrement, récupérées par appels dédiés.

Principes structurants à respecter à chaque étape Séparation des flux et des objets

• Un message “métier” est publié sans signatures et sans clés de chiffrement.
• Les signatures sont publiées ensuite, séparément, via des objets “Message de signature”.
• Les clés (ou matériels) de déchiffrement sont publiées ensuite, séparément, via des objets “Message individuel de déchiffrement”.
• Les requêtes de récupération ne renvoient pas automatiquement signatures et clés ; elles sont récupérées explicitement et rattachées localement au message stocké.

Adressage et immutabilité

• Tout objet est adressé par hash (hash du JSON canonique “sans hash, sans signatures, sans clés de chiffrement” selon la règle donnée).
• Un relais conserve l’historique des hash reçus pour ne pas relayer deux fois.

Confidentialité “publish to all”

• Tout est publié sans destinataire explicite.
• Le contenu utile est chiffré ; seuls les pairs capables d’obtenir (ou de dériver) la clé de déchiffrement peuvent lire.
• Les échanges de matériels de déchiffrement peuvent s’appuyer sur Diffie-Hellman (ECDH secp256k1) entre clés publiques concernées ; le “matériel DH” est publiable car inexploitable par les tiers.

Conformité “contrat / signature”

• La “vérité” d’un login provient de la vérification locale d’un graphe de contrats (service → contrat → champ → action → membre → pair) et de la satisfaction des validateurs (signatures requises, rôles, multi-signatures).

Pairing obligatoire (mFA)

• Sans association préalable d’au moins un “pair” (device/instance), aucune session n’est autorisée.
• L’ajout de l’UUID d’un pair à un membre se fait par conversion BIP32 en mots affichés/saisis pour limiter les erreurs et éviter l’échange brut d’identifiants.

Objets et contraintes à refléter dans l’UX (rappel synthétique) Les écrans doivent permettre de construire, vérifier et exploiter ces objets et liens (UUID “parents” au moins 1 partout où requis).

Service

• Contrat
• Types names chiffrés dont “service”

Contrat

• Message à valider
• Types names chiffrés dont “contrat”

Champ

• Message à valider
• Types names chiffrés dont “champ”
• Contrats parents UUID, au moins 1

ActionLogin

• Action
• Types names chiffrés dont “login”

Action

• Message à valider
• Types names chiffrés dont “action”
• Validateurs de l’action
• Contrats parents UUID, au moins 1

Membre

• Message à valider
• Types names chiffrés dont “membre”
• Actions parents UUID, au moins 1

Pair

• MessageBase
• Types names chiffrés dont “pair”
• Membres parents UUID, au moins 1

MessageBase

• Hash du JSON sans le hash, sans la signature

• UUID

• Version

• Types names chiffrés dont “pair” (et plus généralement le type de l’objet)

• Clés de chiffrement avec paramètres et algo

• Datajson

  • obligatoires : services UUID, types UUID
  • optionnels : label, descriptions, médias, URL, paragraphes, tarif

• Timestamp

• Liste de relais (IP)

• Hash du JSON signé du pair, avec dans la signature : hash + clé publique + signature

• Version logicielle

Hash

• Hash du JSON (sans hash, sans signatures, sans clés de chiffrement)
• Algo

Signature

• Hash
• Clé publique
• Signature cryptographique
• Nonce et matériel éventuel

Message à valider

• MessageBase
• Validateurs du message

Validateurs

• Liste des membres du rôle, au moins 1
• Pour chacun : liste des signatures obligatoires (lui-même et/ou autres membres)

Message individuel de déchiffrement

• Hash du message
• Clé de chiffrement du message chiffré, incluant une clé de chiffrement chiffrée avec paramètres et algo
• Matériel DH à scanner contenant une clé de déchiffrement (dans le secret partagé)

Message de signature

• Signature

Écrans et parcours, de bout en bout Écran d’accueil Objectif

• Démarrer une session locale, présenter l’état du wallet d’identité (clés, pairs, cache), proposer connexion ou onboarding.

Éléments affichés

• Statut “identité locale présente / absente”
• Empreinte courte de la clé publique principale (secp256k1), si existante
• Statut “pairing requis : non satisfait / satisfait”
• Statut réseau relais : atteignables, latence, dernier sync, file d’objets en attente
• Boutons : Créer identité, Importer identité, Se connecter, Gérer pairs, Paramètres relais, Synchroniser maintenant

Écran de création d’identité locale Objectif

• Générer la paire de clés secp256k1 (signature) et initialiser les paramètres de chiffrement.

Actions

• Génération clé privée secp256k1
• Dérivation clé publique secp256k1
• Éventuelle dérivation de sous-clés (BIP32) si vous utilisez un arbre pour identités/pairs/services

Champs et options

• Nom local de l’identité (purement local)
• Option de protection locale (PIN, biométrie, mot de passe) pour chiffrer la clé privée au repos
• Paramètres crypto par défaut (algorithmes symétriques, KDF, formats) pour “Clés de chiffrement avec tous les paramètres”

Sorties

• Identité locale créée
• Date “anniversaire de création des clés” enregistrée (sert de point de départ de scan)
• Cache local initialisé (index des hash vus, index services/types, index ECDH)

Écran d’import d’identité Objectif

• Restaurer la clé privée (ou seed BIP32) et les métadonnées locales nécessaires.

Actions

• Import seed / clé privée
• Recalcul clé publique
• Réindex local minimal

Contrôles

• Vérifier cohérence clé publique dérivée
• Vérifier format/versions

Écran de gestion des relais Objectif

• Déclarer la liste de relais, tester, prioriser, et configurer la stratégie de synchronisation.

Champs

• Liste de relais (IP ou endpoints)
• Stratégie : périodicité, par services, par fenêtres temporelles
• Paramètres anti-resscan : Bloom filter, Merkle trees (optionnel), taille de cache de hash

Actions

• Test connectivité
• Mise à jour de la liste et sauvegarde locale

Écran de pairing (obligatoire avant login) Objectif

• Associer au moins un pair à un membre, via procédure robuste “mots BIP32”, pour fournir le second facteur.

Pré-requis conceptuel

• Un pair est un objet rattaché à un ou plusieurs membres (Membres parents UUID ≥ 1).
• L’association se matérialise par la publication d’objets (selon votre modèle) où l’UUID du pair est présent dans le graphe du membre, et validé par les signatures attendues.

Sous-écran “ajouter un pair” Deux modes pratiques

• Mode “ce device devient un pair”

  • Générer/attribuer un UUID pair local
  • Afficher la séquence de mots BIP32 dérivée de cet UUID

• Mode “associer un pair existant”

  • Saisir les mots BIP32 affichés par l’autre device
  • Reconstituer l’UUID pair
  • Préparer la publication des messages nécessaires pour lier ce pair au membre

Contrôles

• Vérification de saisie (checksum/wordlist)
• Vérification que le pair n’est pas déjà associé
• Vérification que le membre cible est connu (ou possibilité de le découvrir via sync)

Sorties

• UUID pair reconnu et enregistré localement
• Publication (ou préparation) des messages “pair” / “membre” nécessaires à l’association
• Mise en file des signatures et clés de chiffrement à publier séparément

Écran de synchronisation initiale (découverte) Objectif

• Récupérer et indexer l’ensemble des messages utiles pour construire le graphe et détecter ce qui est déchiffrable.

Contraintes imposées par votre modèle “publish to all”

• Aucun message n’est “reçu” : tout est “récupéré (get)” puis filtré localement.
• Pour détecter un message déchiffrable, il faut scanner les messages de clés depuis la date anniversaire de création des clés (ou depuis le dernier checkpoint).

Éléments affichés

• Fenêtre temporelle de scan (début = date anniversaire / dernier checkpoint, fin = maintenant)
• Compteurs : messages récupérés, hash nouveaux, hash déjà vus, signatures en attente de fetch, clés en attente de fetch
• Indicateur Bloom/Merkle : actif/inactif, taux de faux positifs (si Bloom), profondeur/segments (si Merkle)
• Liste des services découverts (via datajson.services UUID) et types UUID

Actions

• Synchroniser maintenant
• Affiner par service
• Construire/mettre à jour l’index Merkle ou Bloom côté client
• Exporter un checkpoint local (hash racine Merkle, ou bitset Bloom) si utile

Étapes techniques de sync côté client

• GET messages chiffrés “hash + message chiffré + datajson public” depuis relais, filtrés par période et/ou service
• Déduplication par hash (cache local + cache relais)
• Pour chaque message potentiel : tenter d’identifier la nécessité d’une clé (via type UUID, service UUID, et index ECDH)
• Fetch dédié des “Message individuel de déchiffrement” pertinents (par hash) et construction du matériel ECDH
• Déchiffrement, parsing JSON, calcul hash canonique, vérification cohérence “Hash du JSON sans hash…”
• Fetch dédié des “Message de signature” (par hash) et attachement local
• Vérification des signatures secp256k1 conformément aux validateurs du message

Écran de sélection du service Objectif

• Choisir le service (service UUID) sur lequel l’utilisateur veut s’authentifier.

Affichage

• Liste des services disponibles (découverts localement)

• Pour chaque service : statut de confiance

  • “Contrat complet et valide”
  • “Contrat incomplet (éléments manquants)”
  • “Contrat invalide (hash/signature/validateurs non satisfaits)”

• Option de rafraîchissement sync “par service”

Action

• Choisir un service → déclenche construction du chemin de validation login

Écran “construction du chemin login” Objectif

• Construire et afficher la chaîne d’objets nécessaires, puis calculer la liste exacte des signatures attendues.

Chaîne minimale attendue

• Service (service UUID)
• Contrat(s) rattachés
• Champs (au moins 1 champ avec contrats parents UUID)
• ActionLogin → Action de type login
• Membre (ayant actions parents UUID incluant l’action login)
• Pair(s) (ayant membres parents UUID incluant ce membre)

Travail du client

• Résoudre les liens par UUID parents, vérifier “au moins 1” partout où requis
• Vérifier les “types names chiffrés” : existence, déchiffrement si nécessaire, cohérence avec type UUID
• Pour chaque objet : recalcul hash canonique et comparer au hash déclaré
• Construire l’ensemble “validateurs” applicables à l’action login et au message de login
• Produire la matrice “signatures obligatoires” : qui doit signer quoi, et sous quelles clés publiques

Affichage conseillé

• Graphe ou liste hiérarchique (service → … → pair), avec statut vert/rouge par nœud
• Détail des signatures requises : membre(s) valideur(s), nombre minimal, dépendances “autres membres et/ou lui-même”

Écran “vérification du pairing requis” Objectif

• S’assurer que les pairs exigés par l’action login sont présents et activables localement.

Vérifications

• Les UUID de pairs attendus sont connus localement (ou récupérables)
• Chaque pair attendu peut produire une signature (donc la clé privée correspondante est accessible localement ou via device associé)
• Le mapping pair ↔ membre ↔ action login est valide et signé selon validateurs

Cas usuels

• Pair local unique : ce device signe
• Multi-pair : exiger au moins N signatures de pairs distincts (mFA renforcé)
• Pair distant : déclencher un flux “signer sur l’autre device” via procédure de partage (QR, mots, lien) sans serveur central, uniquement par publication de signatures

Écran “challenge / message à valider” Objectif

• Générer le “Message à valider” de la session de login, puis organiser sa signature et sa vérification.

Contenu minimal à préparer

• MessageBase complet (uuid, version, timestamp, types UUID, services UUID, relais, version logicielle, datajson public minimal)
• Hash canonique calculé selon règle
• Nonce de session et/ou matériel anti-rejeu dans “Signature” (nonce et autre matériel éventuel)
• Références explicites au service UUID cible
• Références explicites à l’action login UUID et au membre UUID (selon votre modèle), pour lier la preuve à l’intention

Affichage

• Résumé des attributs publics (service UUID, type UUID, timestamp, relais)
• Statut “détecté comme conforme au contrat : oui/non”
• Bouton “Signer” (désactivé si pairing non satisfait)

Écran “signature(s) mFA” Objectif

• Collecter les signatures requises, potentiellement depuis plusieurs pairs/devices.

Flux de signature

• Pour le pair local

  • Signer hash canonique secp256k1
  • Produire objet “Message de signature” : hash + clé publique + signature + nonce/matériel

• Pour les pairs distants

  • Afficher un “paquet de demande de signature” (hash, contexte, paramètres)
  • Sur l’autre device : vérifier contexte, signer, publier la signature
  • Sur ce device : récupérer la signature via fetch dédié et l’attacher localement

Affichage

• Liste des signatures attendues avec état

  • “manquante”
  • “reçue”
  • “valide”
  • “invalide” (mauvais hash, mauvaise clé publique, signature invalide)

• Règles de validateurs satisfaites / non satisfaites, en temps réel

Écran “publication du login” Objectif

• Publier la preuve de login dans le réseau de relais, conformément à la règle “message d’abord, signatures ensuite, clés ensuite”.

Étapes d’émission côté client

• Publier le message chiffré (objet contenant : hash + message chiffré + datajson public)

  • Sans signatures
  • Sans clés de chiffrement

• Publier ensuite, séparément, les “Message de signature” nécessaires

• Publier ensuite, séparément, les “Message individuel de déchiffrement” nécessaires (si d’autres parties doivent déchiffrer, par exemple le service ou un ensemble de validateurs)

• Relais : propagation inter-relais, déduplication par hash

Affichage

• Liste des relais cibles, état de publication par relais
• Hash final de la preuve
• Statut “propagation suffisante” (par exemple M relais sur N ont confirmé stockage)

Écran “vérification côté service sans serveur central” Objectif

• Décrire ce que fait le “service” (ou l’application de service) pour accepter la session, en ne reposant que sur contrats + signatures.

Mécanique de vérification (côté service)

• Récupérer le message publié (par hash ou par scan périodique “par service”)
• Récupérer explicitement signatures associées
• Récupérer explicitement matériels de déchiffrement si nécessaire
• Déchiffrer, recalculer hash canonique, comparer
• Vérifier signatures secp256k1, clés publiques, nonces
• Rejouer la construction du graphe (service → … → action login → membre → pairs) depuis les UUID et messages disponibles
• Vérifier validateurs : liste des membres du rôle, signatures obligatoires, seuils
• Vérifier anti-rejeu : timestamp, nonce, fenêtre temporelle, unicité du hash/nonce
• Si OK : émettre un “jeton local” (non central) ou ouvrir une session locale ; sinon refuser

Écran “résultat de connexion” Objectif

• Donner un état explicite, traçable, et diagnostiquable.

États possibles

• Connecté : preuve acceptée
• Refusé : contrat incomplet
• Refusé : signatures insuffisantes
• Refusé : signature invalide
• Refusé : anti-rejeu déclenché (nonce déjà vu / timestamp hors fenêtre)
• Refusé : pairing requis non satisfait
• Refusé : impossibilité de récupérer signatures/clés après délai

Affichage recommandé

• Hash de la preuve
• Service UUID
• Liste des validateurs satisfaits / non satisfaits
• Journal succinct : quels objets manquaient (hash), quelles signatures manquaient (clé publique), quels matériels DH manquaient

Écran “récupération et déchiffrement en continu” Objectif

• Assurer le fonctionnement périodique “par services” : scan, fetch des clés, fetch des signatures, mise à jour du graphe et des droits.

Fonctions

• Planification périodique : pour chaque service connu, GET des nouveaux messages depuis dernier checkpoint
• Dédup hash
• Tentative de correspondance via index ECDH pour identifier les messages potentiellement déchiffrables
• Fetch des messages de clés (déchiffrement), puis fetch des signatures, puis validation

Optimisations à exposer (au moins comme options avancées)

• Bloom filter

  • Objectif : éviter de rescanner tout l’historique des hash
  • Données : bitset local, éventuellement partagé entre devices
  • Limite : faux positifs possibles → nécessite vérification finale par hash

• Arbres de Merkle

  • Objectif : prouver rapidement la présence/absence d’un hash dans un ensemble et synchroniser des segments
  • Données : racines par période/service, preuve d’inclusion
  • Limite : complexité de maintenance côté relais et côté client

Détails critiques de validation à intégrer (pour éviter des ambiguïtés en production) Canonisation JSON

• Définir une canonisation stricte : ordre des clés, encodage, normalisation des nombres/chaînes, gestion des tableaux.
• Sans cela, “Hash du JSON” devient instable entre implémentations.

Gestion des versions

• “Version” et “Version logicielle” doivent être prises en compte dans la validation (compatibilité ascendante, migrations).
• Le client doit afficher clairement la version d’un contrat et refuser ou isoler les versions non supportées.

Anti-rejeu

• Timestamp seul est insuffisant ; exiger un nonce unique par tentative, et un cache de nonces vus (par service) sur une fenêtre glissante.
• Le service doit rejeter un hash/nonce déjà accepté.

Clés publiques et identité

• La clé publique incluse dans la signature doit être reliée, par le graphe et les validateurs, au pair attendu.
• Interdire l’acceptation d’une signature “valide cryptographiquement” mais non autorisée “contractuellement”.

Séparation signatures / clés

• Prévoir un état “message reçu mais indéchiffrable (clé manquante)” et “message déchiffré mais non validé (signature manquante)”.
• L’UX doit rendre ces états visibles, sinon les utilisateurs concluent à des pertes de données.

Conclusion Un login conforme à ce modèle n’est pas un simple écran “identifiant/mot de passe”, mais un enchaînement de construction et de vérification d’un graphe contractuel, suivi d’une collecte de signatures multi-pairs, puis d’une publication en trois temps (message, signatures, clés), le tout synchronisé via des relais. La robustesse globale vient de la cohérence entre canonisation des hash, règles de validateurs, anti-rejeu, et de la capacité du client à scanner efficacement l’historique (Bloom/Merkle) sans jamais supposer qu’un message “arrive” par push.

Si une suite est souhaitée, la prochaine étape naturelle consiste à produire une spécification d’écrans sous forme de maquettes textuelles (composants, états, erreurs, journaux), puis une machine à états formelle du protocole de login (états, transitions, timeouts, reprise sur erreur), strictement alignée sur les objets et contraintes listés ci-dessus.

Écrans à produire pour login sans serveur central (secp256k1 + contrats + pairing mFA)

Principes UX et contraintes non négociables

Les règles suivantes doivent être visibles dans la conception des écrans (au minimum en “états avancés”, logs, diagnostics) :

• Tous les messages sont récupérés par GET (aucun push).
• Les messages “métier” sont publiés sans signatures et sans clés de chiffrement.
• Les signatures sont publiées après, séparément.
• Les clés/matériels de déchiffrement sont publiés après, séparément.
• Un GET de message ne renvoie pas signatures et clés : elles sont fetch spécifiquement ensuite.
• Tous les objets sont adressés par hash du JSON canonique (sans hash, sans signatures, sans clés de chiffrement).
• Le login est une preuve validée localement par graphe (service → contrat → champ → action/login → membre → pair) + validateurs.
• Le pairing est obligatoire pour autoriser une connexion : au moins un pair associé et attendu par l’action de login.
• Publication “pour tous” : aucun destinataire explicite. Le message est chiffré et n’est lisible que par les parties capables d’obtenir les clés.

Glossaire des objets manipulés dans l’UI

• Service : objet décrivant un service et son contrat associé.
• Contrat : objet “contrat d’identité”.
• Champ : objet rattaché à au moins un contrat parent.
• Action : objet rattaché à au moins un contrat parent, contient des validateurs.
• ActionLogin : action de type “login”.
• Membre : objet rattaché à au moins une action parent.
• Pair : objet rattaché à au moins un membre parent (device/instance).
• MessageBase : trame commune incluant uuid/version/types/services/timestamp/relais/hash/signature/pubkey.
• Message à valider : MessageBase + validateurs.
• Hash : hash du JSON canonique (sans hash, sans signatures, sans clés de chiffrement) + algo.
• Signature : hash + clé publique + signature + nonce/matériel.
• Message de signature : objet portant une Signature.
• Message individuel de déchiffrement : objet portant matériel de déchiffrement + ECDH.

Écran “accueil”

Objectif

Point d’entrée de l’application : état de l’identité locale, état du pairing, accès au login et à la synchronisation.

Pré-requis

Aucun.

Composants UI

• Statut identité locale : présente / absente
• Empreinte de la clé publique principale (format court)
• Statut pairing : requis / satisfait / incomplet
• Statut réseau relais : OK / dégradé / indisponible
• Dernière synchronisation : date/heure
• Boutons :
  • Créer une identité locale
  • Importer une identité
  • Se connecter
  • Gérer les pairs
  • Réglages relais
  • Synchroniser maintenant

États / erreurs

• Identité absente → bouton “Se connecter” désactivé
• Pairing non satisfait → “Se connecter” possible mais renverra vers pairing obligatoire
• Relais indisponibles → mode offline (lecture cache uniquement)

Écran “création d’identité locale”

Objectif

Générer les clés secp256k1 et initialiser les paramètres crypto locaux.

Pré-requis

Aucun.

Composants UI

• Nom local de l’identité (optionnel)
• Protection locale :
  • PIN / mot de passe / biométrie (selon plateforme)
• Paramètres crypto avancés (optionnel) :
  • Algos de chiffrement symétrique
  • KDF
  • Format canonique JSON
  • Hash (algo)

Actions utilisateur

• Générer l’identité

Traitements locaux

• Génération clé privée secp256k1
• Calcul clé publique secp256k1
• Enregistrement “date anniversaire de création des clés”
• Création du cache local :
  • index hash vus
  • index services/types
  • index ECDH (si applicable)

États / erreurs

• Erreur entropie / RNG indisponible
• Protection locale non conforme (PIN trop court, etc.)

Écran “import d’identité”

Objectif

Restaurer une identité existante (clé privée ou seed/hiérarchie).

Pré-requis

Disposer d’un secret d’import.

Composants UI

• Mode import :
  • Seed / phrase / clé privée
  • Fichier chiffré (optionnel)
• Champ d’entrée + validation checksum
• Protection locale au repos (comme création)

Traitements locaux

• Recalcul clé publique
• Vérification cohérence
• Initialisation cache

États / erreurs

• Seed invalide
• Clé privée hors format
• Incompatibilité de version

Écran “réglages relais”

Objectif

Configurer la liste de relais et les stratégies de synchronisation.

Composants UI

• Liste des relais (IP / endpoint)
• Priorité / ordre (drag & drop)
• Options :
  • Sync périodique par service
  • Fenêtre de scan par défaut
  • Déduplication locale (taille cache hash)
  • Accélérateurs : Bloom filter / Merkle (avancé)
• Boutons :
  • Tester relais
  • Ajouter / supprimer relais
  • Sauvegarder

États / erreurs

• Relais non joignable
• Timeout réseau
• Configuration invalide (liste vide)

Écran “synchronisation globale”

Objectif

Récupérer des messages publiés sur relais, sans destinataire, et mettre à jour le cache local.

Pré-requis

Identité locale présente.

Composants UI

• Fenêtre de scan :
  • Début : anniversaire clés / dernier checkpoint
  • Fin : maintenant
• Sélecteurs :
  • Tous services
  • Service spécifique (si déjà connu)
• Compteurs :
  • messages récupérés
  • hash nouveaux
  • hash déjà vus
  • messages déchiffrables détectés
  • signatures à récupérer
  • clés à récupérer
• Boutons :
  • Synchroniser maintenant
  • Pause / reprendre
  • Forcer “fetch signatures”
  • Forcer “fetch clés”
  • Diagnostiquer un hash

Traitements locaux

• GET messages chiffrés : (hash + message chiffré + datajson public)
• Déduplication par hash
• Indexation par service UUID / type UUID
• Tentatives d’identification :
  • ce message est-il potentiellement déchiffrable ?
• Fetch dédié des messages “clés” pertinents
• Déchiffrement, parsing JSON, recalcul hash canonique
• Fetch dédié des “messages de signature”
• Vérification signatures secp256k1
• Mise à jour du graphe (service/contrat/action/membre/pair)

États / erreurs

• Message présent mais clé manquante → “indéchiffrable”
• Message déchiffré mais signatures manquantes → “non validé”
• Hash incohérent (JSON canonique différent) → “objet corrompu / non conforme”
• Signatures invalides → “preuve invalide”

Écran “gestion des services”

Objectif

Lister les services connus localement et leur état de validité contractuelle.

Pré-requis

Au moins une synchronisation effectuée.

Composants UI

• Liste des services (service UUID)
• Pour chaque service :
  • label (si disponible et déchiffré)
  • statut contrat :
    • complet et valide
    • incomplet (objets manquants)
    • invalide (signatures/validateurs)
  • dernier sync service
• Actions :
  • Ouvrir
  • Resync par service
  • Voir graphe

États / erreurs

• Service détecté mais contrat non résolu → “incomplet”
• Types names chiffrés non déchiffrables → “affichage minimal”

Écran “détail service / graphe contractuel”

Objectif

Afficher la chaîne complète : service → contrat → champ → action → membre → pair(s), avec états.

Composants UI

• Vue hiérarchique ou graphe
• Nœuds avec :
  • UUID
  • type UUID
  • statut (valide/incomplet/invalide)
  • hash
• Liste “objets manquants” (hash attendus)
• Bouton “diagnostic”

Traitements locaux

• Résolution des parents UUID
• Validation “au moins 1 parent” sur objets concernés
• Vérification hash canonique
• Vérification signatures et validateurs

États / erreurs

• Cycle détecté dans les UUID parents (si possible) → bloquer
• Parent absent → incomplet

Écran “gestion des pairs”

Objectif

Lister les pairs connus et gérer l’association à des membres.

Composants UI

• Liste des pairs (UUID pair)
• Pour chaque pair :
  • membres parents UUID
  • statut : associé / en attente / invalide
  • capacité signature : OK / indisponible
• Actions :
  • Ajouter un pair
  • Associer à un membre
  • Retirer (local uniquement, selon politique)
  • Diagnostiquer

Écran “ajout de pair (mFA)”

Objectif

Réaliser le pairing obligatoire via conversion BIP32 en mots.

Pré-requis

Identité locale présente.

Mode A : “ce device devient un pair”

Composants UI

• Générer UUID pair
• Afficher liste de mots BIP32 dérivée de l’UUID
• Bouton “continuer” (confirmation)

Traitements locaux

• Conversion UUID → chemin BIP32 → mots
• Enregistrement local du pair

Mode B : “associer un pair existant”

Composants UI

• Saisie des mots BIP32 affichés par l’autre device
• Bouton “reconstituer UUID”

Traitements locaux

• Mots → reconstitution UUID
• Vérification checksum
• Enregistrement pair

Publication

• Préparation des messages nécessaires pour lier pair ↔ membre :
  • message métier (sans signature, sans clés)
  • puis message(s) de signature
  • puis message(s) de déchiffrement si requis

États / erreurs

• Mots invalides / ordre incorrect
• Pair déjà présent
• Membre cible absent du cache (sync requise)

Écran “sélection membre”

Objectif

Choisir le membre concerné par le login (quand plusieurs membres existent).

Pré-requis

Graphe local résolu au moins partiellement.

Composants UI

• Liste des membres
  • label (si déchiffré)
  • actions parents (dont login)
  • pairs associés
• Action : sélectionner

États / erreurs

• Aucun membre avec action login → impossible de se connecter

Écran “sélection service pour connexion”

Objectif

Choisir le service cible du login.

Pré-requis

Services connus.

Composants UI

• Liste des services + statuts
• Bouton “continuer”

États / erreurs

• Service invalide → alerte + détails

Écran “construction du chemin login”

Objectif

Résoudre et afficher le chemin de validation du login, et calculer les signatures attendues.

Composants UI

• Résumé du chemin :
  • service UUID
  • contrat(s) UUID
  • action login UUID
  • membre UUID
  • pairs attendus UUID
• Tableau “signatures requises” :
  • validateurs
  • règles (qui doit signer)
  • statut (manquante/reçue/valide/invalide)
• Boutons :
  • Synchroniser (si incomplet)
  • Démarrer login

Traitements locaux

• Résolution parents
• Validation validateurs de l’action login
• Détermination du set minimal de signatures pour satisfaire la règle

États / erreurs

• Contrat incomplet
• Validateurs impossibles à satisfaire (ex : pair manquant)

Écran “message de login à valider”

Objectif

Construire le Message à valider de login.

Composants UI

• Résumé public :
  • service UUID
  • type UUID
  • timestamp
  • relais cibles
• Paramètres anti-rejeu :
  • nonce généré (affichage possible en mode avancé)
• Bouton “signer”

Traitements locaux

• Construction MessageBase
• Insertion datajson public minimal (services UUID, types UUID)
• Calcul hash canonique
• Préparation du message chiffré
• Préparation publication “message d’abord”

États / erreurs

• Format JSON non canonique détecté
• Relais indisponibles

Écran “collecte des signatures (mFA)”

Objectif

Obtenir toutes les signatures obligatoires attendues pour l’action login.

Composants UI

• Liste des signatures requises :
  • clé publique attendue
  • pair/membre associé
  • état
• Boutons :
  • Signer avec ce device
  • Demander signature sur autre pair
  • Rafraîchir (fetch signatures)
  • Voir détail signature

Flux “signature locale”

• Calcul signature secp256k1
• Création Message de signature

Flux “signature distante”

• Afficher un paquet de demande (hash + contexte)
• Autre device signe et publie
• Ce device fetch la signature et rattache

États / erreurs

• Signature invalide
• Nonce déjà utilisé (anti-rejeu)
• Délai d’attente dépassé

Écran “publication du login”

Objectif

Publier la preuve en respectant la séparation : message chiffré → signatures → clés de déchiffrement.

Composants UI

• Liste des relais + état :
  • envoyé / confirmé / échec
• Hash final de la preuve
• Boutons :
  • Publier
  • Republier sur relais manquants
  • Afficher diagnostics

Traitements réseau (ordre strict)

• POST message chiffré (sans signatures, sans clés)
• POST message(s) de signature
• POST message(s) individuels de déchiffrement (si requis)

États / erreurs

• Message publié mais signatures non publiées → preuve incomplète
• Signatures publiées mais clés manquantes → preuve inutilisable par tiers

Écran “résultat de connexion”

Objectif

Afficher un verdict explicite et traçable.

États possibles

• Connexion acceptée
• Connexion refusée : contrat incomplet
• Connexion refusée : signatures insuffisantes
• Connexion refusée : signatures invalides
• Connexion refusée : pairing non satisfait
• Connexion refusée : anti-rejeu (nonce déjà vu / timestamp hors fenêtre)
• Connexion refusée : objets manquants

Composants UI

• Statut final
• Hash de la preuve
• Service UUID
• Détails :
  • signatures requises vs obtenues
  • objets manquants
  • logs (mode avancé)
• Actions :
  • Recommencer
  • Resync
  • Diagnostic

Écran “diagnostic avancé (hash / objet)”

Objectif

Aider à comprendre un échec (objet manquant, clé absente, signature invalide).

Composants UI

• Entrée hash (ou sélection depuis liste)
• Détails objet :
  • type UUID
  • service UUID
  • timestamp
  • statut déchiffrement : OK/non
  • statut signature : OK/non
• Boutons :
  • Fetch signatures
  • Fetch clés
  • Vérifier canonisation JSON
  • Vérifier validateurs

Erreurs typiques affichées

• Hash recalculé ≠ hash déclaré
• Signature secp256k1 invalide
• Clé publique non autorisée par validateurs
• Matériel DH absent / non exploitable
• Parents UUID absents

Écran “synchronisation continue par service”

Objectif

Maintenir le cache à jour périodiquement, par service.

Composants UI

• Liste services + toggle sync automatique
• Fréquence (min/heure/jour)
• Fenêtre de scan
• Accélérateurs :
  • Bloom filter : taille, faux positifs estimés
  • Merkle : segments/périodes
• Bouton “lancer maintenant”

Traitements locaux

• GET messages depuis dernier checkpoint
• Dédup hash
• Fetch signatures et clés si nécessaire
• Validation graphe et droits

États / erreurs

• Volume trop important → recommander Bloom/Merkle
• Relais instables → backoff

Écran “paramètres crypto (avancé)”

Objectif

Afficher et régler les politiques crypto et compatibilité.

Composants UI

• Algorithme hash (ex : sha256)
• Canonisation JSON (mode strict)
• Paramètres ECDH (secp256k1)
• Paramètres KDF/symétrique (si exposés)
• Politique anti-rejeu :
  • TTL nonce
  • fenêtre timestamp

États / erreurs

• Incompatibilité avec services existants
• Paramètres non supportés par version logicielle

Machine à états du login sans serveur central (secp256k1 + contrats + pairing mFA)

Objectif

Décrire une machine à états déterministe et implémentable pour :

• créer/importer une identité,
• synchroniser des messages via relais (pull-only),
• résoudre le graphe contractuel,
• imposer le pairing (mFA),
• construire un message de login à valider,
• collecter et vérifier les signatures attendues,
• publier la preuve (message → signatures → clés),
• obtenir un verdict local côté client et côté service (sans autorité centrale).

Définitions globales

Notation

• État : S_*
• Événement : E_*
• Garde (condition) : G_*
• Action (effet) : A_*
• Erreur : X_*

Règles d’adressage et de contenu

• Tout objet est adressé par Hash(JSON_canonique(objet))
• JSON_canonique(objet) = JSON sans :
  • hash
  • signatures
  • clefs_de_chiffrement
• Les signatures et les clés sont récupérées séparément après GET message.
• Tout est publié pour tous (sans destinataire explicite), chiffré.

Objets de preuve

• MsgChiffre : { hash, message_chiffre, datajson_public }
• MsgSignature : { signature: {hash, pubkey, sig, nonce, materiel} }
• MsgCle : { hash_message, cle_chiffrement, df_ecdh_scannable }

Fenêtres de synchronisation

• T0 = date_anniversaire_creation_cles
• T_last = dernier_checkpoint_local
• Scan par défaut : [T_last ou T0 ; maintenant]

Cache local minimal

• cache_hash_vus
• index_par_service_uuid
• index_par_type_uuid
• index_par_hash -> (msg, signatures?, cles?, statut_dechiffrement, statut_validation)
• index_pairs_locaux
• index_membres_connus
• index_ecdh (si ECDH structuré par pubkeys)

Variables de session (runtime)

• service_cible_uuid
• membre_cible_uuid
• action_login_uuid
• pairs_attendus[]
• signatures_requises[]
• nonce_login
• hash_login
• msg_login_chiffre
• relays[]
• timer_deadlines (réseau, collecte signatures, fetch clés)

États et transitions

S_INIT (démarrage application)

Entrée

• Charger cache local
• Charger identité locale si présente
• Charger configuration relais

Événements sortants

• E_IDENTITY_ABSENT → S_IDENTITY_REQUIRED
• E_IDENTITY_PRESENT → S_HOME

---

S_IDENTITY_REQUIRED (identité manquante)

UI associée

• écran accueil avec options “Créer” / “Importer”

Transitions

• E_CREATE_IDENTITY → S_IDENTITY_CREATE
• E_IMPORT_IDENTITY → S_IDENTITY_IMPORT

---

S_IDENTITY_CREATE (création identité locale)

Actions

• A_GEN_SECP256K1_KEYPAIR
• A_SET_T0_ANNIVERSAIRE
• A_INIT_CACHE

Sorties

• E_IDENTITY_CREATED → S_HOME

Erreurs

• X_RNG_UNAVAILABLE → S_ERROR_FATAL

---

S_IDENTITY_IMPORT (import identité)

Actions

• A_PARSE_SEED_OR_PRIVKEY
• A_DERIVE_PUBKEY
• A_SET_OR_CONFIRM_T0
• A_INIT_CACHE

Sorties

• E_IDENTITY_IMPORTED → S_HOME

Erreurs

• X_IMPORT_INVALID → S_ERROR_RECOVERABLE

---

S_HOME (accueil)

Événements

• E_OPEN_RELAY_SETTINGS → S_RELAY_SETTINGS
• E_SYNC_NOW → S_SYNC_GLOBAL
• E_MANAGE_PAIRS → S_PAIR_MANAGEMENT
• E_LOGIN_START → S_LOGIN_SELECT_SERVICE

Gardes

• G_IDENTITY_PRESENT sinon retour S_IDENTITY_REQUIRED

---

S_RELAY_SETTINGS (configuration relais)

Actions

• A_SAVE_RELAYS_CONFIG
• A_TEST_RELAYS (optionnel)

Sorties

• E_RELAYS_SAVED → S_HOME
• E_CANCEL → S_HOME

Erreurs

• X_RELAYS_INVALID → S_ERROR_RECOVERABLE

---

S_SYNC_GLOBAL (synchronisation globale)

Objectif

Récupérer MsgChiffre, dédupliquer par hash, puis fetch clés et signatures sur demande.

Entrée

• Déterminer fenêtre [T_scan_start; T_scan_end]
• Initialiser compteurs

Actions boucle (pull)

• A_GET_MSGS_CHIFFRES(relays, window) → liste {hash, message_chiffre, datajson_public}
• A_DEDUP_HASH(cache_hash_vus)
• A_INDEX_PUBLIC_METADATA(service_uuid, type_uuid, timestamp)
• A_DETECT_POTENTIEL_DECHIFFRABLE(index_ecdh, datajson_public) (heuristique)
• A_FETCH_KEYS_BY_HASH(hash) (si candidat)
• A_TRY_DECRYPT(hash) (si clé présente)
• A_RECALC_CANONICAL_HASH
• A_FETCH_SIGNATURES_BY_HASH(hash) (si déchiffré)
• A_VERIFY_SIGNATURES
• A_UPDATE_GRAPH_CACHE

Sorties

• E_SYNC_DONE → S_HOME
• E_SYNC_DONE_WITH_DISCOVERY → S_SERVICE_LIST

Erreurs récupérables

• X_RELAY_TIMEOUT → rester S_SYNC_GLOBAL avec backoff
• X_DECRYPT_KEY_MISSING → marquer état local “indéchiffrable”
• X_SIG_MISSING → marquer “non validé”
• X_HASH_MISMATCH → marquer “corrompu / non conforme”

---

S_SERVICE_LIST (liste services)

Entrée

• Charger services connus depuis index_par_service_uuid

Transitions

• E_SELECT_SERVICE(service_uuid) → S_LOGIN_SELECT_MEMBER (ou direct si membre unique)
• E_RESYNC_SERVICE(service_uuid) → S_SYNC_SERVICE
• E_BACK → S_HOME

---

S_SYNC_SERVICE (sync ciblée service)

Actions

• A_GET_MSGS_CHIFFRES(filter=service_uuid)
• mêmes actions de déchiffrement/validation que S_SYNC_GLOBAL

Sorties

• E_SYNC_SERVICE_DONE → S_SERVICE_LIST
• E_BACK → S_SERVICE_LIST

---

S_PAIR_MANAGEMENT (gestion pairs)

Transitions

• E_PAIR_ADD → S_PAIR_ADD
• E_PAIR_ASSOCIATE_TO_MEMBER → S_PAIR_ASSOCIATE
• E_BACK → S_HOME

---

S_PAIR_ADD (ajout d’un pair)

Modes

• local : “ce device devient un pair”
• distant : “associer un pair existant”

Actions

• A_GEN_PAIR_UUID (mode local)
• A_UUID_TO_BIP32_WORDS (affichage)
• A_WORDS_TO_UUID (saisie)
• A_STORE_PAIR_LOCAL

Sorties

• E_PAIR_READY → S_PAIR_ASSOCIATE

Erreurs

• X_WORDS_INVALID → S_ERROR_RECOVERABLE

---

S_PAIR_ASSOCIATE (associer pair ↔ membre)

Gardes

• G_MEMBRE_EXISTS_LOCALLY sinon S_SYNC_GLOBAL

Actions (préparation publication)

• A_BUILD_PAIR_MEMBERSHIP_MESSAGE (message métier sans signatures/clefs)
• A_ENCRYPT_MESSAGE
• A_CALC_HASH
• A_QUEUE_PUBLISH_MESSAGE
• A_QUEUE_PUBLISH_SIGNATURES_REQUIRED
• A_QUEUE_PUBLISH_KEYS_IF_REQUIRED

Sorties

• E_ASSOCIATION_QUEUED → S_PUBLISH_QUEUE

---

S_PUBLISH_QUEUE (file de publication)

Objectif

Publier dans l’ordre strict : message → signatures → clés.

Actions

• A_POST_MSG_CHIFFRE
• A_POST_MSG_SIGNATURES
• A_POST_MSG_KEYS

Sorties

• E_PUBLISH_OK → S_HOME
• E_PUBLISH_PARTIAL → S_ERROR_RECOVERABLE

Erreurs

• X_RELAY_DOWN → S_ERROR_RECOVERABLE

---

S_LOGIN_SELECT_SERVICE (début login : choix service)

Gardes

• G_PAIRING_SATISFIED sinon S_LOGIN_PAIRING_REQUIRED

Transitions

• E_SELECT_SERVICE(service_uuid) → S_LOGIN_SELECT_MEMBER
• E_BACK → S_HOME

---

S_LOGIN_PAIRING_REQUIRED (pairing obligatoire)

Transitions

• E_GO_PAIRING → S_PAIR_MANAGEMENT
• E_BACK → S_HOME

---

S_LOGIN_SELECT_MEMBER (choix membre)

Gardes

• G_MEMBRE_WITH_ACTION_LOGIN_EXISTS sinon S_ERROR_RECOVERABLE

Transitions

• E_SELECT_MEMBER(membre_uuid) → S_LOGIN_BUILD_PATH
• E_BACK → S_SERVICE_LIST

---

S_LOGIN_BUILD_PATH (résolution graphe et validateurs)

Actions

• A_RESOLVE_GRAPH(service_uuid, membre_uuid)
  • service → contrat → champ → action(login) → membre → pairs
• A_VALIDATE_PARENTS_UUID_CONSTRAINTS
• A_VALIDATE_TYPES_NAMES_IF_AVAILABLE
• A_LOAD_ACTION_VALIDATORS
• A_COMPUTE_REQUIRED_SIGNATURES_SET

Sorties

• E_PATH_OK → S_LOGIN_CHECK_PAIRS
• E_PATH_INCOMPLETE → S_ERROR_RECOVERABLE
• E_PATH_INVALID → S_ERROR_RECOVERABLE

Erreurs

• X_PARENT_MISSING
• X_VALIDATORS_UNSATISFIABLE
• X_HASH_MISMATCH

---

S_LOGIN_CHECK_PAIRS (vérifier pairs attendus)

Gardes

• G_ALL_REQUIRED_PAIRS_AVAILABLE sinon S_LOGIN_NEED_MORE_PAIRS

Sorties

• E_PAIRS_OK → S_LOGIN_BUILD_CHALLENGE

---

S_LOGIN_NEED_MORE_PAIRS (pairs manquants)

Transitions

• E_ADD_PAIR → S_PAIR_MANAGEMENT
• E_RESYNC → S_SYNC_SERVICE
• E_BACK → S_SERVICE_LIST

---

S_LOGIN_BUILD_CHALLENGE (construction message à valider)

Actions

• A_GENERATE_NONCE
• A_BUILD_MESSAGEBASE_LOGIN
  • services_uuid = service_cible_uuid
  • types_uuid = type_login_uuid
  • timestamp = now
  • relays = relays[]
  • version logicielle
• A_ENCRYPT_LOGIN_MESSAGE
• A_CANONICALIZE_JSON
• A_CALC_HASH_LOGIN

Sorties

• E_CHALLENGE_READY → S_LOGIN_COLLECT_SIGNATURES

Erreurs

• X_CANONICALIZATION_FAIL
• X_ENCRYPT_FAIL

---

S_LOGIN_COLLECT_SIGNATURES (collecte signatures mFA)

Objectif

Obtenir toutes les signatures imposées par validateurs.

Sous-états internes (recommandé)

• S_LOGIN_SIG_LOCAL
• S_LOGIN_SIG_REMOTE_WAIT
• S_LOGIN_SIG_FETCH

Actions

• A_SIGN_LOCAL(hash_login, privkey_pair_local) → MsgSignature
• A_REQUEST_REMOTE_SIGNATURE(hash_login, context) (UI/QR/mots selon design)
• A_FETCH_SIGNATURES_BY_HASH(hash_login)
• A_VERIFY_SIGNATURES_SECP256K1
• A_CHECK_VALIDATORS_SATISFIED

Sorties

• E_SIGNATURES_COMPLETE → S_LOGIN_PUBLISH_PROOF
• E_SIGNATURES_INCOMPLETE → rester S_LOGIN_COLLECT_SIGNATURES

Erreurs

• X_SIGNATURE_INVALID
• X_SIGNATURE_TIMEOUT
• X_NONCE_REUSED (si cache nonce)
• X_PUBKEY_NOT_AUTHORIZED

---

S_LOGIN_PUBLISH_PROOF (publication preuve login)

Ordre strict

1. publier message chiffré sans signatures ni clés
2. publier message(s) de signature
3. publier message(s) de déchiffrement si nécessaire

Actions

• A_POST_MSG_CHIFFRE(hash_login, msg_login_chiffre)
• A_POST_SIGNATURES(hash_login, signatures[])
• A_POST_KEYS_IF_REQUIRED(hash_login, key_materials[])

Sorties

• E_PUBLISH_LOGIN_OK → S_LOGIN_VERIFY_LOCAL
• E_PUBLISH_LOGIN_PARTIAL → S_ERROR_RECOVERABLE

Erreurs

• X_RELAY_POST_FAIL

---

S_LOGIN_VERIFY_LOCAL (vérification locale finale)

Objectif

Le client démontre que la preuve est auto-cohérente et satisfaisante avant affichage.

Actions

• A_RELOAD_PUBLISHED_OBJECTS_IF_NEEDED
• A_VERIFY_CANONICAL_HASH(hash_login)
• A_VERIFY_SIGNATURES
• A_VERIFY_GRAPH_CONFORMITY
• A_VERIFY_ANTI_REPLAY(nonce, timestamp_window)

Sorties

• E_LOCAL_VERDICT_ACCEPT → S_LOGIN_SUCCESS
• E_LOCAL_VERDICT_REJECT → S_LOGIN_FAILURE

---

S_LOGIN_SUCCESS (connexion OK)

Sorties

• E_DONE → S_HOME

---

S_LOGIN_FAILURE (connexion KO)

Actions

• Afficher diagnostics : signatures manquantes, objets manquants, anti-rejeu, etc.

Sorties

• E_RETRY → S_LOGIN_BUILD_PATH (ou S_LOGIN_COLLECT_SIGNATURES selon cause)
• E_RESYNC → S_SYNC_SERVICE
• E_BACK → S_HOME

---

États d’erreur

S_ERROR_RECOVERABLE (erreur récupérable)

Objectif

Afficher une erreur explicite et proposer des actions de reprise.

Sorties possibles

• E_RETRY → état précédent
• E_SYNC_NOW → S_SYNC_GLOBAL
• E_OPEN_DIAGNOSTIC → S_DIAGNOSTIC
• E_BACK → S_HOME

---

S_ERROR_FATAL (erreur bloquante)

Objectif

Cas impossible à corriger sans intervention externe (ex : RNG indisponible).

Sorties

• E_EXIT → fin

---

S_DIAGNOSTIC (diagnostic hash / objet)

Actions

• A_FETCH_MSG_BY_HASH
• A_FETCH_SIGNATURES_BY_HASH
• A_FETCH_KEYS_BY_HASH
• A_TRY_DECRYPT
• A_VERIFY_HASH
• A_VERIFY_SIGNATURES
• A_VERIFY_VALIDATORS

Sorties

• E_BACK → S_HOME (ou état appelant)

Anti-rejeu et cohérence temporelle (contrainte transversale)

Règles

• Un login doit inclure un nonce_login unique.
• Le service (ou le validateur final) doit maintenir un cache nonce_vus par fenêtre temporelle.
• Le client doit également maintenir un cache local pour éviter de republier un nonce déjà utilisé.

Erreurs

• X_NONCE_REUSED : nonce déjà vu → rejet.
• X_TIMESTAMP_OUT_OF_WINDOW : timestamp trop ancien/futur → rejet.

Optimisation de scan (optionnel)

Bloom filter

• État utilisateur : activé/désactivé
• Effet : éviter de re-fetch massivement des hash déjà vus
• Limite : faux positifs → toujours confirmer par vérification hash

Merkle trees

• État utilisateur : activé/désactivé
• Effet : synchroniser par segments et preuves d’inclusion
• Limite : complexité de maintenance côté relais

Résumé des sorties réseau par phase

Synchronisation

• GET MsgChiffre (par fenêtre temporelle, éventuellement par service)
• GET MsgCle par hash (ciblé)
• GET MsgSignature par hash (ciblé)

Publication preuve (ordre strict)

• POST MsgChiffre (sans signatures ni clés)
• POST MsgSignature
• POST MsgCle (si requis)

Table des causes d’échec et état de reprise conseillé

• Contrat incomplet → S_SYNC_SERVICE puis S_LOGIN_BUILD_PATH
• Parent UUID manquant → S_SYNC_GLOBAL puis S_LOGIN_BUILD_PATH
• Message indéchiffrable (clé manquante) → S_SYNC_GLOBAL + fetch clés → retry
• Signature manquante → S_LOGIN_COLLECT_SIGNATURES + fetch signatures → retry
• Signature invalide → rester S_LOGIN_COLLECT_SIGNATURES (recollect)
• Pubkey non autorisée → S_LOGIN_BUILD_PATH (recalcul validateurs)
• Nonce rejoué → S_LOGIN_BUILD_CHALLENGE (nouveau nonce)
• Relais down → S_RELAY_SETTINGS ou S_PUBLISH_QUEUE avec retry/backoff

Catalogue des objets du projet (contrats, identité, pairing, login, relais)

Portée

Ce document recense l’ensemble des objets manipulés par le protocole :

• structure des contrats et des entités (service, contrat, champ, action, membre, pair),
• structure commune de message (MessageBase, hash, signature),
• objets de validation (validateurs, message à valider),
• objets cryptographiques séparés (message de signature, message individuel de déchiffrement),
• enveloppes réseau (messages chiffrés publiés sur relais),
• contraintes de publication et de récupération.

La règle principale est la séparation stricte :

• publication du message sans signatures ni clés,
• publication des signatures ensuite,
• publication des clés/matériels de déchiffrement ensuite.

Conventions et invariants

Types (types uuid et types names chiffrés)

Chaque objet porte un types_uuid et un types_names_chiffres incluant au minimum le type de l’objet. Le type name est chiffré et peut inclure des sous-types (ex : "login" pour ActionLogin).

Hash canonique

Le hash est calculé sur le JSON canonique de l’objet :

• sans le champ hash,
• sans la liste signatures,
• sans les champs cles_de_chiffrement (ou équivalents),
• sans tout bloc de signature ou matériel crypto posté séparément.

Le hash doit spécifier explicitement l’algorithme.

Signature secp256k1

Les signatures servent à prouver :

• l’intégrité (le hash),
• l’autorité (clé publique autorisée par validateurs),
• l’anti-rejeu (nonce / matériel additionnel éventuel).

Publication “pour tous”

Tous les messages sont publiés :

• sans destinataire explicite,
• sous forme chiffrée,
• récupérés par GET périodiques via relais.

Récupération séparée

Un GET de message ne doit pas renvoyer automatiquement :

• signatures,
• clés/matériels de déchiffrement. Ils sont récupérés par requêtes dédiées ensuite.

Structure commune : MessageBase

Rôle

Base obligatoire d’un message de l’écosystème. Supporte l’adressage (hash), l’indexation (uuid, version, type, service), et la synchronisation (timestamp, relais).

Champs obligatoires

• uuid : identifiant unique de l’objet
• version : version du schéma de cet objet
• types :
  • types_uuid : identifiant de type
  • types_names_chiffres : au minimum le type (ex : "pair", "membre", "contrat")
• cles_de_chiffrement : paramètres + algorithmes (présents dans le message complet, mais exclus du hash canonique)
• datajson :
  • obligatoires :
    • services_uuid[] : au moins 1
    • types_uuid[] : au moins 1
  • optionnels :
    • label
    • description_longue
    • description_courte
    • photo
    • image
    • banniere
    • url
    • paragraphes[] : couples texte + image
    • tarif
• timestamp : horodatage
• liste_relais[] : liste de relais (IP / endpoints)
• version_logicielle : version du client ayant produit le message

Champs dérivés / attachés après coup

• hash : hash canonique (stockable dans le message complet, mais calculé sans certains champs)
• signatures[] : non inclus dans le message publié initialement (posté séparément)

Objet : Hash

Rôle

Décrit le hash canonique d’un objet.

Champs

• algo : nom de l’algorithme (ex : sha256)
• hash_value : valeur du hash (encodage à spécifier)

Calcul

Le hash porte sur le JSON canonique :

• sans hash,
• sans signatures,
• sans clés de chiffrement.

Objet : Signature

Rôle

Preuve cryptographique associée à un hash.

Champs

• hash : hash signé (référence)
• cle_publique : clé publique secp256k1
• signature : signature cryptographique secp256k1
• nonce : anti-rejeu
• materiel : champs optionnels (ex : contexte, challenge, metadata anti-rejeu)

Contraintes

• La clé publique doit être autorisée selon les validateurs du message et/ou de l’action.
• Le nonce doit être unique dans la fenêtre de validité considérée.

Objet : Message à valider

Rôle

Enveloppe logique d’un message nécessitant validation contractuelle.

Composition

• MessageBase
• validateurs

Finalité

Permet de déterminer :

• quelles signatures sont requises,
• qui a autorité pour signer,
• quelles dépendances de signatures sont nécessaires.

Objet : Validateurs

Rôle

Définir les exigences de signatures, sous forme de règles par rôle/membre.

Champs

• membres_du_role[] : au moins 1

Pour chaque membre de rôle :

• signatures_obligatoires[] :
  • signatures exigées des autres membres et/ou de lui-même
  • cardinalité minimale (si modèle seuil)
  • dépendances éventuelles

Contraintes

• La liste des membres du rôle doit être non vide.
• Les signatures doivent pouvoir être résolues vers des clés publiques présentes dans le graphe (membre/pair).

Objet : Message de signature

Rôle

Publication séparée d’une ou plusieurs signatures associées à un message.

Champs obligatoires

• signature : structure Signature complète

Indexation recommandée

• hash_cible : hash du message ciblé (si non redondant avec signature.hash)

Cycle de vie

1. message publié sans signatures
2. message(s) de signature publiés ensuite et attachés localement au message ciblé

Objet : Message individuel de déchiffrement

Rôle

Publication séparée des éléments permettant de récupérer une clé de déchiffrement (ou une clé enveloppe).

Champs obligatoires

• hash_message : hash du message chiffré concerné
• cle_de_chiffrement_message :
  • clé de chiffrement du message chiffré
  • clé de chiffrement chiffrée (enveloppe)
  • paramètres et algorithmes complets
• df_ecdh_scannable :
  • matériel Diffie-Hellman à scanner
  • contient une clé (ou information) permettant de déchiffrer la clé enveloppe via secret partagé

Contraintes

• Le matériel DH est inutilisable sans possession d’une clé privée correspondante.
• Ce message doit pouvoir être filtré/identifié côté client lors d’un scan global.

Objet : Enveloppe réseau “message chiffré publié”

Rôle

Format minimal publié sur les relais pour la diffusion “pour tous”.

Champs

• hash : hash canonique du message (référence)
• message_chiffre : payload chiffré (opaque)
• datajson_public :
  • métadonnées non sensibles utiles au filtrage
  • doit inclure au minimum :
    • services_uuid[]
    • types_uuid[]
  • peut inclure :
    • timestamp
    • version
    • autres marqueurs de routage/filtrage

Contraintes

• Ne doit pas inclure signatures.
• Ne doit pas inclure clés de chiffrement.

Objets “contrats / identité”

Objet : Service

Rôle

Décrit un service, son identité contractuelle, et sert de racine à une authentification.

Champs spécifiques

• contrat_uuid : référence vers un Contrat
• types_names_chiffres inclut "service"

Contraintes

• Doit exister dans datajson.services_uuid[] des objets liés au service.
• Doit être résoluble via sync par service.

Objet : Contrat

Rôle

Contrat d’identité principal pour un service.

Champs spécifiques

• message_a_valider : base + validateurs applicables
• types_names_chiffres inclut "contrat"

Contraintes

• Le contrat doit être déchiffrable et validable pour autoriser des actions.

Objet : Champ

Rôle

Unité contractuelle rattachée à un ou plusieurs contrats.

Champs spécifiques

• message_a_valider
• types_names_chiffres inclut "champ"
• contrats_parents_uuid[] : au moins 1

Contraintes

• Au moins un parent contrat.
• Permet d’étendre la structure du contrat et des exigences.

Objet : Action

Rôle

Action exécutable dans le contexte du contrat. Contient ses propres validateurs.

Champs spécifiques

• message_a_valider
• types_names_chiffres inclut "action"
• validateurs_action
• contrats_parents_uuid[] : au moins 1

Contraintes

• Au moins un parent contrat.
• Les validateurs doivent être satisfaisables.

Objet : ActionLogin

Rôle

Spécialisation de Action, de type “login”.

Champs spécifiques

• action : référence Action
• types_names_chiffres inclut "login"

Contraintes

• Doit être identifiable comme action de login dans le graphe.
• Les signatures requises pour login sont tirées des validateurs de l’action.

Objet : Membre

Rôle

Identité d’un membre (acteur) autorisé à exécuter des actions, dont login.

Champs spécifiques

• message_a_valider
• types_names_chiffres inclut "membre"
• actions_parents_uuid[] : au moins 1

Contraintes

• Doit référencer au moins une action.
• Doit pouvoir être lié à un ou plusieurs pairs (devices).

Objet : Pair

Rôle

Représente un device/instance participant aux signatures (mFA).

Champs spécifiques

• MessageBase
• types_names_chiffres inclut "pair"
• membres_parents_uuid[] : au moins 1

Contraintes

• Pairing obligatoire : au moins un pair attendu doit être disponible pour login.
• L’UUID du pair sert d’identifiant uniquement (clé d’identification), pas de secret.

Conversion UUID pair ↔ mots (BIP32)

Rôle

Procédure robuste d’association pair ↔ membre sans échanger l’UUID brut.

Procédé

• UUID du pair converti via dérivation BIP32 en une liste de mots.
• Device A affiche les mots.
• Device B saisit les mots.
• Reconstitution de l’UUID du pair.

Contraintes

• La liste de mots doit inclure un checksum ou mécanisme de détection d’erreur.
• Les mots n’exposent pas de secret exploitable : l’UUID n’est qu’un identifiant.

Objet : Relais (entité réseau)

Rôle

Stocker et relayer des objets adressés par hash. Assurer une diffusion inter-relais.

Responsabilités minimales

• Stocker :
  • enveloppes MsgChiffre
  • messages MsgSignature
  • messages MsgCle
• Relayer entre relais
• Déduplication :
  • sauvegarder les hash reçus pour ne pas relayer deux fois

Contraintes

• Un relais ne doit pas “fusionner” message + signatures + clés lors d’un GET.
• Le client doit pouvoir GET par période et idéalement filtrer par service.

Catalogue des flux (rappel)

Publication d’un objet (ordre strict)

1. Publication MsgChiffre

• contient hash + message chiffré + datajson public
• sans signatures
• sans clés

2. Publication MsgSignature

• une ou plusieurs signatures (selon validateurs)
• attachées au hash

3. Publication MsgCle

• clés / matériels DH nécessaires au déchiffrement
• attachés au hash

Récupération côté client

1. GET MsgChiffre (pull périodique, par fenêtre)
2. Déduplication par hash
3. GET MsgCle (si candidat déchiffrable)
4. Déchiffrement, parsing, recalcul hash canonique
5. GET MsgSignature
6. Vérification secp256k1 + validateurs
7. Mise à jour graphe local

Conditions de login (rappel)

Pour se logguer, il faut :

• cibler un service_uuid,
• trouver l’ActionLogin du membre,
• satisfaire les validateurs de l’action login,
• fournir les signatures attendues des pairs requis,
• publier preuve (message → signatures → clés),
• permettre au service de vérifier la conformité contrat/signature sans serveur central.