PD-99 — Expression de Besoin¶

Intitulé : Écran de connexion utilisateur (SRP-6a) EPIC : PD-195 — MOBILE-iOS

1. Contexte¶

Le projet ProbatioVault dispose déjà :

• d’un parcours d’inscription et de validation utilisateur opérationnel,
• d’un socle d’identité et de gestion de session existant,
• d’une application mobile iOS fonctionnelle.

La présente Expression de Besoin concerne exclusivement l’écran de connexion permettant à un utilisateur déjà inscrit de s’authentifier depuis l’application mobile iOS.

L’architecture a acté l’usage du protocole SRP-6a pour l’authentification. Ce choix n’est pas remis en question dans ce document et constitue un cadre imposé.

L’écran de login est un point d’entrée critique vers des données personnelles et probatoires. L’acte de connexion engage la responsabilité de l’utilisateur et conditionne la valeur de l’ensemble du système.

2. Objectifs principaux¶

• Permettre à un utilisateur existant de s’authentifier à partir :
• d’un identifiant de type email,

• d’un mot de passe défini lors de l’inscription.

• Réaliser cette authentification selon un mécanisme SRP-6a, impliquant un échange de type challenge / response, sans transmission exploitable du mot de passe.

• Présenter cet accès sous la forme d’un écran de connexion clair, sobre et compréhensible, utilisable sans connaissance technique.
• Matérialiser explicitement que :
• le mot de passe est strictement personnel,
• personne, y compris les équipes ProbatioVault, ne connaît ni ne connaîtra jamais ce mot de passe,

• le mot de passe ne sera jamais demandé ailleurs que sur cet écran.

• Gérer les tentatives de connexion, qu’elles aboutissent ou échouent, sans divulguer d’information exploitable.

• Offrir une connexion facilitée par biométrie, considérée comme un confort optionnel, dérivé d’une authentification fondatrice préalable.
• Traiter l’acte de login comme un acte engageant, et non comme un simple geste fonctionnel.

3. Non-objectifs (exclusions explicites)¶

La PD-99 ne vise pas à :

• Créer, modifier ou valider une identité utilisateur.
• Traiter l’inscription, la création de compte ou l’enrôlement initial.
• Choisir ou configurer un fournisseur d’identité ou un protocole d’authentification alternatif.
• Mettre en place un mécanisme autre que SRP-6a.
• Décrire le fonctionnement cryptographique interne de SRP-6a.
• Gérer la récupération, la réinitialisation ou le changement de mot de passe.
• Définir des politiques globales de sécurité (verrouillage, quotas, délais).
• Optimiser les performances ou la rapidité perçue.

4. Contraintes (juridiques, temporelles, organisationnelles)¶

Contraintes juridiques¶

• L’acte de connexion doit pouvoir être considéré comme l’expression volontaire d’un accès à des données sensibles.
• L’interface ne doit jamais laisser entendre que :
• le mot de passe est stocké,
• le mot de passe est accessible à une personne humaine,

• le serveur pourrait se substituer à l’utilisateur.

• Les messages d’erreur ne doivent pas permettre d’inférer :

• l’existence d’un compte,
• la validité d’un identifiant,
• la nature précise d’un échec.

Contraintes organisationnelles¶

• L’écran de login doit être compréhensible sans accompagnement.
• Il doit être cohérent avec le discours global de ProbatioVault : sécurité forte, contrôle utilisateur, sobriété.

Contraintes temporelles¶

• La connexion peut intervenir dans des contextes d’urgence ou de stress.
• L’utilisateur doit comprendre rapidement s’il est connecté ou non, sans ambiguïté.

5. Scénarios d’échec et résultats inacceptables¶

Sont considérés comme inacceptables :

• Un message distinguant explicitement :
• email inconnu,
• mot de passe incorrect,
• compte non valide,

• indisponibilité interne.

• Une différence de comportement observable entre ces cas.

• Une interface laissant penser que le mot de passe :
• est transmis tel quel,
• est récupérable,

• pourrait être communiqué au support.

• Une authentification biométrique perçue comme :

• obligatoire,
• autonome,

• suffisante sans le secret initial.

• Une situation où l’utilisateur ne sait pas s’il est réellement authentifié.

• Toute ambiguïté exploitable en cas de litige, d’audit ou de contestation.

6. Tensions et conflits non résolus (assumés)¶

• Clarté utilisateur vs non-divulgation d’information
• Fluidité d’usage vs gravité de l’acte
• Confort biométrique vs responsabilité personnelle

Ces tensions sont acceptées et non résolues à ce stade.

7. Décisions actées et invariants¶

• L’usage de SRP-6a est un invariant.
• La première connexion (email + mot de passe) et la connexion facilitée (biométrie) sont visuellement différenciées sur l’écran de login.
• Cette différenciation s’arrête à l’écran de connexion ; aucun marqueur persistant n’est conservé après.
• La biométrie est optionnelle et désactivable :
• globalement,

• et/ou appareil par appareil.

• Il n’est pas nécessaire de distinguer explicitement une première connexion sur un nouvel appareil.

• L’utilisateur doit voir sans ambiguïté quelles données sont synchronisées localement et lesquelles ne le sont pas.
• Le terme « mot de passe » est retenu.
• L’écran de login rappelle explicitement que le mot de passe est irrécupérable.
• Les messages d’erreur sont neutres et non ambigus, sans indication de cause.
• Le login est un acte engageant, pas un simple passage technique.

Fin de l’Expression de Besoin — PD-99