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

97 lines
7.9 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# 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`.
Reference in New Issue View Git Blame Copy Permalink