Suppression de la piscine de la WoT

cgeek · 16 December 2021 17:26

Comme l’avait évoqué @elois dans ce sujet, la migration vers Substrate est une bonne occasion de supprimer la notion de piscine concernant les documents de WoT.

Une simple recherche sur le forum vous montrera que la piscine est une plaie pour les utilisateurs, mais en plus c’est une potentielle faille de sécurité (attaque DoS). Jusque-là nous pouvions l’accepter, mais si la Ğ1 doit passer à un autre niveau il faut corriger ce point.

Publier directement en blockchain

L’idée donc, c’est que les identités, certifications et adhésions soient directement publiées en blockchain au fur et à mesure du processus d’entrée d’un nouveau membre, dès que les documents sont signés.

Prenons un exemple pour avoir l’idée générale :

Bob publie son identité, celle-ci est inscrite en blockchain mais Bob n’est pas membre pour autant
Alice certifie Bob : la certification est inscrite en blockchain mais Bob n’est toujours pas membre (il en faut 5)
Quatre autres membres certifient Bob, qui dispose alors de 5 certifications
Bob publie sa demande d’adhésion, et si la règle de distance est respectée, il devient membre

Avantages

Plus de problème de piscine désynchronisée, tout est stocké en blockchain
Moins d’incertitudes quant à la validité de l’inscription : tout est publié au fur et à mesure (exit la concurrence)
Meilleur contrôle du spam : en utilisant la WoT, possibilité d’avoir des quotas et des frais.

Reste le cas de l’identité

Autant il est possible d’appliquer des quotas et frais pour un membre, autant pour un nouvel entrant c’est plus compliqué : il est facile de créer une identité sur une clé et de répéter l’opération pour spammer la blockchain. C’est même pire que dans Duniter v1.

La solution que voyais Eloïs, c’était de reprendre la mécanique de Duniter v1 qui intégrait l’identité via la certification (qui la contient). Comme la certification est réservée aux membres et se trouve bien cadrée par des quotas, c’est une bonne protection.

Oui mais voilà, comment fait le nouvel entrant pour publier son identité afin qu’un membre puisse le certifier, afin que justement l’identité soit publiée ?

Plusieurs solutions peuvent être imaginées, par exemple le nouvel entrant pourrait se débrouiller pour transmettre son identité par un canal externe (e-mail, QRCode, etc).

Je serai plutôt partisan d’une solution on-chain, qui consisterait à ajouter une nouvelle action aux membres : pouvoir inviter à la création d’identité. Concrètement, chaque membre pourrait inscrire en blockchain un droit d’écriture d’identité sur une clé publique (compte) qui n’en dispose pas encore, et autoriserait un non-membre à y publier son identité.

Ensuite bien sûr on déroule le processus normal d’inscription : certifications et adhésion.

De cette façon il est facile de conserver des quotas, tout en permettant l’inscription progressive en blockchain.

Si jamais vous avez d’autres idées, n’hésitez pas à les partager ci-après.

Pini · 16 December 2021 18:26

C’est vraiment pas bête comme idée, et élégant. Je plussoie.

poka · 17 December 2021 03:17

Ça ferait donc un quota d’invitation + le quota de certification.
Je trouve que ça alourdi l’UX.

On ne pourrait garder les mêmes quotas de certification et d’invitation, en considérant que si Bob invite Alice, et que Alice publie son identité en retour, alors l’invitation de Bob devient automatiquement sa première certification.

L’invitation émise même sans émission d’identité en retour serait compté au quota des certifications.
On pourrait définir un délais d’expiration plus court que les certifications, par exemple 5 jours pour que la personne publie son identité, sans quoi l’invitation est annulé et je récupère mon quota de certification.

Le premier certificateur serai alors considéré comme le parrain en terme d’UX par exemple.

Dit autrement un membre peut certifier n’importe quel portefeuille, mais ce dernier a 5 jours (par exemple) pour publier son document d’identité en retour pour que la certification soit valide.

