Description : Le payload attendu de POST /user/password/change n’est pas défini (nom exact des champs, présence/absence de confirmation). La spec mentionne la confirmation côté client PD‑106, mais ne contractualise pas si le backend la reçoit/valide.
Impact : Tests et implémentations peuvent diverger (champ confirmation ignoré ou exigé), rendant la conformité non vérifiable de façon déterministe.
Description : Le comportement en cas d’échec d’invalidation de sessions n’est pas borné (code d’erreur indiqué, mais statut HTTP, message, et état final côté client non précisés).
Impact : Risque de réponses non homogènes et difficulté à prouver CA‑239‑05.
Description : L’invalidation « de toutes les sessions » suppose une capacité système et une instantanéité non bornée (latence, propagation, tokens déjà émis). Aucun délai de prise d’effet n’est contractualisé.
Impact : Non‑déterminisme des tests et risque de faux positifs/négatifs sur CA‑239‑05.
Description : Exigence « message exploitable » sans contrainte de non‑divulgation peut introduire fuite d’information (ex. distinction trop précise entre ancien mot de passe invalide et politique). La spec ne borne pas le contenu admissible.
Impact : Risque d’énumération de politiques ou d’indices exploitables, et difficulté d’audit.