PD-24 — Acceptabilité¶

📚 Navigation User Story

| Document | | | ---------- | -- | | 📋 [Spécification](PD-24-specification.md) | | | 🛠️ [Plan d'implémentation](PD-24-plan.md) | | | ✅ **Critères d'acceptation** | *(ce document)* | | 📝 [Retour d'expérience](PD-24-rex.md) | | [← Retour à crypto-proof](../PD-189-epic.md) · [↑ Index User Story](index.md)

Objectif¶

Vérifier que l’implémentation est conforme à la spécification, respecte l’ensemble des invariants ProbatioVault et ne présente aucune incohérence ou oubli critique.

Périmètre de vérification¶

La revue d’acceptabilité vérifie explicitement :

la conformité stricte à la spécification fonctionnelle
le respect de tous les invariants applicables
la couverture des scénarios de test définis
l’absence d’incohérences, oublis ou régressions

Écarts identifiés¶

Chaque écart constaté est documenté et classé selon sa gravité.

Classification des écarts¶

Niveau	Définition
BLOQUANT	Violation d’un invariant, faille de sécurité, non-conformité majeure à la spec
MAJEUR	Fonction incomplète, comportement non conforme mais sans rupture de sécurité
MINEUR	Détail, dette acceptable, amélioration non critique

Détail des écarts¶

ID	Description	Référence	Gravité
E-01	La réponse `POST /auth/login/challenge` ne retourne que `{ salt, B }` alors que TA-2 attend `{ salt, B, N, g }`. Choix d’architecture valide (N/g constants exposés via GET /auth/srp-params) mais la spec et l’API divergent ; à aligner (ajouter N/g dans la réponse ou mettre à jour TA-2).	Spec TA-2 Initialisation SRP, auth.service.loginChallenge (retour salt/B)	MINEUR
E-02	Absence de rate limiting / protection DoS sur `/auth/login/challenge` malgré la contrainte « Limitation des tentatives » du plan Phase 6 et de la spec.	Spec « Contraintes » (limitation des tentatives), Plan Phase 6 Sécurité, auth.controller / auth.service (pas de rate limiting)	MAJEUR
E-03	Couverture de tests cryptographiques incomplète : aucun test de conformité aux vecteurs RFC 5054 ni de validation B mod N ≠ 0 / u ≠ 0 (exigé par le plan Phase 7). Les tests actuels se limitent à des validations de format.	Plan Phase 7 Tests (vecteurs RFC 5054), src/modules/auth/services/srp.service.spec.ts	MINEUR

[2026-01-12] — Suivi E-01¶

Statut précédent : OUVERT
Statut actuel : RÉSOLU
Justification factuelle : La spécification TA-2 est alignée sur le retour {salt, B} avec N/g fournis via GET /auth/srp-params (constants RFC 5054) ; l’implémentation existante est conforme.
Preuve de vérification : PD-24-specification.md (challenge {salt, B} + endpoint srp-params), auth.service.loginChallenge.

[2026-01-12] — Suivi E-02¶

Statut précédent : OUVERT
Statut actuel : RÉSOLU
Justification factuelle : Rate limiting implémenté sur /auth/login/challenge (LoginRateLimitGuard) avec seuil par défaut 5 requêtes/60s, réponse 429 homogène, logs hashés, audit LOGIN_RATE_LIMITED, tests login-rate-limit.guard.spec.ts (11 PASS).
Preuve de vérification : auth.controller.ts (@UseGuards LoginRateLimitGuard), rate-limit.service.ts, rate-limit.config.ts, login-rate-limit.guard.spec.ts.

[2026-01-12] — Suivi E-03¶

Statut précédent : OUVERT
Statut actuel : RÉSOLU
Justification factuelle : Contrôles B mod N ≠ 0, u ≠ 0 ajoutés (srp.service.ts:157-184, 208-211) et tests associés PASS ; traitement d’erreur BadRequest si u = 0.
Preuve de vérification : srp.service.ts, srp.service.spec.ts (tests sécurité ajoutés).

Conclusion d’acceptabilité¶

✅ ACCEPTÉ (écarts E-01, E-02, E-03 résolus)

Historique des verdicts¶

Date	Verdict	Version / commit	Commentaire
2026-01-12	✅ ACCEPTÉ	non renseigné	Écarts E-01..E-03 résolus (spec TA-2 alignée, rate limiting implémenté, tests SRP sécurité ajoutés)
(antérieur)	⚠️ ACCEPTÉ AVEC RÉSERVES	non renseigné	Écarts E-01..E-03 ouverts