Supression du UserID?

J’ai retrouvé le sujet en question :

et ce post en particulier :

OK, je n’avais pas vu passer ce post.

Pour répondre rapidement : non, en effet, l’UID n’a aucun intérêt technique. Mais il a un intérêt humain pour construire la WoT : poser un identifiant « qui parle » et qui constitue un point d’appui solide permettant de sécuriser la certification (et donc la WoT, et donc la monnaie).

C’est pour ça que je ne souhaite pas qu’il soit off-chain. Par contre, selon moi tout le reste peut l’être : nom, prénom, etc.

Autre argument mais plus faible : nous ne sommes pas à l’abri de changer de système cryptographique, dans ce cas l’UID pourra servir d’invariant.

5 « J'aime »

On sort du sujet, donc je renvoi à cette discution:

De toute façon on en est pas à réfléchir à changer le protocole, juste à l’adapter pour le rendre optimal pour Substrate il me semble.

1 « J'aime »

Le sujet est de savoir si le pseudo doit être connu des le démarrage du processus d’adhésion comme membre.

Si

  • seule la clef publique est nécessaire pour stocker la première certification (on-chain), comme le suggère @cgeek,
  • et que le pseudo peut être renseigné plus tard par le propriétaire du compte, lors de l’émission de son adhésion
    Alors cela signifie que le pseudo ne sert pas aux certifieurs, qui ne peuvent s’appuyer dessus pour vérifier que cette personne n’aura qu’un seul compte membre.
    Il leur faut donc retenir la clef publique, pour suivre ensuite l’évolution de ce compte, et non plus seulement le pseudo. Ceci me semble faciliter les fraudes, ET rendre plus complexe la vérification par les certifieurs. En gros le pseudo ne sert plus pour le contrôle (par les membres) de la WoT…

Prenons un exemple :

  • j’envoie ma clef a des membres pour qu’ils me certifient. A aucun moment ils ne connaissent le pseudo que je vais utiliser ensuite.
  • j’obtiens mes 5 certifications et décide, sans avoir besoin de leur dire, le pseudo ‹ DonaldTrump ›
  • je les recontacte quelques mois plus tard pour un paiement
  • plutôt que de redonner mon pseudo precedent, je donne celui d’un autre compte que j’ai créé de la même façon, avec 5 autres personnes : ‹ BenoitLavenier ›.

A quel moment vont ils faire le lien, que j’ai en réalité deux comptes ? Quel outil auront ils pour être aider dans leur rôle de vérificateur ?
S’ils consultent leur historique de certification, il verront Donald Trump, mais sans pouvoir dire qui leur avait fait cette demande…

Voyez vous ce que je veux dire ?

Bises

Une solution alternative, est de pouvoir certifier une clef publique associée à un pseudo.
Un peu comme le fait d’inclure systématiquement le checksum (par exemple dans le format standard des copier/coller de clefs), on pourrait avoir un format du type : <clef_publique>::

Voir mieux : un checksum après le UserID pour être certain d’avoir tout copier/collé :

<clef_publique>:::

Le pseudo n’étant nécessaire, dans ce cas, que lors de la toute premiere certification. Dans les cas suivant, même si le copier/coller est mal fait, le UI pourront le détecter et afficher le bon pseudo au certifieur avant qu’il ne valide sa certification.

1 « J'aime »

Oui ça c’est pas mal, que la certification inclut nécessairement le pseudonyme associé.

Et que lors de la publication de l’identité, toute certification qui ne respecterait pas ce pseudonyme serait alors détruite et devrait être rejouée (sans délai de rejeu, si ce n’est le délai de 5j anti-spam).

Oui :slight_smile:

Personnellement je serais favorable à une simplification :

  • Il est possible de certifier un compte porte-feuille
  • Si un compte portefeuille à 5 certifications ou plus, ce compte hérite du droit de produire le DU, de certifier, et d’écrire en blockchain (si on reste sur le couplage de ces 3 droits)

C’est tout.

Le document d’identité pour moi n’a pas besoin d’être en blockchain.
On peut très bien avoir un identifiant géré par cesium+ ou autre système externe et que la blockhain se contente de clef publique.

Les certifications ne pouvant être émise que par des comptes certifiés, les quotas peuvent s’appliquer.
La licence est la pour réguler la manière de certifier.

Ça me semble suffisant.

