Non. Il n’y a pas besoin d’avoir un compte sur JPMA pour ça. L’attestation d’âge transmise par le vérificateur d’identité n’est pas conservée par JPMA sur son serveur, elle est conservée sur le téléphone de l’utilisateur.
Quand tu es FAI (" obligent les opérateurs de communications électroniques à conserver les données de connexion de leurs utilisateurs") . Pas un service disponible via Internet, qui n’est pas un opérateur (dans les textes de lois, ils sont qualifiés d’« éditeur de service » en général). Un service Internet par défaut ne doit PAS stocker les IP (il y a une tolérance pour les logs techniques, et uniquement pour ça).
Pure spéculation de ta part parce que tu as décidé depuis le début que Docaposte sont des grands méchants menteurs qui veulent fliquer les gens qui vont sur des sites pornos.
Quel intérêt ce token a à la vente ? Aucun. Un autre site ne peut l’utiliser pour rien, il n’a aucune valeur ce token, tout ce qu’il dit c’est que l’utilisateur pour lequel SitePorno avait généré l’id Random A a plus de 18 ans. Aucune information personnelle. Et quand Bob va aller sur JeuxDArgent, même si JeuxDArgent a en sa possession ce token, il n’a aucun moyen de l’associer à Bob… Sauf par des moyens qui n’ont rien à voir avec le token et avec JPMA, moyens qui peuvent déjà être mis en œuvre aujourd’hui sans. Acheter ce token n’apporte strictement rien.
En navigation privée, le token saute aussi après chaque visite, ça ne change rien… Tous les moyens de stocker des informations dans le navigateur sautent.
Si, c’est bien ce que tu disais au début :
Alors oui, par contre JPMA sait que telle IP va sur SitePorno (et non, comme je le décris, Identité Numérique ne le sait pas, il sait juste que l’utilisateur est allé sur un site faisant un contrôle d’âge, ce qui ne dit pas forcément que c’est un site porno et encore moins lequel… cela dit, ma description ne semble pas correspondre tout a fait au fonctionnement de JPMA, où le lien avec le service d’identité n’est pas synchrone, le service fournit un certificat conservé dans le téléphone de l’utilisateur, donc il n’y a pas une requête vers ce service à chaque accès à un site demandant une vérification d’âge, après la première utilisation et pendant un an, c’est le téléphone de l’utilisateur qui devient le fournisseur d’identité).
Mais ça tu peux pas faire autrement sans permettre un trafic de jetons si ça marche en étant totalement déconnecté : c’est le fait d’être connecté qui permet de fonctionner avec des jetons jetables ayant une très courte durée de vie (pas besoin de plus de quelques secondes)… Et à partir du moment où JPMA n’enregistre pas ces IP, il n’y a pas de problème particulier. Or il n’a aucune obligation de les enregistrer.
En fait, sauf à accuser JPMA de mentir ou de ne pas respecter la loi, on peut même affirmer que JPMA n’enregistre PAS ces données. Parce que la législation française impose d’indiquer à l’utilisateur quand son adresse IP est enregistrée, et la politique de confidentialité de JPMA ne mentionne aucune collecte d’adresse IP.
Reste au final un truc à vérifier, c’est si, après le scan de QR et la validation par l’utilisateur de l’autorisation de partage, JPMA notifie SitePorno en back, comme tu le supposes, ou en front, comme je le suppose.
En gros, on a deux possibilité pour cette étape :
smartphone → back JPMA → front JPMA → front SitePorno
smartphone → back JPMA → back SitePorno → front SitePorno
(EDIT : après réflexion, la seconde ne me parait pas possible, ça doit forcément passer par le front JPMA : quand il scanne le QR, l’utilisateur a le front JPMA sur son navigateur, plus le front SitePorno, donc pour que la redirection vers SitePorno se déclenche, il faut forcément que front JPMA soit notifié du succès du scan… on pourrait envisager la 2ème solution avec une double notification par back JPMA à la fois vers front JPMA et back SitePorno, mais ça aurait peut d’intérêt, puisqu’à partir du moment où front JPMA redirige vers front SitePorno, la notification peut passer par là…)
Dans le premier cas, ça peut se faire sans même que le back JPMA ne stocke l’URL de callback (il la voit forcément passer dans la requête GET ou POST initiale, mais peut tout a fait ne pas la stocker, puisque c’est uniquement le front qui en a besoin, une fois que le back l’a notifié que c’est OK), dans le second cas ça implique un stockage temporaire de l’URL de callback côté back JPMA (mais toujours pas besoin de l’associer à une IP dans une bdd).
Pour vérifier ce point, j’ai essayé de trouver une liste des sites partenaires de JPMA, mais je n’en ai pas trouvé ^^
