PD-106 - Ecran Settings iOS (Profil, MFA TOTP, securite et compte)¶

1. Objectif¶

Definir le contrat fonctionnel de l'ecran Settings iOS pour : - consulter le profil en lecture seule ; - gerer le MFA TOTP (etat, activation, desactivation, codes de recuperation) ; - changer le mot de passe ; - se deconnecter ; - supprimer son compte.

Le contrat privilegie securite, robustesse, conformite et observabilite des comportements.

2. Perimetre / Hors perimetre¶

Inclus¶

• Parcours Settings unique permettant d'acceder aux fonctions Profil, MFA, mot de passe, deconnexion, suppression de compte.
• Affichage du profil en lecture seule (nom, email, avatar ou initiales).
• Affichage de l'etat MFA depuis le serveur (active/desactive, methode).
• Activation MFA TOTP avec verification du code utilisateur.
• Desactivation MFA avec confirmation explicite.
• Consultation/affichage des codes de recuperation selon les regles de securite de cette spec.
• Regeneration des codes de recuperation avec invalidation des anciens.
• Changement de mot de passe (ancien, nouveau, confirmation).
• Deconnexion avec invalidation de session serveur.
• Suppression de compte avec confirmation renforcee et re-authentification.

Exclu¶

• Modification des endpoints backend existants.
• Ajout de nouvelles methodes MFA (SMS, email, WebAuthn).
• Flux de login MFA (saisie TOTP a la connexion).
• Edition du profil (nom, email, avatar).
• Parametres biometrie/auto-lock existants hors parcours PD-106.
• Android.
• Preuve exhaustive de purge RGPD backend (voir section 4, hors perimetre PD-106).

3. Definitions¶

• MFA : authentification multi-facteur.
• TOTP : mot de passe a usage unique base sur le temps.
• Etat MFA : etat courant du compte (active ou desactive) et methode configuree.
• Operation critique : activation/desactivation MFA, regeneration des codes de recuperation, changement de mot de passe, suppression de compte.
• Re-authentification : preuve recente d'identite acceptee par la politique serveur pour autoriser une operation critique ; elle DOIT etre validee dans les 5 minutes precedant l'execution de l'operation critique, dans le meme flux de navigation, sans sortie vers un autre parcours ; la re-authentification est invalidee si l'utilisateur navigue vers un ecran hors du parcours Settings en cours (pile de navigation active interrompue ou quittee) ; cette borne temporelle est evaluee par le serveur.
• Codes de recuperation : codes de secours permettant l'acces en cas d'indisponibilite du facteur TOTP.
• Affichage unique : affichage en clair autorise uniquement pour la reponse serveur de generation/regeneration qui vient d'etre recue sur le device courant ; si l'utilisateur ferme puis rouvre l'ecran sans nouvelle generation/regeneration, aucun code en clair NE DOIT etre reaffiche.
• Confirmation renforcee : double validation explicite obligatoire dans le meme flux (validation initiale puis confirmation finale).
• Message/erreur exploitable : message affiche dans la langue active contenant au minimum soit un identifiant d'erreur stable, soit un motif textuel actionnable par l'utilisateur.
• Stockage local durable : toute surface de persistance locale surviveant a la fermeture ou au redemarrage de l'application, incluant Keychain, AsyncStorage, SQLite, UserDefaults et fichiers applicatifs/cache persistants.
• Logs applicatifs : toute emission de journal cote client ; en environnement de test, les surfaces auditables sont console, journaux systeme et logs de debug exportables ; les services tiers de crash reporting/telemetrie sont hors surface d'audit quand l'acces n'est pas garanti.
• Hors perimetre : exigence non verifiable dans le cadre de PD-106 mobile seul, devant etre prouvee par un autre artefact.

4. Invariants (non negociables)¶

5. Flux nominaux¶

F-106-01 - Acces Settings et consultation profil¶

1. L'utilisateur ouvre le parcours Settings.
2. Le systeme charge les informations de profil et l'etat MFA depuis le serveur.
3. Le systeme affiche le profil en lecture seule et identifie le compte connecte.
4. Si l'etat MFA est indisponible, le systeme affiche etat inconnu (pas de valeur stale).

F-106-02 - Activation MFA TOTP¶

1. L'utilisateur demande l'activation MFA.
2. Le systeme exige une re-authentification.
3. Si re-authentification validee, le systeme initie l'enrolement TOTP et affiche les informations d'enrolement sensibles avec avertissement.
4. L'utilisateur saisit un code TOTP de verification.
5. Le systeme soumet la verification au serveur.
6. En cas de succes, le systeme marque MFA active, affiche les codes de recuperation en affichage unique, puis recharge l'etat MFA serveur.

F-106-03 - Consultation et regeneration des codes de recuperation¶

1. L'utilisateur accede a la section codes de recuperation.
2. Si aucun affichage unique n'est disponible dans le contexte courant, le systeme n'affiche aucun code en clair et propose la regeneration.
3. La regeneration exige confirmation explicite et re-authentification.
4. En cas de succes serveur, le systeme invalide les anciens codes, affiche le nouveau jeu en affichage unique avec avertissement.

