Project

General

Profile

Development #32876

Faire que la configuration par défaut verrouille la civilité

Added by Marie Kuntz 4 months ago. Updated 2 months ago.

Status:
Solution proposée
Priority:
Normal
Category:
-
Target version:
-
Start date:
07 May 2019
Due date:
% Done:

0%

Patch proposed:
Yes
Planning:
No

Description

Demande de FranceConnect suite à la nouvelle procédure

0001-franceconnect-maps-FC-gender-to-Publik-title-32876.patch View (1.67 KB) Benjamin Dauvergne, 07 May 2019 05:35 PM

0001-franceconnect-maps-FC-gender-to-Publik-title-32876.patch View (8 KB) Benjamin Dauvergne, 09 May 2019 06:13 PM

0002-franceconnect-maps-FC-gender-to-Publik-title-32876.patch View (6.85 KB) Benjamin Dauvergne, 09 May 2019 07:45 PM

0001-tests-share-login-and-admin_user-32876.patch View (7.14 KB) Benjamin Dauvergne, 09 May 2019 07:45 PM

0002-franceconnect-maps-FC-gender-to-Publik-title-32876.patch View (6.85 KB) Benjamin Dauvergne, 09 May 2019 08:36 PM

0001-tests-share-login-and-admin_user-32876.patch View (7.14 KB) Benjamin Dauvergne, 09 May 2019 08:36 PM


Related issues

Related to Publik - Development #27081: Intégration cahier des charges FranceConnect Nouveau 08 Oct 2018
Blocked by Authentic 2 - Development #32954: afficher les champs civilité verrouillés Solution déployée 09 May 2019

History

#1 Updated by Marie Kuntz 4 months ago

#2 Updated by Benjamin Dauvergne 4 months ago

  • Project changed from Plugin FS FranceConnect to Hobo

C'est parce qu'on ne récupère pas la civilité par défaut, donc on ne la verrouille pas, c'est un ticket pour hobo.

#3 Updated by Benjamin Dauvergne 4 months ago

  • Assignee set to Benjamin Dauvergne

#4 Updated by Benjamin Dauvergne 4 months ago

Pour les déploiements existant ne passant pas par hobo il faut mettre ce bout de config à la main dans le settings.json (ou refaire la config via hobo, peut-être plus simple):

{
    "A2_FC_USER_INFO_MAPPINGS": {
        "last_name": {
            "ref": "family_name",
            "verified": true
        },
        "first_name": {
            "ref": "given_name",
            "verified": true
        },
        "title": {
            "ref": "gender",
            "translation": "simple",
            "translation_simple": {
                "male": "Monsieur",
                "female": "Madame" 
            },
            "verified": true
        },
        "email": "email" 
    }
}

#6 Updated by Benjamin Dauvergne 4 months ago

Benjamin Dauvergne a écrit :

Pour les déploiements existant ne passant pas par hobo il faut mettre ce bout de config à la main dans le settings.json (ou refaire la config via hobo, peut-être plus simple):

[...]

Configuration testé sur http://connexion-malakoff.test.entrouvert.org/accounts/, elle fonctionne mais l'affichage n'est pas verrouillé car l'attribut readonly sur les boutons radio ne fonctionne pas (je pensais qu'on avait corrigé cela).

#7 Updated by Benjamin Dauvergne 4 months ago

#8 Updated by Benjamin Dauvergne 4 months ago

Fini le boulot de partager login() et admin_user(), j'ai eu la tentation de corriger le style des tests qui n'utilisent pas la fixture app mais je me suis retenu.

#11 Updated by Benjamin Dauvergne 3 months ago

Je sollicite une relecture par une personne avec moins de cheveux.

#12 Updated by Paul Marillonnet 3 months ago

(J'en remets une couche avant d'aller chez le coiffeur.)
Puisque la provenance de FC n'atteste pas de la véracité des attributs, je ne comprends pas l'utilité du verrouillage (en plus de donner l'impression à l'usager qu'il n'est plus maître de ses infos personnelles).
La seule validation qui peut y avoir ici n'est pas une validation de véracité des infos de l'usager, mais plutôt une validation de leur provenance.
Je pense qu'il y a d'autres pistes (genre des attributs de profil 'fc_first_name', 'fc_last_name', 'fc_gender', avec un peu de code pour les substituer aux attributs de base lorsque ces derniers ne sont pas définis), plus intéressantes et plus respectueuses de l'usager que le verrouillage jusqu'à ce que mort s'en suive.

#13 Updated by Benjamin Dauvergne 3 months ago

On verrouille déjà first_name et last_name et on ne va pas le défaire.

#14 Updated by Mikaël Ates 2 months ago

FC atteste de la véracité pour l'identité pivot (Il faut repointer ici le point fait sur la validité de l'identité validée servie par FC : décrets, réponses support FC, etc.). Je pense que la réserve sur la qualité des données portent plutôt sur des sources comme API Entreprise ou API Association.

Pour ce qui est de la demande en elle-même et le besoin de mise en oeuvre, revoir le fil de discussion DINSIC/EO : "Modification des données d'identité non possible dans Publik".

#16 Updated by Marie Kuntz 2 months ago

Pour l'instant, comme on ne récupère pas le sexe sur FC, FC n'exige pas qu'on verrouille la civilité. Mais si on le récupère, il faut verrouiller.
Sur le sujet de maîtriser ses infos personnelles, c'est le cas puisqu'on maîtrise sur le compte qui a servi à la connexion (impots, caf...).

Puisque la provenance de FC n'atteste pas de la véracité des attributs, je ne comprends pas l'utilité du verrouillage

il ne s'agit pas de véracité mais de synchronisation : les infos doivent être les mêmes sur FC et sur Publik.

#17 Updated by Benjamin Dauvergne 2 months ago

Marie Kuntz a écrit :

Pour l'instant, comme on ne récupère pas le sexe sur FC, FC n'exige pas qu'on verrouille la civilité. Mais si on le récupère, il faut verrouiller.
Sur le sujet de maîtriser ses infos personnelles, c'est le cas puisqu'on maîtrise sur le compte qui a servi à la connexion (impots, caf...).

Les gens ont un droit de rectification sur notre système, on ne peut pas se défausser en disant appeler la CAF/les impôts; pour l'instant on ignore car ça n'est juste jamais arrivé.

Puisque la provenance de FC n'atteste pas de la véracité des attributs, je ne comprends pas l'utilité du verrouillage

il ne s'agit pas de véracité mais de synchronisation : les infos doivent être les mêmes sur FC et sur Publik.

Non il a raison si on pas la certitude que les informations qu'on provisionne sont "sûres" on doit toujours laisser un moyen de débrayer et de permettre à l'utilisateur de corriger ou de faire corriger; mais avec FC ces cas sont faibles; et de toute façon le RGPD nous oblige à avoir une procédure de rectification, normalement, même si les données viennent d'ailleurs.

Ces histoires de synchronisation c'est le diktat de la DINSIC mais rien ne nous y oblige, on pourrait très bien suivre la voie d'avoir un double profil, celui de Publik et celui de la connexion FC quand elle est active (si on se connecte avec son mot de passe sur un compte relié à FC, on ne bénéficierait pas du profil Publik); en demandant par ailleurs aux gens et donc avec leur consentement express s'ils veulent synchroniser certains partie de leur profil Publik avec le profil FC. Pour l'instant c'est de la science-fiction nous ne sommes pas parti sur ce chemin.

Also available in: Atom PDF