support for unregistered Relying Party (uRP)

[pileum-eu]

Changements apportés

Ce PR implémente un concept simple de unregistered Relying Parties (uRP).

Cette fonctionnalité permet à des Relying Parties non préalablement enregistrées d’utiliser FranceConnect pour vérifier que leurs utilisateurs sont des personnes physiques et distinctes.

Le scope OpenID est limité à l'identifiant technique (sub), donc aucune donnée personnelle ne peut être transmise. De plus, le sub est Pairwise Pseudonymous Identifier (PPID), ce qui empêche les corrélations parmi les uRP.

Comme cette implémentation est compatible avec les spécifications OpenID Connect, elle ne requiert aucun changement dans l'implémentation des Relying Parties.

Justification

Cette fonctionnalité permet à des applications tierces de se protéger contre les attaques Sybil. En sécurité informatique, l’attaque Sybil correspond à la création de multiples faux comptes par une même personne. Par exemple, sur un réseau social, un utilisateur qui crée plusieurs profils fictifs. C'est une attaque simple à mettre en œuvre sur Internet, mais pourtant compliquée à parer (un même attaquant peut utiliser plusieurs comptes emails, plusieurs numéros de téléphone, plusieurs adresses IP). Afin de se protéger contre cette attaque, certaines applications ont recours à des pratiques intrusives telles que demander aux utilisateurs de fournir une pièce d'identité ou un numéro de carte bancaire. Néanmoins, ce type de vérification n’est pas efficace contre les attaques Sybil (un même utilisateur peut utiliser plusieurs numéros de carte bancaire), et met en péril la confidentialité des données personnelles des utilisateurs.

Cette fonctionnalité est une solution alternative à la fois plus robuste face aux attaques Sybil, et sans utiliser les données personnelles des utilisateurs.

Voici des exemples d'applications tierces qui peuvent bénéficier du support uRP :

• Réseau social : lutte contre le spam, les bots, et le harcèlement (actions généralement commises au travers de faux profils)
• Site de vote en ligne : garantir 1 vote par personne (par exemple dans l’application Agora)
• Jeux vidéo : distribution équitable d'objets virtuels (par exemple 1 par personne)
• Service en ligne : offres d'essai limitées par personne

Détails techniques

Comme les uRP ne sont pas connus à l'avance du provider (FranceConnect), cela induit plusieurs contraintes :

• Le mode implicit flow est utilisé car il ne requiert pas de secret client_secret partagé entre uRP et provider.
• Les uRP partagent un même client_id constant.
• Les uRP fournissent l’adresse de callback de leur choix.
• Le sub est dérivé, entre autres, de l'adresse de callback du uRP afin de garantir que le sub est un PPID (spécifique à chaque couple utilisateur-uRP).

[sherman-dinum]

Bonjour,

Merci pour votre contribution et pour la qualité de la PR.

Bien que l'utilité ne soit pas à démontrer, aujourd'hui nos contraintes ne permettent malheureusement pas d'implémenter cette fonctionnalité car FranceConnect ne peut pas accepter n'importe quel RP. Nous devons vérifier précisément à ce jour qui est enrolé au près de l'appli: https://franceconnect.gouv.fr/partenaires et ici: https://github.com/france-connect/Documentation-FranceConnect-Plus/blob/main/fs/docs-fs.md.

Nous avons déjà à l'heure actuel fait un pas dans le sens d'une telle fonctionnalité en implémentant un mode "anonyme" qui ne certifie que l'unicité de l'utilisateur. Les Services ayant accès à ce mode doivent cependant toujours répondre aux critères cités plus haut. Il est possible que cette réglementation évolue un jour mais ce n'est pas encore prévu. Si c'est le cas nous implémenterons probablement de tels méchanismes.

Encore merci pour votre contribution.