Permettre à l'utilisateur de participer sans être authentifié

[srosset81]

Problème

L'authentification est souvent un obstacle important à l'usage des outils. Les personnes n'aiment pas s'enregistrer, car cela prend du temps, est source d'erreurs et cela signifie souvent de la collecte de données, notamment d'emails permettant d'envoyer ensuite des messages non-désirés.

Proposer divers types de SSO allège le processus d'authentification, mais il ne résoud pas le problème de fond pour l'utilisateur: pourquoi l'oblige-t-on à s'identifier pour participer ?

Pour les GAFAM, la réponse à cette question est simple: plus on arrive à suivre le parcours d'un utilisateur et à récolter ses données de manière centralisée, plus cela aura de la valeur en termes publicitaires. Ainsi la page d'accueil de Facebook n'est rien d'autre qu'un formulaire qui nous oblige à fournir notre adresse email. (Et Facebook a dès le début insisté pour avoir les vrais prénoms et noms de famille des utilisateurs, toujours dans le but de mieux nous identifier, alors qu'à cette époque les gens étaient plutôt habitués à utiliser des pseudonymes.)

Mais pour nous ce problème ne se pose pas. On peut imaginer de revenir à l'Internet des débuts, avec ses utilisateurs anonymes, cachés sous de multiples identités. D'ailleurs Mobilizon, développé en ce moment par Framasoft, aura la particularité d'offrir la possibilité d'avoir plusieurs identités: une professionnelle, une familiale, une militante...

L'anonymat fait quant à lui partie de la philosophie des wikis depuis ses débuts, de Wikipedia à YesWiki: permettre à n'importe qui d'éditer une ressource. Cela peut parfois créer des enjeux en terme de modération, mais l'exemple de Wikipédia montre que c'est possible.

Solution envisagée

Après réflexion avec Gabriel, nous souhaiterions proposer la possibilité de créer des identités éphémères, notamment pour ActivityPub mais peut-être aussi pour WebID On aurait alors une différence plus nette entre identification et authentification, tel que décrite ici:

