ECT-01 — Authentification JWT pour POST /auth/reauth¶
Verdict : VALIDE
Analyse : La specification (Sect. 2) indique explicitement "Authentification JWT obligatoire pour /user/mfa/*" mais /auth/reauth est sous un prefixe different (/auth/). Le flux F-238-06 mentionne "L'utilisateur appelle POST /auth/reauth avec son mot de passe" sans preciser le besoin d'un JWT prealable. Aucun critere d'acceptation ni code d'erreur ne couvre l'absence de JWT sur cet endpoint. L'ecart est reel et justifie.
Recommandation ajustee : Ajouter dans INV-238-XX une regle explicite : "POST /auth/reauth DOIT exiger un JWT valide" ou clarifier que l'endpoint est accessible sans authentification prealable (ce qui serait incoherent avec le flow prevu).
Analyse : INV-238-03 et CA-238-06 imposent le retour de method mais aucune valeur contractuelle n'est definie. La specification (Sect. 3) mentionne "TOTP" comme methode mais sans formaliser l'enum. La reference a PD-106 est presente mais les valeurs PD-106 ne sont pas reproduites dans PD-238. L'ecart est justifie car le test ne peut verifier qu'une valeur "valide" sans connaitre l'ensemble admis.
Recommandation ajustee : Definir explicitement method: enum("TOTP") avec possibilite d'extension future, ou referencer PD-106 avec section precise.
Analyse : Le "Points a clarifier #3" de la specification confirme que le format exact n'est pas specifie. Les tests (TC-NOM-01) verifient uniquement la presence du champ. Sans format contractuel (ISO 8601, epoch), l'interoperabilite avec PD-106 n'est pas garantie.
Recommandation ajustee : Specifier "ISO 8601 UTC" comme format obligatoire.
Analyse : L'ecart est partiellement valide. La specification reconnait deja cette limitation dans "Points a clarifier #2". Le champ expiresAt est retourne mais sa valeur depend de Keycloak. Cependant, ChatGPT le classe comme "Non-testable" alors que le test TC-NOM-02 verifie la presence du champ. La testabilite existe pour la structure, pas pour la coherence temporelle. La severite "Mineur" est correcte.
Recommandation ajustee : Clarifier que seule la presence de expiresAt est testable ; la validite temporelle releve du contrat Keycloak.
Analyse : Verification dans Tests §2 : la ligne indique "INV-238-02 | CA-238-03 | TC-ERR-04". INV-238-02 concerne l'acces croise ("Un utilisateur NE DOIT pouvoir consulter/modifier que son propre MFA"). CA-238-03 concerne "POST /user/mfa/totp/verify sans JWT est refuse" (authentication, pas autorisation). Le mapping est effectivement incorrect ; CA-238-03 devrait etre associe a INV-238-01 (JWT obligatoire).
Recommandation ajustee : INV-238-02 doit etre associe a un nouveau critere d'acceptation dedie a l'acces croise (ex: CA-238-16 a creer, ou renommer TC-ERR-04 vers scenario cross-access explicite).
Analyse : Verification dans Tests §2 : la ligne indique "INV-238-13 | CA-238-13 | TC-INV-01". INV-238-13 concerne les "erreurs explicites sans effet partiel silencieux". CA-238-13 concerne le "rate limiting". Le mapping est incoherent. Le test TC-INV-01 couvre bien INV-238-13 mais pas CA-238-13.
Recommandation ajustee : Corriger la matrice : INV-238-13 doit pointer uniquement vers TC-INV-01/TC-ERR-12, et CA-238-13 vers INV-238-11.
ECT-07 — Absence de code d'erreur pour reauth invalide¶
Verdict : VALIDE
Analyse : La section §6 (Cas d'erreur) ne definit aucun ERR-238-* pour l'echec de POST /auth/reauth avec mot de passe invalide. Les tests ne peuvent donc pas verifier un comportement contractuel. Le seul code mentionne est ERR-238-UNAUTHORIZED-REAUTH qui concerne le token reauth absent/invalide/expire, pas l'echec d'authentification initiale.
Recommandation ajustee : Ajouter ERR-238-REAUTH-FAILED pour l'echec de verification du mot de passe lors du reauth.
ECT-08 — Hypothese H-238-02 et risque d'acces croise¶
Verdict : PARTIEL
Analyse : L'ecart est partiellement valide. L'hypothese H-238-02 indique bien "Les claims OIDC permettent d'identifier l'utilisateur courant" avec impact "Acces croise possible" si faux. Cependant, INV-238-02 couvre deja l'exigence ("Un utilisateur NE DOIT pouvoir consulter/modifier que son propre MFA"). La recommandation de ChatGPT (verifier coherence sub JWT / identifiant Keycloak) est pertinente mais releve de l'implementation, pas de la specification fonctionnelle. La severite "Majeur" est excessive pour une hypothese explicitement documentee.
Recommandation ajustee : Ajouter dans les criteres d'acceptation un test explicite verifiant que sub JWT est utilise pour toute operation Keycloak (TC-NOM/TC-ERR additionnels).
ECT-09 — Surface d'audit des logs non contractualisee¶
Verdict : PARTIEL
Analyse : L'ecart est partiellement valide. La section Tests §8 (Observabilite) mentionne "Inspection des logs applicatifs (exclusion secrets)" mais sans definir exhaustivement les surfaces. Cependant, INV-238-09 est clair : "Le secret TOTP et les codes de recuperation NE DOIVENT jamais etre loggues". La specification est prescriptive sur le comportement, l'observabilite requise est une preoccupation de test, pas de specification. Severite "Mineur" appropriee.
Recommandation ajustee : Preciser dans le document de tests les surfaces de logs a auditer (logs applicatifs, metriques, traces APM).
ECT-10 — Validation claims sub/purpose du reauth token¶
Verdict : REJETE
Analyse : L'ecart est un faux positif. INV-238-12 definit explicitement : "POST /auth/reauth DOIT retourner un reauthToken JWT avec sub, purpose="reauth", exp = 5 minutes". CA-238-14 precise : "Reauth token retourne sub, purpose="reauth", exp (5 min)". Le test TC-NOM-06 verifie "Le JWT contient sub, purpose="reauth", exp a 5 minutes". La validation de ces claims est implicite dans l'exigence de conformite du token. De plus, TC-NEG-02 teste explicitement "Reauth token avec purpose != reauth → Refus operation sensible", prouvant que la validation est couverte.
Recommandation ajustee : Aucune action requise. L'exigence est testable via TC-NOM-06 (emission) et TC-NEG-02 (validation).
ECT-M01 — Absence de test pour reauth avec mot de passe invalide¶
Categorie : Non-testable / Cas d'erreur manquant
Localisation : Tests §4 (Scenarios de test – Cas d'erreur)
Description : Aucun test ne couvre le cas ou POST /auth/reauth est appele avec un mot de passe incorrect. Ce scenario est distinct de l'absence de reauth token (TC-ERR-05/07). Le comportement attendu (code erreur, message) n'est ni specifie ni teste.
Severite : Majeur
ECT-M02 — Absence de test pour disable/regenerate avec MFA inactif¶
Categorie : Cas d'erreur manquant
Localisation : Spec §6 (Cas d'erreur), Tests §4
Description : Les tests TC-NOM-04/05 partent du principe que le MFA est actif. Aucun test ne verifie le comportement si un utilisateur tente de desactiver un MFA deja inactif ou de regenerer des codes sans MFA actif. La specification ne definit pas ce comportement (idempotence ou erreur ?).
Justification : La review ChatGPT identifie correctement 6 ecarts valides et 3 partiellement valides sur 10. Un ecart (ECT-10) est rejete car la validation des claims reauth est couverte par TC-NEG-02. Deux ecarts manques sont identifies, dont un majeur (absence de test pour reauth invalide). Les incoherences de matrice (ECT-05, ECT-06) sont confirmees et doivent etre corrigees. L'absence de definition du code d'erreur pour reauth invalide (ECT-07) et l'ambiguite sur le JWT pour /auth/reauth (ECT-01) sont les points bloquants a resoudre avant passage en phase implementation.