4nk/anchorage_layer_simple
5
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
anchorage_layer_simple/features/userwallet-contrat-login-reste-a-faire.md
ncantu 5de870fa13 Update login state machine and add new login components 
**Motivations:**
- Continue implementation of login state machine
- Add new login components for collect, share and sign screens
- Add utilities for login signing, validation, and publishing
- Update documentation for CNIL compliance and login workflow
- Add features for timeouts, backoff, and validator acceptance

**Root causes:**
- N/A (feature additions and improvements)

**Correctifs:**
- Update login state machine implementation
- Update graph resolver and sync service

**Evolutions:**
- Add LoginCollectShare and LoginSignScreen components
- Add useSignAndPostLogin hook
- Add login utilities: loginSign, loginPublish, loginValidation, collectSignatures
- Add sync utilities: syncUpdateGraph, syncValidate
- Add validatorsAccept utility
- Update App.tsx and LoginScreen.tsx
- Update loginBuilder and loginStateMachine services
- Add documentation for CNIL compliance, remote collection, timeouts, and validator acceptance
- Update identity types

**Pages affectées:**
- userwallet/src/App.tsx
- userwallet/src/components/LoginScreen.tsx
- userwallet/src/components/LoginCollectShare.tsx (new)
- userwallet/src/components/LoginSignScreen.tsx (new)
- userwallet/src/hooks/useSignAndPostLogin.ts (new)
- userwallet/src/services/graphResolver.ts
- userwallet/src/services/loginBuilder.ts
- userwallet/src/services/loginStateMachine.ts
- userwallet/src/services/syncService.ts
- userwallet/src/services/syncUpdateGraph.ts (new)
- userwallet/src/services/syncValidate.ts (new)
- userwallet/src/types/identity.ts
- userwallet/src/utils/relay.ts
- userwallet/src/utils/collectSignatures.ts (new)
- userwallet/src/utils/loginPublish.ts (new)
- userwallet/src/utils/loginSign.ts (new)
- userwallet/src/utils/loginValidation.ts (new)
- userwallet/src/utils/validatorsAccept.ts (new)
- userwallet/docs/synthese.md
- userwallet/docs/specs-champs-obligatoires-cnil.md
- userwallet/features/userwallet-acceptation-version-validateurs.md (new)
- userwallet/features/userwallet-dh-systematique-scan-fetch.md (new)
- features/userwallet-contrat-login-reste-a-faire.md
- features/userwallet-login-state-machine.md
- features/userwallet-validation-conformite.md
- features/userwallet-champs-obligatoires-cnil.md (new)
- features/userwallet-collecte-distante-2-devices.md (new)
- features/userwallet-timeouts-backoff.md (new)
- mempool (submodule)
- hash_list.txt
- hash_list_cache.txt
2026-01-26 15:04:07 +01:00

7.9 KiB
Raw Blame History

Contrat et login – reste à faire

Author: Équipe 4NK
Date: 2026-01-26

1. Principe (rappel)

Le login décentralisé repose sur :

  • Graphe contractuel : Service → Contrat → Champ → Action(login) → Membre → Pair ; contraintes « au moins 1 parent ».
  • Validateurs : signatures requises pour l’action login, liées aux pairs/membres du graphe.
  • Pairing mFA : obligatoire ; au moins un pair attendu par l’action login doit être disponible.
  • Publication en trois temps : message chiffré (sans sig ni clés) → signatures → clés ; tout adressé par hash canonique, récupéré par GET (pull-only).
  • Vérification locale : conformité graphe + signatures + anti-rejeu (nonce, fenêtre temporelle) ; pas d’autorité centrale.

Référence : userwallet/docs/specs.md (modèle, objets, machine à états, catalogue).

2. Déjà en place

  • Identité : création secp256k1, import (hex ou BIP39), protection par mot de passe, déverrouillage.
  • Pairing : 8 mots BIP32-style, WordInputGrid, confirmation croisée « membre finaliser », IndexedDB, statut « Connecté ».
  • Relais : config, health, GET/POST messages/signatures/keys, GET /bloom ; sync, HashCache (IndexedDB), dédup, fetch clés/signatures.
  • Graphe : GraphResolver, caches (services, contrats, champs, actions, membres, pairs), resolveLoginPath.
  • Login : LoginBuilder (challenge, nonce, chiffrement « for all »), construction preuve, publication message → signatures → clés. Anti-rejeu : NonceStore (IndexedDB), vérification timestamp (fenêtre), X_NONCE_REUSED / X_TIMESTAMP_OUT_OF_WINDOW avant publish.
  • Iframe : auth-request / auth-response / login-proof, useChannel, postMessage.
  • Écrans : Home, CreateIdentity, ImportIdentity, RelaySettings, Sync, Manage Pairs, Pairing (setup + display), Services, Login, Data Export/Import, Unlock. Navigation via GlobalActionBar.

3. Reste à faire (principes contrat & login)

3.1 Machine à états formelle

  • Fait : loginStateMachine (états S_LOGIN_, événements E_), useLoginStateMachine, dispatch dans LoginScreen, Retour → E_BACK ; G_PAIRING_SATISFIED, E_ADD_PAIR / E_SYNC_NOW. Timeouts : RELAY_FETCH_TIMEOUT_MS sur tous les fetch relay (GET/POST). Pas de backoff. Voir features/userwallet-login-state-machine.md, features/userwallet-timeouts-backoff.md.
  • À prévoir : timeouts sur collecte signatures (fetch relay) si distinct.