L'identification est une phase qui consiste à établir l'identité de l'utilisateur. Elle permet répondre à la question : "Qui êtes vous ?". L'utilisateur utilise un identifiant (que l'on nomme "Compte d'accès", "Nom d'utilisateur" ou "Login" en anglais) qui l'identifie et qui lui est attribué individuellement. Cet identifiant est unique.

L'authentification est une phase qui permet à l'utilisateur d'apporter la preuve de son identité. Elle intervient après la phase dite d'identification. Elle permet de répondre à la question : "Êtes-vous réellement cette personne ?". L'utilisateur utilise un authentifiant ou "code secret" que lui seul connait.

https://ssi.ac-strasbourg.fr/bonnes-pratiques/recommandations/lidentification-et-lauthentification/

Voilà un peu le scénario imaginé:

• L'utilisateur arrive sur SemApps, il n'est pas connecté.
• Le frontend lui attribue un nom aléatoire, par exemple un nom d'animal et une couleur. L'utilisateur est maintenant "Giraffe bleue". Son nom est affiché dans la barre de navigation et enregistré dans un cookie.
• L'utilisateur initie une première action: suivre un acteur, poster un commentaire, éditer une ressource.
• SemApps détecte que l'utilisateur n'est pas connecté. Il ne le bloque pas mais crée une identité éphémère (WebID + acteur ActivityPub), avec le nom aléatoire fourni par le frontend.
• Un token est retourné par le backend et enregistré dans le navigateur. L'utilisateur est alors identifié en tant que "Giraffe bleue".
• L'utilisateur peut continuer d'agir en tant que "Giraffe bleue", poster des messages, accéder même à son fil personnalisé. Il peut recevoir des notifications push s'il est sur smartphone.

Plusieurs possibilités s'ouvrent à lui:

• Si à un moment il veut "péréniser" son identité, il a la possibilité de s'authentifier. Il se connecte alors à un SSO et son profil WebID/ActivityPub de "Giraffe bleue" est associée à celui du SSO. Une fois authentifié, il peut changer son nom, mettre une photo de profil, etc.
• Il peut aussi décider de garder son identité éphémère. Dans ce cas, s'il veut éviter de perdre ses données en vidant son cache navigateur ou en changeant d'ordinateur, il peut simplement copier le token JWT quelque part pour pouvoir le réutiliser plus tard. (On est alors sur un mode de fonctionnement proche de Bitcoin, où un token suffit pour accéder à son argent.)
• Il peut aussi décider de se déconnecter, et du coup de perdre son identité, peut-être pour reprendre une nouvelle identité éphémère. Au moment de la déconnexion, on lui donne la possibilité de copier le token JWT.

Techniquement tout cela me semble parfaitement faisable, mais je serai intéressé d'avoir les retours des autres développeurs.

Résumé

Pour aller dans le sens d'une identité plus allégée, on aurait donc:

1. Permettre à l'utilisateur de participer sans être authentifié ("identités éphémères")
2. Faciliter la gestion d'identités multiples
3. Ne pas mettre en avant le vrai prénom et nom de famille

Ces trois points pourraaient faire l'objet d'issues séparées si nous sommes d'accord sur le concept.

Notes

• Au moment de l'autentification SSO, si le système détecte que l'utilisateur a déjà une identité associé à son compte SSO, l'utilisateur peut soit l'ajouter, soit la remplacer. Cela peut permettre de gérer plusieurs identités, comme Mobilizon.
• Certaines actions pourraient être interdites aux identités éphémères. Un porteur d'action pourrait par exemple refuser de recevoir des commentaires d'identitiés éphémères. Il faudra trouver un moyen d'identifier ces identités éphémères.

[srosset81]

Et une réflexion intéressante autour de ces questions : https://www.looic.com/2005/10/connaissez-vous-la-difference-entre-identification-et-authentification/

[bouviermullerp]

Je ne connaissais pas la différence entre les 2 concepts ident et auth. Ca me parait hyyyper intéressant et avec beaucoup de valeur ajouté. En terme de priorité, ça serait intéressant de connaitre la position de notre communauté pour déterminer à quel point c'est un besoin essentiel ou non pour eux. Pour les cdlt par exemple, nous n'aurons pas ce besoin expressement

[simonLouvet]

Techniquement ca me parait faisable également. J'ai par contre plus de doute sur l’utilité pour le projet. Il me parait par exemple plus important pour le projet de mettre en place les droits ACL, démontrer les bases de données distribuées, démontrer l’interopérabilité avec startin'blox, les web component Solid, GoGoCarto, Mnemotix....

[srosset81]

Idée après discussion avec @simonLouvet:

• La génération du nom (et de l'image) est faite du côté du frontend
• A la première action qui requiert d'être identifié, on propose à l'utilisateur:
  • Soit de créer une identité éphémère (éventuellement en fournissant un username, qui sera repris comme slug)
  • Soit de se connecter via un SSO
• Si on ne veut pas imposer cette étape supplémentaire à l'utilisateur, on peut créer une identité éphémère en arrière-plan. Dès qu'on l'a reçue, on appelle à nouveau l'endpoint avec le token JWT.

Techniquement

• On ajoute un endpoint POST /identity qui crée une nouvelle identité
  • Cet endpoint accepte un nom (temporaire), éventuellement une image.
    • Si aucun nom n'est fourni, il en génère un lui-même (?)
  • Il crée un WebID (et éventuellement un acteur ActivityPub)
  • Il retourne un JWT avec le webId créé
• Si on va sur GET /auth en ayant déjà une identité éphémère, l'endpoint ne crée plus un WebID mais il se contente de mettre à jour ce WebID avec les informations retournées par le SSO (email, nom, nom de famille).
• Côté backend, on peut déterminer si une identité est éphémère en regardant si une adresse email est liée au compte (?)
  • La règle serait donc qu'une identité éphémère n'a pas d'adresse email. Si elle en a une, cela signifie qu'on peut la récupérer plus tard.

Avantages

• On peut garder toujours le même token JWT, qui aura uniquement le webId en data. Ce token peut donc être copié-collé par l'utilisateur pour se reconnecter plus tard.

Problèmes pas encore réglés

Merge des comptes

• Scénario:
  • Un utilisateur s'authentifie, fait des actions, puis se déconnecte
  • Il revient sur l'app et faire des actions avec une nouvelle identité éphémère
• Problème:
  • Lorsqu'il s'authentifie à nouveau, on détecte que son adresse email est déjà associée à un compte.
• Solution:
  • Est-ce qu'on peut lui proposer de "merger" les deux comptes, sachant que certaines activités devront être répétées ?

Email comme moyen d'authentifier un utilisateur

• Scénario
  • L'utilisateur se connecte via un SSO
  • Il change d'adresse email directement sur le SSO
  • La prochaine fois qu'il veut se connecter, l'instance SemApps ne trouve aucun compte avec sa nouvelle adresse email et elle crée donc un nouveau compte
• Problème:
  • Les données de l'ancien compte sont perdues et irrécupérables, à moins de rechanger l'adresse email sur le SSO
• Solution:
  • Il serait mieux d'identifier, pour chaque SSO, un identifiant unique qui permet
  • Mais où est-ce qu'on enregistre l'ID ? Sous quel prédicat ?

[ReX-AV-Gab]

Voilà le scénario que j’imagine en tant qu’utilisateur pour la mise en œuvre de l’identité éphémère (par ex. Canard bleu) pour pouvoir participer sans être obligé de m'authentifier. Lors de la première utilisation de l’appli en question :

• apparaître en Canard bleu dès l’entrée dans l’appli ;
• pouvoir, en sortie de l’appli de préférence, faire appel - ou non - à un compte pré-existant - ou à créer - en conservant - ou non - mon historique de Canard bleu ;
• pouvoir, à la reprise de l’appli, repartir avec la dernière identité utilisée le cas échéant, soit donc celle liée au compte utilisé, soit celle, conservée, de Canard bleu qui me serait réservée pendant un certain laps de temps (40 jours ?) après sa dernière utilisation.

[srosset81]

Suite à la réunion tech avec @simonLouvet aujourd'hui, deux idées sont apparues:

• Pour la génération des noms éphémères uniques, développer un package indépendant type name-generator, permettant d'ajouter un endpoint qui retourne un nom unique.

  • Ce nom expirerait après XX jours. Le frontend serait responsable de ne plus l'utiliser avec ce laps de temps, et de demander un nouveau nom.
  • Ce nom pourrait être généré à partir d'une requête SPARQL sur wikidata, par exemple pour retourner tous les noms d'oiseaux existants.

• Pour le problème "Merge des comptes" (voir commentaire ci-dessus), on pourrait permettre simplement de gérer plusieurs identités. Dans le scénario qui pose problème, l'utilisateur aurait deux WebID liés à son compte SSO. Lorsqu'il s'authentifie, on lui demande quel identité il veut utiliser. La gestion de plusieurs identités est fondamentalement intéressante, c'est en tout cas ce que Framasoft a voulu proposer avec Mobilizon. Il faudra aussi prévoir la possibilité de supprimer une identité.