EDIT :
En fait, si on veux s’assurer que le titulaire du compte est vivant, effectivement un document d’identité semble utile pour l’expliciter chaque année. Ceci dit, une règle qui désactive les droits lié aux certifications pour un compte qui n’a émi aucun document depuis 1 an fait aussi l’affaire (et dès lors que le compte est actif à certifier ou émettre des transactions, c’est que le titulaire à accès à son compte, donc ça peut faire le job sans rajouter de document spécifique, mais en ajoutant une règle de gestion.

2 « J'aime »

C’est la solution que j’aimerais retenir, qui va dans le sens de la dernière proposition de kimamila.

Oui, la blockchain n’en a pas besoin. Mais comme dit plus haut, le pseudo est là pour faire le pont entre la technique et l’humain, à travers une donnée fiable (ce qui ne serait pas le cas en off-chain).

Je crains qu’en enlevant le pseudo :

  • on augmente le risque d’erreurs/fraudes (avis de @kimamila également) car celui-ci agit comme un CRC humainement très lisible (un pseudo est choisi pour être prononcé par les pairs)
  • on déshumanise le processus, car en ayant le pseudo obligatoire celui-ci se retrouve aussi dans la mémoire des utilisateurs, tandis qu’une clé publique y est très vite effacée. A y repenser, c’est peut-être ce que je crains le plus, car faut-il le rappeler : toute la Ğ1 repose sur l’humain. Ce dernier doit y être impliqué sans quoi l’effondrement n’est pas loin.

C’est le rôle du document d’adhésion, qui ne contient pas de pseudo. Et qui sert aussi de déclencheur à la vérification de la distance (calcul très coûteux). L’identité n’est pas utile pour ce cas.

4 « J'aime »

Je comprends les points positifs du pseudo, mais il a un gros point négatif :

  • c’est un champ libre comme le champ commentaire.

Il a donc les mêmes problèmes que le champ commentaire.

Il nécessite donc une validation de la donnée pour éviter des attaques par injection de code. Et aussi par des attaques sociales (mots racistes, insultes, usurpation d’identité par homonymie ou autres). C’est le côté attaque par l’humain.

Je pose ça là pour bien sécuriser ce champ.

Concernant le UserID, ce qui m’en semble essentiel c’est qu’il soit modifiable.

Partons des usages comme le fait @kimamila, on décidera dans un 2ème temps si on le stocke onchain ou offchain (ou onblock).

Concernant les usages, j’assume que:

  • Je dois voir le pseudo de la personne que je certifie.
  • Le pseudo doit être modifiable à long-terme (ça me semble acceptable qu’il ne soit pas modifiable avant la validation complète de l’identité).
  • Si le pseudo a été modifié il y a moins de X jours, je dois avoir une alerte dans l’UX, et lorsque j’appuie sur cette alerte, ça doit n’indiquer que le pseudo a changé récemment, et m’indiquer quel était l’ancien pseudo).

Concernant le choix du stockage onchain ou offchain, il y a en réalité un 3 ème choix, ou plus précisément, le terme onchain n’est pas assez précis, et peut désigner 2 réalités différentes:

Il faut dissocier le contenu des blocs d’une part, et le storage onchain d’autre part. Le storage onchain est la seule partie qui doit nécessairement être conservée par tous les nœuds du réseau, et qu’il convient de garder légère sous peine d’impact négatif sur les performances et la scalabilité.

Concernant les blocs, le seul impératif est de conserver les blocs non-finalisés, soit en moyenne 5 à 10 blocs grand maximum!

Les blocs plus anciens ne sont conservés que par les nœuds d’archive, les nœuds d’archive ne servant qu à déployer de nouveaux indexers, ou restaurer des indexers down depuis longtemps ou avec une corruption de donnée.

Les nœuds d’archive peuvent être peu nombreux, n’ont pas besoin d’écrire des blocs, et peuvent donc sans problème être réservé à des machines avec beaucoup de stockage.

Ce que je veux dire, c’est qu’entre un stockage onblock et un stockage offchain, dans les 2 cas la donnée devra être stockée quelque part sur quelques machines, donc ça ne change rien en termes de taille de stockage.

Pour stocker une donnée onblock mais pas onchain, rien de plus simple, il suffit de créer un paramètre inutilisé dans un extrinsic.

En revanche, le storage onblock reste une violation du droit à l’oubli, mais dans la pratique, même avec un storage offchain, difficile d’être sûr que toute trace est effacée, une vielle copie peut toujours persister quelque part.

Bref, tout ça pour dire que je suis ok pour que le UserID soit stocké onblock, cela permettrait de le rendre accessible par l’api graphql de Hydra par exemple :slight_smile:

Je propose donc:

  1. D’ajouter un paramètre inutilisé idty_name à l’extrinsic create_identity
  2. D’ajouter un extrinsic change_idty_name qui vérifie que l’appelant une identité validée (membre de la wot) avec paramètre idty_name également inutilisé afin de ne pas alourdir le storage.

Un système d’historisation tel que Hydra devrait alors être capable de fournir l’historique de tout les pseudos d’un membre et leur date de modification.

Il reste la question des comptes simple portefeuille, on pourrait y rattacher un « membre propriétaire », afin de pouvoir appliquer un quota.

Plus généralement, toute donnée à stocker doit être limitée soit par des quotas soit par des frais. Dans le premier cas cela implique que toute donnée soit rattachée à un propriétaire identifiable, dans le 2ème cas cela implique que l’utilisateur doit avoir suffisamment de Ğ1 pour créer ou modifier son profil.

On peut également mixer les deux: donner la possibilité de rattacher optionnellement un propriétaire, et ne faire payer que si aucun propriétaire n’est rattaché.

Je parlais bien de le mettre dans le Storage, afin de ne pas autoriser les doublons.

Autoriser la modification, pourquoi pas, mais bon ça ne me semble pas prioritaire du tout.

3 « J'aime »

J’espère que cela n’empêchera pas d’avoir des comptes anonymes. Juste pour être sûr.

2 « J'aime »