Côté UX le client peut très bien afficher un bouton invitation au lieu de certification si le compte n’a pas encore d’identité.

C’est un peu un mix de vos deux propositions.
Je ne sais pas si c’est pertinent, il ne faut pas non plus que ça complexifie l’implémentation pour rien.

cgeek · 17 December 2021 10:30

En fait, on peut même directement dire qu’il s’agit d’une certification, sans distinction je m’explique.

Autant dans Duniter v1 la certification porte sur une identité, composée d’un UserID, blockstamp et d’une signature, autant pour Duniter v2 je pense que cette lourdeur peut être abandonnée.

En effet à partir du moment où l’on écrit directement en blockchain, certifier une clé publique suffit puisqu’il n’y a aucun risque de collision d’une part (on est on-chain, les contrôles sont supposés fiables), et il n’y a pas non plus de risque pour la WoT puisque tant que le certifié n’est pas membre il ne peut pas lui-même certifier ni donc intervenir dans la distance des autres.

De plus il n’y a aucun risque de vol de compte, la clé publique étant supposée être un élément discriminant et contrôlée exclusivement par son propriétaire, le membre en devenir.

Bref je ne vois pas de contre-indication à permettre la certification de comptes, sans même qu’une identité n’y soit encore rattachée.

edit : par contre en terme d’UX, effectivement il peut être intéressant de prévenir le certifieur qu’il agit sur un compte pour lequel l’identité n’existe pas encore et donc l’inviter à prendre ses précautions (bien vérifier la clé notamment).

edit 2 : en conséquence, créer une identité revient surtout à associer un pseudo. Et aussi, pas besoin que celle-ci soit publiée pour autoriser les certifications 2, 3, 4 et plus. Du moment que la clé publique est connue, les certifications peuvent être réalisées. L’apothéose intervient quand le certifié prend le contrôle de son compte en publiant son identité + adhésion.

poka · 17 December 2021 11:29

Cela signifie qu’un compte peut devenir membre sans avoir déclaré d’identité si je comprends bien ?

Déclarer son identité (renseigner son pseudo en somme) ne sert donc plus à grand chose, si ce n’est facilité la reconnaissance du compte, simplifier sa recherche dans l’annuaire.

On pourrait donc certifier des clés publiques n’appartenant à personne, ce qui n’est pas le cas aujourd’hui.
Je reste sceptique quant à la possibilité de devenir membre sans avoir déclaré d’identité.

On pourrait aussi autoriser les certifications 2, 3, 4 et plus sur une clé publique sans identité, mais attendre la publication de l’identité (+ adhésion si le quota est rempli et que la règle de distance est effectué) pour valider ces certifications (ne devient membre qu’un compte ayant publié son identité).

Si on ne fait pas ça, un groupe de pote pourrait par exemple décider de certifier le compte du bar dans lequel ils se trouves, sans même que le propriétaire de ce compte ne l’ai voulu.

Ce n’est pas conforme à la licence certe, mais aujourd’hui, sans parler respect ou non de la licence, la seule fraude possible est de certifier quelqu’un qu’on ne connait pas assez bien voir pas du tout.
Si on autorise la certification de compte sans identité associé, on ouvre alors le champ des possibles niveau fraude.

Mon avis n’est pas tranché, d’un côté ça simplifie pas mal l’implémentation, mais rends optionnel le document d’identité.
De l’autre ça sécurise un peu la WoT je trouve, ça responsabilise les futures membres à devoir se déclarer pour le devenir. On ne peut pas certifier n’importe quoi.

Ou alors je n’ai pas compris ce que tu proposes, car il faut bien que le propriétaire du compte publie son document d’adhésion pour devenir membre dans tous les cas ?

cgeek · 17 December 2021 12:08

Non, non ! Simplement que les certifications ne requièrent pas identité ni adhésion pour être réalisées.

