Tension
Avec la nouvelle connexion par POD, le profil se trouve sur le POD. Mais par défaut, il est privé.
Proposition
Proposition faite après réflexion avec @simonLouvet
Après la connexion, regarder si l'utilisateur a un profil attaché au COD (recherche des profiles avec le webId dans "as:describes")
Si oui, utiliser ce profil pour le menu utilisateur (Voir / éditer mon profil).
Si non, afficher un écran qui lui permet de choisir un profil à ajouter sur le COD:
Si un profil public existe, il peut le sélectionner directement
Si un profil privé existe, il peut le rendre public
Il peut aussi créer un nouveau profil, à partir d'un profil existant (fork) ou à partir de rien.
Il peut choisir si créer le profil sur le COD ou sur son POD. L'avantage de créer sur son POD est que le profil peut être réutilisé sur d'autres applications. Dans ce cas l'URI du profil est ajouté (PATCH) au container.
Il peut aussi ne pas se créer de profil. Dans ce cas, il peut naviguer sur le site, profiter des droits WebACL, etc, mais personne ne saura qu'il s'est connecté.
S'il crée un nouveau profil, celui-ci est indiqué dans le prédicat "as:url" de son webId. Il peut donc y en avoir plusieurs et il faudra adapter le code ActivtiyPods pour prendre en compte cette possibilité.
Les relations sont ajoutées à son profil et non à son webId. Cela permet de respecter les règles RGDP, car est considéré comme données personnelles tout ce qui peut potentiellement identifier une personne.
Si le profil du POD est supprimé, il sera aussi détaché du COD par le mécanisme du mirroir (fetch toutes les heures). Cela garantit un fonctionnement optimal RGDP. Il faut veiller à supprimer les relations inverses.
Il faut prévoir un fix pour que les relations inverses soient générées car ce n'est pas le cas pour le moment.
Tension Avec la nouvelle connexion par POD, le profil se trouve sur le POD. Mais par défaut, il est privé.
Proposition Proposition faite après réflexion avec @simonLouvet
Après la connexion, regarder si l'utilisateur a un profil attaché au COD (recherche des profiles avec le webId dans "as:describes")
Si oui, utiliser ce profil pour le menu utilisateur (Voir / éditer mon profil).
Si non, afficher un écran qui lui permet de choisir un profil à ajouter sur le COD:
Il peut aussi créer un nouveau profil, à partir d'un profil existant (fork) ou à partir de rien. Il peut choisir si créer le profil sur le COD ou sur son POD. L'avantage de créer sur son POD est que le profil peut être réutilisé sur d'autres applications. Dans ce cas l'URI du profil est ajouté (PATCH) au container.
Il peut aussi ne pas se créer de profil. Dans ce cas, il peut naviguer sur le site, profiter des droits WebACL, etc, mais personne ne saura qu'il s'est connecté.
S'il crée un nouveau profil, celui-ci est indiqué dans le prédicat "as:url" de son webId. Il peut donc y en avoir plusieurs et il faudra adapter le code ActivtiyPods pour prendre en compte cette possibilité.
Les relations sont ajoutées à son profil et non à son webId. Cela permet de respecter les règles RGDP, car est considéré comme données personnelles tout ce qui peut potentiellement identifier une personne.
Si le profil du POD est supprimé, il sera aussi détaché du COD par le mécanisme du mirroir (fetch toutes les heures). Cela garantit un fonctionnement optimal RGDP. Il faut veiller à supprimer les relations inverses.
Il faut prévoir un fix pour que les relations inverses soient générées car ce n'est pas le cas pour le moment.