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

## 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
2. 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.