Il faut bien entendu identité + adhésion pour passer au statut de membre.

Oui, le seul intérêt est humain.

poka · 17 December 2021 12:24

D’accords donc si je reformule:

Un portefeuille n’ayant reçu aucune certification ne peut pas émettre de document d’identité.
Une certification suffit pour lui ouvrir le droit de publier son identité.
N’importe quel portefeuille peut se faire certifier, autant qu’il veut.
Il ne devient membre que lorsqu’il publie ses documents d’identité + d’adhésion, et que bien sûr qu’il ai reçu le nombre de certification nécessaire et que la règle de distance est respecté.

C’est bien ça ?

cgeek · 17 December 2021 12:50

Yes

Maaltir · 17 December 2021 13:30

Alors je me demande s’il serait possible d’avoir une notion d’identité non creatrice de monnaie.
Quand je veux donner des Junes à une asso ou une entreprise, je vais la chercher par son nom.
Ce serait bien que ce nom, soit en quelque-sorte « certifiée ». Je serais un peu plus sur de donner au bon endroit, qu’il n’y a pas eu usurpation.
Un genre de je certifie que c’est bien un non-humain.

C’est peut-être un truc à imaginer pour plus tard…
Je ne sais pas si cela peut intéresser beaucoup de gens.
Mais si ça peut orienter la réflexion sur le sujet de l’identification, je préfère en parler maintenant.

cgeek · 17 December 2021 13:40

C’est à réfléchir, la contrainte principale étant que tout ce qui s’exécute on-chain doit voir son intérêt soupesé car les ressources sont limitées.

tuxmain · 17 December 2021 15:42

Comme ces certifications n’auraient aucune incidence sur le DU, la TdC ou la gouvernance, je ne vois pas l’intérêt qu’elles soient en blockchain. Ça pourrait faire partie des modules utilisant le stockage offchain des nœuds.

Pini · 17 December 2021 16:15

Au risque de dire une bêtise, ne serait-il pas plus simple, à la création d’un portefeuille, d’y associer un identifiant qui correspondrait à l’identité ?
Edit - Si un user veut que le portefeuille soit anonyme, il ne saisit rien.

vit · 17 December 2021 18:22

Elois avait aussi parlé de supprimer le pseudo en blockchain car c’est une donnée personnel (RGPD, droit à l’oubli, tout ça, tout ça…).

Il me semble que le sujet de supprimer le pseudo et/ou carrément le document d’identité sont des problématiques liées au sujet qu’entraîne la suppression des piscines… Car si on trouve une solution alternative qui s’appuie sur le pseudo ou l’identité, elle peut être remise en question…

@cgeek, as-tu ce sujet (suppression pseudo et/ou identité) dans la liste des spécifications ? En as-tu parlé avec Elois ?

tuxmain · 17 December 2021 19:33

Un identifiant texte, genre pseudo, ou un identifiant technique (hash, numéro…) ?

Si on stocke cet identifiant en blockchain, alors il faut au moins une réserve de monnaie et une taxe à chaque changement pour limiter le spam.

Et si on met un champ, les gens vont le remplir. Aujourd’hui, on dit aux gens qu’ils peuvent utiliser des pseudos et ne pas mettre de nom dans Cesium+, mais rien que le placeholder “Nom, Prénom” fait que tout le monde met son vrai nom.

Et tous les arguments contre le champ username s’appliquent.

Pini · 17 December 2021 20:16

Oui. Identifiant qui représente l’identité. Par exemple, pour moi ‘Pini’.

Pas besoin. On le déclare immutable, comme les autres paramètres du portefeuille. Tu veux changer d’identité ? Crée-toi un nouveau compte.

Un texte explicatif sur les IHM concernées ne me semble pas hors de portée.

Ça ne me parle pas.

cgeek · 18 December 2021 14:51

C’est hors-sujet. La Ğ1 ne s’inscrit pas dans un État, encore moins dans ses lois.

Cela ne me dit rien.