3.2 Écrans et UX alignés specs

À valider avant implémentation. Voir features/userwallet-ecrans-login-a-valider.md.

  • Service iframe : fourni par channel message (contrat + contrats fils). Si absent → contrat par défaut en dur dans le front jusqu’à réception.

  • Écrans login : déjà en place. Reste à faire : notifications selon événements relais (collecte signatures, clés de déchiffrement → hash à fetch → signatures, contrats, membres, pairs, actions, champs sur le relai).

  • Cette section évoluera avec l'avancement des tests une fois validée.

  • Sélection service / sélection membre : écrans dédiés « choisir le service cible du login » et « choisir le membre (quand plusieurs) » avec liste, statuts, validation des prérequis (action login, pairs).

  • Construction du chemin login : écran dédié avec résumé (service → contrat → action login → membre → pairs), tableau « signatures requises » (validateurs, qui doit signer, manquante/reçue/valide/invalide), boutons Synchroniser / Démarrer login.

  • Message de login à valider : écran avec résumé public (service, type, timestamp, relais), nonce (mode avancé), « signer ».

  • Collecte signatures mFA : écran listant les signatures requises (clé, pair/membre, état), actions « signer avec ce device », « demander signature sur autre pair », « rafraîchir » (fetch), « voir détail ».

  • Publication du login : écran dédié (ou étape claire) avec ordre strict message → signatures → clés, statut par relais, erreurs explicites.

  • Vérification locale + résultat : écran/étape « vérification locale finale » (hash, signatures, graphe, anti-rejeu) puis succès / échec avec diagnostics (signatures manquantes, objets manquants, etc.).

3.3 États et diagnostics visibles

  • Message reçu mais indéchiffrable (clé manquante) et message déchiffré mais non validé (signature manquante) : fait. Sync retourne indechiffrable et nonValide ; SyncScreen affiche « Indéchiffrables (clé manquante) » et « Non validés (ex. signature manquante) ».
  • Contrat incomplet : affichage explicite lorsque le graphe est incomplet (LoginScreen : path.statut === 'incomplet', erreur « Chemin incomplet »).
  • Statut par relais : fait. Sync retourne relayStatus (endpoint + ok) ; SyncScreen affiche « Statut relais » (OK / indisponible par relais).

3.4 Anti-rejeu et nonce

  • Nonce unique : fait. Chaque login utilise un nonce ; pas de republication du même nonce.
  • Cache nonce_vus : fait. NonceStore (IndexedDB, userwallet_nonce_cache), TTL 1 h ; init / hasUsed / markUsed. Vérification timestamp via verifyTimestamp (fenêtre 5 min).
  • Erreurs : fait. X_NONCE_REUSED, X_TIMESTAMP_OUT_OF_WINDOW avant publish ; messages explicites dans LoginScreen.

3.5 Validation et conformité

  • Fait : verifyMessageSignaturesStrict, filterSignaturesByAuthorizedPubkeys ; buildAllowedPubkeys (résolution cle_publique depuis pairs) ; checkCardinalitySupported (refus si cardinalite_minimale > 1) ; checkDependenciesSatisfied (membres des dependances doivent avoir ≥1 signature dans la preuve, via pair du membre) ; contrats version non supportée exclus ; contrat_version affiché. Voir features/userwallet-validation-conformite.md.
  • Fait : support de cardinalite_minimale > 1 via collecte distante (2 devices). Device 1 publie message + sigs locales, boucle de collecte (fetch sigs par hash), Device 2 signe via /login-sign?hash=...&nonce=... (lien/QR) et poste sa sig. Voir features/userwallet-collecte-distante-2-devices.md.

3.6 Scan et optimisation (optionnel)

  • Bloom filter : fait. getBloom(relay) ; utils/bloom → fetchAndLoadBloom ; sync fetch les Bloom, fetchKeys skip getKeys quand !bloom.has(hash) (pas de faux négatifs). Voir features/userwallet-bloom-usage-sync.md.
  • Merkle trees : checkpointing / accélération de scan (optionnel, non implémenté).

3.7 Côté service (hors userwallet)

  • Acceptation de session : le service (application qui consomme le login) doit vérifier la preuve en ne s’appuyant que sur contrats + signatures (sans serveur central). Rejouer la construction du graphe depuis les UUID/messages disponibles, vérifier hash, signatures, anti-rejeu.
  • Politique anti-rejeu : TTL nonce, fenêtre timestamp, cache nonce_vus.

4. Synthèse

Domaine Statut Priorité
Machine à états login Fait (loginStateMachine, useLoginStateMachine, dispatch) —
Écrans sélection service / membre, chemin login, collecte sig, publication, vérification À valider avant implémentation (voir userwallet-ecrans-login-a-valider) ; notifications relais à implémenter Haute
États « indéchiffrable » / « signature manquante » / statut relais visibles Fait (Sync) —
Anti-rejeu (nonce, fenêtre, cache) Fait (NonceStore, verifyTimestamp, X_*) —
Validation stricte validateurs + clé autorisée Fait (strict verify, version contrats) —
Version contrats Fait (supported check, affichage) —
Bloom API + usage sync Fait (getBloom, fetchAndLoadBloom, skip key fetch) —
Merkle (scan) Optionnel, non implémenté Basse

Les éléments de la section « Déjà en place » restent le socle ; les développements ci‑dessus les complètent pour coller au principe « contrat + login » décrit dans specs.md.