anchorage_layer_simple/features/service-login-verify.md

Côté service – Acceptation de session et politique anti-rejeu (3.7)

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

Explication

Rôle du « service »

Le service est l’application parente qui embarque UserWallet en iframe. C’est elle qui consomme le login : elle reçoit la preuve de login (login-proof) via postMessage, doit l’accepter ou refuser pour ouvrir une session, sans serveur central.

• UserWallet (iframe) envoie { type: 'login-proof', payload: LoginProof } au parent.
• Le parent écoute window.addEventListener('message', ...), filtre event.data?.type === 'login-proof', puis vérifie la preuve avant d’accepter la session.

Acceptation de session

Le service doit vérifier la preuve en s’appuyant uniquement sur contrats + signatures :

1. Graphe contractuel : le service dispose du contrat (et contrats fils) du service, fourni par channel message ou contrat par défaut. Il peut en déduire l’action login, les membres, les validateurs.
2. Clés autorisées : à partir des validateurs de l’action login (membres_du_role[].signatures_obligatoires[].cle_publique), construire l’ensemble des cle_publique autorisées à signer. (Résolution pair_uuid → clé non utilisée côté service si seules les cle_publique explicites sont présentes.)
3. Vérification crypto : pour chaque signature de la preuve, vérifier qu’elle signe bien hash-nonce (hash du challenge + nonce) avec la cle_publique indiquée (secp256k1).
4. Conformité validateurs : toutes les signatures doivent provenir de clés autorisées ; au moins une signature valide est requise.
5. Anti-rejeu : nonce unique (cache nonce_vus), fenêtre temporelle sur le timestamp du challenge.

Aucune autorité centrale : la décision d’accepter ou refuser la session repose uniquement sur ces vérifications locales.

Politique anti-rejeu

• Nonce unique : chaque preuve utilise un nonce. Le service maintient un cache des nonces déjà vus (ex. NonceCache). Si un nonce est rejoué dans la fenêtre TTL, la preuve est refusée (X_NONCE_REUSED).
• Fenêtre timestamp : le timestamp du challenge doit être dans une fenêtre acceptable (ex. ±5 min). Sinon refus (X_TIMESTAMP_OUT_OF_WINDOW).
• Cache nonce_vus : persistance optionnelle (mémoire, IndexedDB, Redis, etc.). Le package fournit un cache en mémoire avec TTL configurable ; le service peut le remplacer par un stockage adapté.

Implémentation

Le package service-login-verify fournit :

• verifyLoginProof(proof, context) : vérification complète (crypto, clés autorisées, timestamp, nonce).
• NonceCache : cache anti-rejeu en mémoire (TTL configurable).
• buildAllowedPubkeysFromValidateurs(validateurs) : extraction des cle_publique depuis les validateurs de l’action login.

Le service (parent) :

1. Reçoit contrat + contrats fils (channel ou défaut).
2. Extrait l’action login et ses validateurs, construit allowedPubkeys via buildAllowedPubkeysFromValidateurs.
3. Maintient une NonceCache (ou équivalent).
4. À réception de login-proof, appelle verifyLoginProof(proof, { allowedPubkeys, nonceCache, timestampWindowMs }).
5. Si accept: true → ouvrir la session ; sinon → refuser et optionnellement informer l’utilisateur (ex. via postMessage vers l’iframe).

Limites

• Validateurs sans cle_publique (uniquement pair_uuid) : le service ne peut pas vérifier les clés autorisées. Il faut au moins une cle_publique dans signatures_obligatoires pour une vérification stricte côté service.
• Le service ne déchiffre pas le challenge ; il vérifie uniquement les signatures et l’anti-rejeu.

Utilisation

import {
  verifyLoginProof,
  NonceCache,
  buildAllowedPubkeysFromValidateurs,
} from 'service-login-verify';

const nonceCache = new NonceCache(3600000);
const allowedPubkeys = buildAllowedPubkeysFromValidateurs(actionLogin.validateurs_action);

window.addEventListener('message', (event) => {
  if (event.data?.type !== 'login-proof') return;
  const result = verifyLoginProof(event.data.payload, {
    allowedPubkeys,
    nonceCache,
    timestampWindowMs: 300000,
  });
  if (result.accept) {
    // ouvrir session
  } else {
    // refuser (result.reason)
  }
});

Références

• features/userwallet-contrat-login-reste-a-faire.md (§ 3.7)
• userwallet/docs/specs.md (graphe, validateurs, anti-rejeu)
• service-login-verify/ : implémentation (package à la racine du dépôt).
• website-skeleton/ : squelette de site qui intègre l’iframe et vérifie les preuves.