Le problème n’est pas la modification, mais déjà la création : si créer un compte portefeuille ne coûte rien (et c’est le cas), alors créer des “identités non-membre” l’est tout autant d’après la définition que tu en donnes Pini. C’est donc une faille aboutissant en attaque DoS, c’est pour cela que @tuxmain parle de requérir une taxe pour limiter l’attaque.

elois · 11 January 2022 00:44

9 messages ont été scindés en un nouveau sujet : Supression du UserID?

cgeek · 21 December 2021 11:52

Par contre, je ne sais pas encore quoi faire concernant les fenêtres de péremption des documents :

idtyWindow : 2 mois
sigWindow : 2 mois
msWindow : 2 mois

Ces valeurs étaient présentes pour se prémunir de spam sur les piscines, je me demande s’il ne faudrait pas en conserver certaines même sans piscine.

Par exemple pour éviter que les pseudo ne soient « pillés » par des attaquants (qui certifieraient une clé qu’ils maîtrisent et y publient une identité - pas de quoi devenir membre mais juste réserver le pseudo sans limite de temps), et vu le stock de certifications (100 max) ça peut être un peu gênant.

Bon, là on est un peu dans de l’optimisation, qu’en pensez-vous ?

HugoTrentesaux · 21 December 2021 15:21

TL;DR

Restons minimaux et fonctionnels on-chain, appliquons des limites anti-spam strictes, facilitons l’ajout de fonctionnalités off-chain et travaillons sur les clients.

Je ne comprends pas tellement l’objet de la discussion sur la publication d’identité. Voici la manière dont je comprends les choses :

n’importe quelle personne peut générer une paire de clé cryptographiques lui permettant de chiffrer / signer des documents, et peut stocker ces clés comme elle le souhaite pour utilisation ultérieure sur une autre machine
un compte devient membre s’il remplit les conditions suivantes :
- il existe un document signé par disant que représente une personne physique unique qui souhaite que le compte A devienne membre (ça correspond aujourd’hui au document d’adhésion)
- il existe cinq documents signés par , , , , déjà membres disant qu’ils connaissent une personne physique capable de signer avec , et qu’ils pensent que cette personne respecte la licence (elle est seule à avoir accès à cette clé, elle ne va pas tenter de créer d’autres clés membres…)
- d’autres conditions sur les propriétés du graphe (distance aux “référents”…)
- d’autres conditions sur les dates des documents (intervalle de validation de certification, durée de certification, durée d’adhésion)

D’autre part, la blockchain principale et le seul moyen d’obtenir le consensus sur le réseau, c’est une ressource précieuse sur laquelle on ne veut stocker que le strict minimum, tout le reste doit passer par d’autres canaux (messages off-chain, stockage off-chain). On ne fait confiance qu’à des membres de la wot pour écrire dedans, et on impose des règles d’acceptation des blocs pour tenter d’écrire le strict minimum.

il existe un nombre “limité” d’identités membres (par exemple < 1 million)
- on peut donc appliquer des restrictions sur la fréquence d’émission de documents
il existe un nombre “illimité” de clés valides (par exemple > 1000 milliards)
- une restriction sur la fréquence d’émission de documents n’empêche pas d’émettre un document à partir d’une autre clé, il faut donc un autre mécanisme de limite

Voilà la manière dont je perçois les usages actuels :

