6bf37be44e
**Motivations:** - Consigner l'état actuel du dépôt (cron, service-login-verify, website-skeleton, userwallet, docs). - Centraliser les modifications en attente. **Root causes:** - N/A (commit groupé). **Correctifs:** - N/A. **Evolutions:** - Cron quotidien restart services : script local sans SSH, systemd (bitcoin-signet, bitcoin, APIs, dashboard, userwallet, website-skeleton) + Docker (mempool, bitcoin-signet-instance). - Feature cron-restart-services-local : documentation et règle scripts locaux / pas d'SSH. - service-login-verify : module vérification login (buildAllowedPubkeys, verifyLoginProof, nonceCache). - website-skeleton : app iframe UserWallet, config, systemd unit. - userwallet : collectSignatures, relay. - docs : DOMAINS_AND_PORTS, README, WEBSITE_SKELETON ; features userwallet-contrat-login, timeouts-backoff, service-login-verify. **Pages affectées:** - data/restart-services-cron.sh, data/restart-services.log, data/sync-utxos.log - features/cron-restart-services-local.md, features/service-login-verify.md, features/userwallet-contrat-login-reste-a-faire.md, features/userwallet-timeouts-backoff.md - docs/DOMAINS_AND_PORTS.md, docs/README.md, docs/WEBSITE_SKELETON.md - configure-nginx-proxy.sh - service-login-verify/ (src, dist, node_modules) - userwallet/src/utils/collectSignatures.ts, userwallet/src/utils/relay.ts - website-skeleton/
97 lines
8.8 KiB
Markdown
97 lines
8.8 KiB
Markdown
# 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. **Notifications relais** : `runCollectLoop` `onProgress`, `collectProgress`, affichage « Signatures collectées : X / Y » dans LoginCollectShare. **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). **Collecte** : timeout distinct `COLLECT_FETCH_TIMEOUT_MS` pour chaque GET /signatures pendant la boucle de collecte (`CollectLoopOpts.fetchTimeoutMs`, `fetchSignaturesForHash(..., fetchTimeoutMs)`). Pas de backoff. Voir `features/userwallet-login-state-machine.md`, `features/userwallet-timeouts-backoff.md`.
|
||
|
||
### 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. **Notifications relais** : progression collecte signatures (X/Y) implémentée via `onProgress` dans `runCollectLoop` et affichage dans `LoginCollectShare` ; voir `features/userwallet-notifications-relais.md`. Reste à faire : réagir à d’autres événements relais si extension (ex. push) — hash à fetch pour signatures, contrats, membres, pairs, actions, champs.
|
||
- 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. **Implémenté** : package `service-login-verify` (`verifyLoginProof`, `buildAllowedPubkeysFromValidateurs`, `NonceCache`). Voir `features/service-login-verify.md`.
|
||
- **Politique anti-rejeu** : TTL nonce, fenêtre timestamp, cache nonce_vus. **Implémenté** : `NonceCache` (mémoire, TTL configurable), `verifyTimestamp` dans `verifyLoginProof`, `timestampWindowMs` optionnel.
|
||
|
||
---
|
||
|
||
## 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 (progression X/Y) fait (userwallet-notifications-relais) | 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 |
|
||
| Côté service (acceptation session, anti-rejeu) | Fait (`service-login-verify`) | — |
|
||
|
||
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`.
|