F-106-04 - Desactivation MFA¶

1. L'utilisateur demande la desactivation MFA.
2. Le systeme affiche une confirmation explicite.
3. Le systeme exige une re-authentification.
4. En cas de succes serveur, le systeme passe l'etat MFA a desactive et recharge l'etat serveur.

F-106-05 - Changement de mot de passe¶

1. L'utilisateur renseigne ancien mot de passe, nouveau mot de passe, confirmation.
2. Le systeme refuse localement si confirmation differente.
3. Le systeme exige une re-authentification.
4. Le systeme soumet la demande au serveur.
5. En cas de refus (complexite, ancien mot de passe invalide, etc.), le motif exploitable est affiche.
6. En cas de succes, le systeme invalide la session courante cote serveur, efface les donnees sensibles locales de session et redirige l'utilisateur vers un etat non authentifie.

F-106-06 - Deconnexion¶

1. L'utilisateur demande la deconnexion.
2. Le systeme affiche une confirmation explicite.
3. Le systeme appelle l'invalidation de session serveur.
4. Le systeme efface les donnees sensibles locales de session.
5. L'utilisateur est redirige vers un etat non authentifie.

F-106-07 - Suppression de compte¶

1. L'utilisateur ouvre l'action de suppression de compte.
2. Le systeme affiche un avertissement d'irreversibilite.
3. Le systeme exige une confirmation renforcee.
4. Le systeme exige une re-authentification.
5. Le systeme soumet la suppression au serveur.
6. En cas de succes, l'utilisateur est deconnecte ; le compte n'est plus reutilisable.

5bis. Diagrammes¶

Diagramme d'etats -- Etat MFA du compte¶

L'etat MFA observable cote application suit trois etats derives de la reponse serveur (INV-106-04). Toute mutation MFA declenche une relecture serveur.

stateDiagram-v2
    [*] --> inconnu : Ouverture Settings\n(lecture serveur en cours)

    inconnu --> active : Reponse serveur\nmfa_enabled=true
    inconnu --> desactive : Reponse serveur\nmfa_enabled=false
    inconnu --> inconnu : Echec lecture serveur\n[ERR-106-MFA-STATE-UNAVAILABLE]

    desactive --> active : Activation TOTP confirmee\npar le serveur (INV-106-07)
    active --> desactive : Desactivation confirmee\npar le serveur (INV-106-11)

    active --> inconnu : Relecture serveur\napres mutation
    desactive --> inconnu : Relecture serveur\napres mutation

    note right of inconnu
        INV-106-04 : etat inconnu si lecture echoue.
        Operations MFA bloquees dans cet etat
        [ERR-106-MFA-STATE-UNAVAILABLE].
    end note

Diagramme de sequence -- Activation MFA TOTP (F-106-02)¶

Flux multi-service impliquant re-authentification (INV-106-05), enrolement TOTP, verification du code et affichage unique des codes de recuperation (INV-106-08, INV-106-09).

sequenceDiagram
    actor U as Utilisateur
    participant App as App iOS
    participant Srv as Backend API

    U->>App: Demande activation MFA
    App->>U: Exige re-authentification (INV-106-05)
    U->>App: Saisie credentials
    App->>Srv: POST /auth/reauth
    Srv-->>App: 200 OK (token reauth)

    App->>Srv: POST /mfa/totp/init (token reauth)
    Srv-->>App: 200 {secret, otpauth_uri, recovery_codes_pending}
    App->>U: Affiche QR code / secret TOTP\n+ avertissement (INV-106-08)

    U->>App: Saisie code TOTP de verification
    App->>Srv: POST /mfa/totp/verify {code}

    alt Code valide
        Srv-->>App: 200 {recovery_codes}
        App->>U: MFA active + codes de recuperation\nen affichage unique (INV-106-09)
        Note over App: Secret TOTP et codes NON persistes\nen stockage local durable (INV-106-08)
        App->>Srv: GET /mfa/status (relecture INV-106-04)
        Srv-->>App: 200 {enabled: true, method: TOTP}
    else Code invalide
        Srv-->>App: 401 ERR-106-MFA-CODE-INVALID
        App->>U: Message erreur explicite (INV-106-16)
    end

Diagramme de sequence -- Suppression de compte (F-106-07)¶

Flux a confirmation renforcee (INV-106-14) avec re-authentification non reutilisable (INV-106-06).

sequenceDiagram
    actor U as Utilisateur
    participant App as App iOS
    participant Srv as Backend API

    U->>App: Ouvre action suppression
    App->>U: Avertissement irreversibilite (INV-106-14)

    U->>App: Confirmation renforcee etape 1
    App->>U: Confirmation renforcee etape 2
    U->>App: Validation finale

    App->>U: Exige re-authentification (INV-106-05)
    U->>App: Saisie credentials
    App->>Srv: POST /auth/reauth
    Srv-->>App: 200 OK (token reauth)

    App->>Srv: DELETE /account (token reauth)

    alt Succes
        Srv-->>App: 200 OK
        App->>App: Efface donnees sensibles locales (INV-106-13)
        App->>U: Redirige etat non authentifie (INV-106-15)
    else Echec serveur
        Srv-->>App: 5xx ERR-106-DELETE-FAILED
        App->>U: Message erreur explicite (INV-106-16)\nCompte reste actif
    end