lorsque quelqu’un veut rejoindre la monnaie libre (il ne sait pas encore distinguer membre / portefeuille, il n’a pas encore lu la licence, mais il sait qu’il a envie de participer), il se “connecte” à Césium (traduction = il installe un client), il crée un compte (traduction = il génère un paire de ), il complète son profil (traduction = il publie des infos sur un stockage off-chain comme Cesium+). Ici rien ne doit être écrit on-chain, d’ailleurs je pense que la “création de compte membre” sur Césium (traduction = avec publication immédiate d’un document d’adhésion) est une erreur à éviter.
quand cette personne participe à des apéros monnaie libre, comprend mieux les règles, et trouve un premier certificateur potentiel, elle lui communique sa publique d’une des manières suivantes
- elle lui envoie directement par mail / sms / Qr-code césium
- elle lui dit de chercher son nom dans l’annuaire Césium+ (donc potentiellement un outil complètement off-chain) et vérifie avec lui que la clé publique correspondante correspond bien en regardant les premiers caractères (ici on peut avoir la discussion sur le format court de clé…)
à ce stade, le certificateur peut chercher à vérifier que la personne a vraiment le contrôle de cette clé, par exemple en faisant un échange d’une june. C’est une bonne idée, mais on pourrait tout à fait faire cette vérification sans passer par une transaction (écriture en blockchain). Un simple message off-chain signé ferait l’affaire.
les autres certificateurs peuvent voir les certifications reçues par la personne directement sur la blockchain

Finalement, voilà comment j’envisage le protocole blockchain pour la wot :

une clé membre a une limite “antispam” d’émission de documents (par exemple nombre de bloc minimal entre deux émissions successives, et/ou un stock dans une certaine fenêtre de blocs),
une clé ayant reçu une certification gagne le droit d’émettre au maximum deux documents : une “adhésion / création d’identité / association de pseudo (si on veut le garder)” et une “révocation”
une clé devient membre (écriture en blockchain du changement de statut) quand :
- elle a émis une “adhésion”
- elle a reçu cinq certifications
- les documents précédents vérifient leur durée de validité
- les certifications vérifient l’intervalle “antisybil” de leur émetteur

Je distingue donc le mécanisme “antispam” destiné à protéger la blockchain contre de trop nombreux documents et le mécanisme “antisybil” destiné à ralentir la progression d’une région sybil de la wot. Je ne précise volontairement pas l’algorithme qui choisit laquelle de deux identités certifiées par un même émetteur doit devenir membre en premier, puisque deux nœuds peuvent avoir des règles différentes tant que le résultat vérifie les contraintes de validation.

Section “réponse”

C’est déjà à peu près ce qui se passe aujourd’hui, on peut même ajouter “sur papier” et “à l’oral” à la liste.

C’est plutôt de savoir si on peut avoir cette info en blockchain. Qu’est-ce qui m’empêche de faire un script qui génère des clés et publie en blockchain un document leur affectant un pseudo ?

soit le prérequis d’avoir une certification sur cette clé
soit un coût en monnaie

Je suis plutôt pour l’option 1.

Plusieurs solutions, mais je les trouve toutes excessivement compliquées :

on distingue l’invitation à déclarer un pseudo de la certification, une seule invitation à déclarer un pseudo est nécessaire pour déclarer un pseudo, on ne peut certifier qu’une clé associée à un pseudo
la première certification peut se faire sans pseudo, mais les certification suivantes ne peuvent se faire qu’après publication d’un pseudo
la certification contient un champ en clair “pseudo du destinataire”, cinq certification ne peuvent être validées qui si elles ciblent le même pseudo

Je pourrais très bien concevoir un client pour le duniter actuel qui n’affiche pas le pseudo. Ce n’est pas parce que cette info est en blockchain qu’elle sera affichée par les clients.

On pourrait ajouter un outil qui incite le certifieur à écrire une note sur le certifié avec des informations comme le nom sous lequel il l’a connu, les lieux et les dates des rencontres, ce qu’il sait sur lui, des photos, des descriptions physiques… Mais :

ce n’est pas parce qu’on propose un outil que les gens vont s’en servir
ce n’est pas parce que cet outil est proposé on-chain plutôt que off-chain que les clients vont l’implémenter

Conclusion : profitons de la wot et de quotas pour éviter les frais d’action. Il y a un vrai enjeu côté client.

elois · 10 January 2022 19:55

C’est exactement ce que j’ai déjà implémenté dans ma PoC cet été, je le montre même en vidéo