6. Cas d'erreur¶

7. Criteres d'acceptation (testables)¶

8. Scenarios de test (Given / When / Then)¶

Scenario 1 - Consultation initiale Settings¶

GIVEN - utilisateur authentifie ; - backend profil et etat MFA disponibles.

WHEN - l'utilisateur ouvre Settings.

THEN - le profil est visible en lecture seule ; - le compte est clairement identifie ; - l'etat MFA reflete la reponse serveur courante.

Scenario 2 - Activation MFA TOTP nominale¶

GIVEN - utilisateur authentifie ; - MFA desactive ; - re-authentification valide.

WHEN - l'utilisateur active MFA puis soumet un code TOTP valide.

THEN - MFA devient active ; - les codes de recuperation sont affiches une seule fois avec avertissement ; - l'etat MFA est recharge depuis le serveur.

Scenario 3 - Activation MFA avec code invalide¶

GIVEN - utilisateur dans le flux d'activation MFA ; - re-authentification valide.

WHEN - l'utilisateur soumet un code TOTP invalide.

THEN - MFA reste desactive ; - un message d'erreur explicite est affiche ; - aucun etat de succes n'est affiche.

Scenario 4 - Operation critique sans re-authentification¶

GIVEN - utilisateur authentifie ; - operation critique choisie (ex. desactivation MFA).

WHEN - l'utilisateur tente d'executer l'operation sans re-authentification valide.

THEN - l'operation est refusee ; - l'etat metier reste inchange ; - un message explicite est affiche.

Scenario 5 - Consultation codes hors affichage unique¶

GIVEN - utilisateur authentifie ; - aucun evenement recent de generation/regeneration de codes.

WHEN - l'utilisateur ouvre la section codes de recuperation.

THEN - aucun code en clair n'est affiche ; - le systeme indique que la regeneration est necessaire.

Scenario 6 - Regeneration codes de recuperation¶

GIVEN - utilisateur authentifie ; - re-authentification validee ; - confirmation explicite validee.

WHEN - l'utilisateur regenere les codes.

THEN - un nouveau jeu de codes est affiche en affichage unique ; - les anciens codes deviennent invalides.

Scenario 7 - Changement mot de passe refuse (politique serveur)¶

GIVEN - utilisateur authentifie ; - ancien mot de passe saisi ; - nouveau mot de passe ne respectant pas la politique serveur.

WHEN - l'utilisateur soumet la demande.

THEN - la modification est refusee ; - un message exploitable indique la raison ; - le mot de passe reste inchange.

Scenario 8 - Deconnexion nominale¶

GIVEN - utilisateur authentifie avec session active.

WHEN - l'utilisateur confirme la deconnexion.

THEN - la session serveur est invalidee ; - les donnees sensibles locales de session sont effacees ; - l'application revient en etat non authentifie.

Scenario 9 - Suppression de compte nominale¶

GIVEN - utilisateur authentifie ; - confirmation renforcee valide ; - re-authentification valide.

WHEN - l'utilisateur confirme la suppression de compte.

THEN - le compte est supprime cote serveur ; - l'utilisateur est deconnecte ; - une tentative ulterieure d'utilisation du compte echoue.

Scenario 10 - Suppression de compte annulee (confirmation invalide)¶

GIVEN - utilisateur sur le flux suppression.

WHEN - la confirmation renforcee est incorrecte ou incomplete.

THEN - la suppression n'est pas executee ; - un message explicite est affiche ; - le compte reste actif.

9. Hypotheses explicites¶

10. Points a clarifier¶

1. Contrat exact des endpoints backend (requete/reponse, codes HTTP, erreurs) pour MFA, mot de passe, logout, suppression compte.
2. Format exact de la donnee d'enrolement TOTP renvoyee (URI otpauth:// complete, secret brut, autres metadonnees).
3. Politique de re-authentification par operation critique (facteurs autorises).
4. RESOLU - la consultation des codes hors phase de generation/regeneration est interdite (voir F-106-03 etape 2).
5. Arbitrage UX global : ecran unique vs sous-ecrans, et articulation avec ProfileScreen et SecuritySettingsScreen.
6. Regles serveur de complexite mot de passe a rendre visibles a l'utilisateur.
7. Politique de retention/purge post-suppression (delais, anonymisation, journaux), requise pour preuve RGPD article 17.

References¶

• Epic : PD-195 - Application mobile iOS zero-knowledge
• JIRA : PD-106
• Repos concernes : ProbatioVault-app
• Documents associes : PD-106-besoin.md