Gestion des identités dans une monnaie de production

Archives Discussion
1

Je souhaitais partager avec vous ma réflexion au sujet des identités pour une monnaie de production, et plus précisément de la méthode que l’on pourrait employer pour s’assurer de l’unicité des identités de la toile.

TL;DR
Avoir comme identifiant utilisateurs des informations personnelles comme nom, prénom, date et lieur de naissance est dangereux. Aussi, si l’on compte se reposer sur des plateformes web qui recenseraient les identités et nous aidaient à croiser des informations, alors je suggère que l’on utilise la blockchain et plus précisément le champ Commentaire des transactions afin de lier, par un protocole simple, des informations d’identités à notre clé.

Exemple : POL:LINK:https://monblog.moi.fr indiquerait un site web à consulter qui corroborerait mon identité. On pourrait ajouter d’autres sites ou informations bien sûr, mais principalement cela permet une indexation facile par les outils externes et surtout une authenticité et non-répudiation desdites informations du fait de la signature et de la blockchain.

Voilà.

Aujourd’hui dans TestNet

Comme vous le savez déjà, pour le moment nous passons par le forum en faisant une petite présentation, en donnant quelques liens et au vu du nombre assez restreint d’utilisateurs et du fait qu’il s’agit d’intégrer TestNet (une monnaie de test), cela nous suffit largement.

Bien sûr nous savons que cela n’est pas tenable à terme, nous en avions conscience dès le départ. Croiser les données sur un forum pour une centaine d’utilisateurs passe encore, mais doublez ce nombre et ça devient ingérable.

Il nous maintenant parler de l’avenir étant donné l’avancement des logiciels.

Fixons le cadre

D’abord, il faut imaginer que l’on se place dans une monnaie Duniter à la Bitcoin : imaginons une monnaie P2P, sur internet, et donc dans un environnement non contrôlé. Ce n’est donc pas l’exemple d’une monnaie qu’on voudrait locale géographiquement, où ses membres se limiteraient à intégrer d’autres locaux.

La méthode de l’identifiant unique

C’était l’idée d’OpenUDC, utiliser un identifiant “unique” rassemblant des informations comme notre nom, prénom, date et lieu de naissance, informations qui pourraient facilement être croisées avec des papiers d’identité pour un certain nombre de pays, notamment la France. @bou2fil en parlait dans son topic WOT, condification du pseudo en donnant pour exemple :

FR-31-Phil-Bood-1998-M-Fr-En

Ce système a pour point fort de rendre facile le tri et la vérification des identités par comparaison avec le système d’identification de l’Etat pour éviter un 1er niveau de triche, ce qui est un point à ne pas négliger.

Le problème des informations d’identité étatiques

Un 1er problème qui va à l’encontre du choix de cette solution, c’est que beaucoup tiennent à leur anonymat et que là, on leur propose tout simplement de s’asseoir dessus. :confused:

Mais à la limite, ce n’est pas le plus gênant : le pire, c’est qu’aujourd’hui beaucoup de systèmes (banques, assurances, opérateurs internet/téléphonie, etc.) se suffisent de telles informations pour nous identifier & authentifier lors d’un appel téléphonique avec eux, entre autres possibilités. Et donc en publiant ces informations, on s’expose à l’usurpation d’identité, ce qui n’est pas cool du tout.

Bref, étant donné la situation actuelle, nous avons besoin d’autre chose.

Les plateformes de recensement

Une solution qui est évoquée par ici pour le projet Duniter, c’est de se reposer sur des outils externes et notamment des sites web qui recenseraient les identités et nous permettraient à nous, utilisateurs de Duniter, de faire le tri dans les personnes prétendant vouloir participer de la Toile de Confiance et de la production de la monnaie.

Je sais qu’il existe déjà plein d’outils qui prétendent faire cela. MAIS, ce que je souhaite évoquer ici, c’est que l’on dispose d’un environnement fondamental qu’il serait très intéressant d’utiliser pour alimenter une telle plateforme. En effet, nous disposons :

  • d’un trousseau de clés cryptographiques par identité
  • d’un registre global et irréversible (admettons) : la blockchain

L’idée que je suggère, c’est que l’on mette au point un protocole simple utilisant le champ Commentaire des transactions afin d’y ajouter des “indices” confortant la réalité et la non duplication de l’identité.

Par exemple POL:LINK:https://monblog.moi.fr permettrait de lier un site web à son identité. On pourrait en créer autant que l’on souhaite (1 par transaction) et surtout en créer d’autres types, par exemple POL:ID:GITHUB:c-geek permettant de lier un identifiant externe à une identité.

Bien sûr pour faire cela, les clés utilisées pour réaliser l’identité auront besoin d’avoir reçu un peu de monnaie pour réaliser ces “fausses transactions”. Mais à la limite, ça fait un filtre de plus.

Voilà, c’est tout simple et ça peut faire office de méthode initiale pour publier des informations d’identité.

« Oui mais les transactions c’est pas fait pour ça »

Oui, mais elles le permettent et surtout ce champ est informatif et sans impact sur le logiciel. En plus, cela peut éviter d’alourdir le coeur avec de nouvelles fonctions. Alors autant utiliser ce simple champ.

Votre avis / Vos solutions

Bien sûr, ceci n’est qu’une proposition et il y a plein de solutions possibles, toutefois celle-ci à la vertu de figer les informations dans le marbre et de permettre une indexation externe facilitée.

Qu’en pensez-vous ? Avez-vous d’autres idées à proposer ? Car à mon avis il faut vraiment commencer à y penser : plus tôt la méthode trouvée est claire et reproduite par tous, et plus le déploiement d’une monnaie libre sous Duniter sera efficace.

Bien à vous

2

L’idée est intéressante. Avantage : simplicité et sécurité.
Par contre, je me pose une question. Quels sont les infos les plus pertinentes d’une identité et combien “d’indices” nécessaires?
Par ailleurs, je suis plutôt favorable à l’identifiant unique évoqué par @bou2fil. Il me semble pertinent d’avoir à disposition les 2 solutions, ce qui permettrait au moins une seconde solution. S’il apparaissait un problème avec l’une, l’autre y suppléerait…

3

En partant de ton idée que je trouve très intéressante, on pourrait rediriger les utilisateurs vers un site style Remuniter, mais dédiée à la validation des identités. Comme il faut pouvoir prouver son identité avant de recevoir un quelconque DU, ce service permettrait à tout le monde de réaliser cette procédure en amont d’une demande d’adhésion.

Cette application serait un simple guide :

  1. Bienvenue dans la communauté XXXX, pour faire vérifier votre identité, je suis là pour vous aider à publier des preuves de votre existence et unicité.
    Pour commencer, veuillez entrer votre clé publique.

  2. [L’utilisateur entre sa clé publique]

  3. Parfait. Je vous propose maintenant d’enregistrer dans la blockchain des informations vous concernant. Veuillez sélectionner une information vous concernant (site/blog/identité…)

  4. [L’utilisateur entre une information (adresse de blog, pseudo github…)

  5. Merci. Veuillez cliquer sur le lien ci-dessous pour ouvrir votre portefeuille. Celui-ci va vous proposer de me renvoyer une transaction de 1 unité, stockant l’information que vous venez d’entrer.

  6. [L’utilisateur clique sur le lien duniter://TX:[inputs]:[outputs]:[unlocks]:[pubkey]:[commentaire]
    Son client de bureau s’ouvre, et propose de renvoyer l’unité reçue.

  7. La procédure peut être répétée autant de fois que le souhaite l’utilisateur. Pendant ce temps, l’application est en attente de validation de l’échange. L’envoi de l’unité par le bot doit être validée avant le retour de la transaction.

Le site peut ainsi proposer de voir le nombre de validation donnée pour une seule unité. Pour éviter les vols d’unité, l’application pourra réutiliser les mécanismes de TIMELOCK/XHX. En l’absence de transaction correcte se basant sur son unité vers lui même avant 3H, et possédant un verrou temporel, il publierai une transaction d’annulation.

Ainsi le point d’entrée est simple et efficace, le process est transparent pour tout le monde.

4

@mamygeek

Oui on peut tout à fait utiliser les 2 solutions indépendamment. Mieux : on ne peut pas empêcher les utilisateurs d’utiliser cette codification pour leur UID.

D’ailleurs je n’avais pas vu que, dans la solution de bou2fil, toutes les informations ne sont pas données : on n’a pas la date de naissance précise, ni le lieu précis, mais des informations partielles. Ce qui permet de conserver un certain anonymat et se prémunir du vol d’identité en grande partie.

Après, il faudrait peut-être ajouter 1 champ ou 2 pour éviter les collisions, un pseudonyme par exemple.

@Inso

OK je crois comprendre l’idée et ça me parait effectivement jouable, mais ça demande quand même :

  • le développement de la plateforme (côté web + backend permettant d’automatiser les échanges de transactions)
  • le support d’un protocole duniter:// dans les clients, et plus précisément celui permettant de récupérer une transaction signée (ex. duniter://TX:[...]:?callback=https://identification.duniter.org/callback) qui permet “d’annuler” l’envoi d’unités.

Mais c’est très intéressant quand même, et ça peut devenir une solution standard à long terme :slight_smile: merci les crosschain transactions … ça ouvre vraiment des portes énormes !

Personnellement, je crois que je vais pencher pour un mix des 2 solutions. Celle de la codification comme soutenue par @bou2fil et @mamygeek pour un démarrage rapide et très simple, puis certainement compléter par un protocole automatisé d’identification comme proposé par @inso.

1 Like
5

Oui pour le support du protocole, c’est quelquechose d’assez important de toute façon si on veut créer des badges web “payez moi en monnaie libre !” :wink:

Pour le callback, je ne suis pas certain de comprendre pourquoi il doit être envoyé au client ? Dans ma vision, c’est au backend de l’application de s’assurer que son unité n’est pas volée et qu’elle est rendue avec une information d’identification.

6

Hé bien si le système utilise ses propres unités de monnaie, c’est sûrement mieux que ce soit lui qui s’assure de la propagation de la transaction ?

Par exemple le système génère une transaction TX1 à partir d’une unité qu’il possède avec en sortie une unité qui lui revient (opération nulle donc) mais que cette transaction possède 2 émetteurs, donc 2 co-signataires, le système est probablement le mieux placé pour propager la transaction sur le réseau et “verrouiller” l’unité ainsi allouée pour cet utilisateur.

Or si l’on s’en remet à l’utilisateur, alors on ne peut pas s’assurer dans le système qu’il existe effectivement une transaction qui pourra dépenser l’unité, puisque c’est l’utilisateur qui a tous les éléments en main. Donc le système ne peut pas décider tout seul, il ne sait pas s’il verrouille l’unité pour rien ou pas, c’est moins automatisé.

Mais avec une callback, alors le client de bureau peut avertir le système de la transaction plus rapidement. Et donc si le client répond par exemple dans la minute, alors le système possède la transaction (tout comme l’utilisateur) et peut garder l’unité verrouillée plus longtemps sur la base de cette donnée fiable. Et s’il ne reçoit pas la réponse passé 1 minute, il peut considérer que l’utilisateur annule l’opération et que l’unité peut être allouée à quelqu’un d’autre.

Avant de rédiger cette réponse, j’étais plutôt parti sur les mécanismes de transactions crosschain où notamment les utilisateurs (ici un système A + un utilisateur B) se renvoient des transactions à co-signer. Et un système de callback me semble adapté à cette situation.

1 Like
7

Ah oui tiens, c’est encore plus simple. C’est possible ça, une seule transaction qui envoi et récupère l’unité pour 2 signataires, au lieu de 2 transactions, une pour envoyer et une pour récupérer ?

Et je vois l’intéret du callback oui. C’est intéressant comme idée, je me demande si c’est très standard dans les systèmes faisant de l’interconnexion web/desktop ?

8

Oui c’est déjà possible et ça fonctionne de cette façon.

Je n’en sais trop rien, mais en tout cas c’est comme ça que fonctionne OAuth (le protocole permettant de s’inscrire et s’authentifier sur un site avec un compte existant ailleurs [GitHub, Twitter, …], par exemple pour ce forum).

1 Like
9

Je comprends pas trop ce que vous avez écrit ci-dessus (@cgeek et @inso) vu que vous êtes les experts, les parents du bébé duniter. Je ne connais pas toutes les possibilités qui sont implémentées : annulation d’opérations, transactions inter-monnaies si j’ai bien capté…
Ce que je pense c’est que si l’on cherche à certifier des personnes physiques en les identifiant elles ne peuvent pas être anonymes. Pourtant l’anonymat a des avantages (personne n’a besoin de savoir ce que vous faîtes de votre monnaie ; c’était le cas avec les espèces en monnaie officielle, mais cette possibilité se réduit avec les plafonds imposés pour les achats chez les commerçants toujours plus bas) ; pour obtenir cet anonymat il faudrait qu’entre la personne certifiée et sa clé qui reçoit le DU il n’y ait pas de lien apparent (on certifie les gens avec leur clé de certification et ils “reçoivent” -avec un système adhoc s’il est possible de le mettre en place?- les données confidentielles utiles pour accéder à leur clé publique anonyme qui reçoit le DU.

Autre sujet de préoccupation : vos propositions de preuve d’identité (site web, réseau social…) ne protègent pas de l’usurpation d’identité: je peux créer une boite mail et vous envoyer une demande de certification en utilisant les données de mon voisin : son identité sur un réseau social ou son site web, en obtenir un accès au DU en utilisant son identité. Il aura alors du mal à pouvoir y accéder à son tour.
Ce problème d’identité, de KYC (Know Your Customer) me parait crucial (est ce que la solution ne serait pas d’ utiliser des services qui offrent une bonne fiabilité en matière d’identité : abonnement à un service de téléphonie mobile ou FAI avec SMS de confirmation que vous êtes bien qui vous prétendez être? diffusé à ceux qui certifient mais pas public, pas dans la blockchain car problème des données personnelles, CNIL)
Voila, c’était mon point de vue du moment (celui d’un observateur non technicien qui espère pouvoir utiliser un tel système dans un proche avenir).

Autre inquiétude : est ce que vous ne craignez pas l’adoption d’une loi (style Hadopi interdisant le partage de fichiers P2P) qui interdise purement et simplement duniter (comme en un temps il y avait eu une tentative d’interdiction des SEL, et comme les MLC sont strictement règlementées pour les rendre difficiles à mettre en oeuvre et peu efficaces, comme la NEF qui semble avoir beaucoup de difficultés à obtenir les agréments pour devenir une banque avec comptes courants pour les particuliers …)

10

L’anonymat peut être réalisé par un service annexe. Un peu comme un proxy ou un VPN, mais pour la monnaie.

Le service d’authentification demandera des références à des actions bien précises. Exemple :

  • Pour valider un compte github, pointer sur un commit contenant le format brut de votre document d’identité sur un repo
  • Pour valider votre compte twitter, pointer sur un twitt contenant le format inline de votre document d’identité

Etc… Ainsi la personne qui s’authentifie prouve qu’elle possède bien ces comptes. C’est le lien vers le twitt ou vers le commit git qui est enregistré dans la blockchain.

C’est un service de base qui permet un premier niveau de vérification et qui reste relativement décentralisé.
Pour d’autres niveaux de vérifications, ils se développeront avec l’adoption de la monnaie libre…

Non. Il n’y a pas de “vol”, de problème de “propriété intellectuelle”. Juste de la création d’unités que les individus peuvent échanger. Je ne vois pas comment une telle chose peut-être interdite dans un pays libre. si on regarde les cryptomonnaies actuelles, la tendance est plutôt à l’encadrement et au contrôle des innovations et des nouvelles valeurs qu’à leur interdiction.

11

Cela dépend bien sûr de la définition, par exemple dans Duniter n’est pas du tout anonyme puisqu’il possède a minima un pseudo, une clé publique et une date de création. On peut nommer le membre.

L’identité étatique n’étant jamais qu’un pseudo un peu plus long, contenant des données que l’on peut croiser avec d’autres documents. C’est pour cela que je propose d’ajouter des liens vers des données externes pour croiser les informations.

Il y a plusieurs solutions possibles sans remettre en cause le fait que la nouvelle monnaie provienne des membres, par exemple le tiers de confiance tel une banque en monnaie libre. Vous déposez votre monnaie là-bas, et vous faites des ordres de paiement via un canal privé.[quote=“bou2fil, post:9, topic:1170”]
Autre inquiétude : est ce que vous ne craignez pas l’adoption d’une loi (style Hadopi interdisant le partage de fichiers P2P) qui interdise purement et simplement duniter
[/quote]

Que peut-on y faire ? S’ils le veulent ils peuvent pondre une telle loi. Mais d’une part cela ne dit rien quant à sa possibilité d’application, et d’autre part est-ce que nous aurions dû ne pas produire Duniter sous prétexte de ce fantôme de “l’Etat qui va vouloir tout détruire” ?

A ce rythme là bien sûr, on n’avance sur aucun sujet. J’ose espérer toutefois qu’ils n’auront aucune base légale permettant d’interdire un tel système, ou que même s’ils passent une loi illégale (on n’en serait pas à la 1ère loi anticonstitutionnelle ou contraire aux Droits de l’Homme et du Citoyen) qu’ils le fassent avec un retard tel qu’il est déjà trop tard.

Le mieux étant que l’Etat tente de se greffer à l’outil et demande une taxe. Ainsi il reconnaîtrait l’existence d’une chose qu’il ne contrôle pas, et qui aura une influence forte sur lui à long terme.

1 Like
12

Ce qui pourrait arriver de mieux en fait, serait que l’état intègre la monnaie libre dans ses comptes.
Plus de soucis d’identification, une monnaie libre connue et disponnible pour et par tous. Une fluidité des échanges jamais atteinte depuis l’apparition des monnaies. On se demande pourquoi nos artistes développeurs ne sont pas subventionnés :smiley:

1 Like
13

C’est une idée que je tente de partager depuis que je connais la TRM (début 2016). C’est tout à fait possible mais avec des conditions difficiles à remplir:

1 - réunir un groupe de travail performant pour la mise en oeuvre optimale c’est à dire acceptable par le plus grand nombre tout en respectant une transition juste (la plus facile)

2 - rassembler autour d’un projet global que je présente depuis avril sur laprimaire.org… (mal parti)

3 - et enfin, de profiter de l’opportunité exceptionnelle (particulièrement propice) de la prochaine élection…

Mais ceci est une autre histoire qui n’a pas sa place ici :slight_smile:

14

La question doit effectivement être posée car elle interroge les fondements même du projet. Ce que je trouve notamment intéressant avec Duniter c’est la notion de toile de confiance.

Le fait de chercher des moyens pour empêcher la fraude c’est exprimer de la méfiance envers l’autre, ce que je conçois tout à fait puisque c’est de cette manière que nos esprits sont formatés. C’est d’ailleurs cette méfiance qui est le principal obstacle à l’acceptation par le plus grand nombre d’un revenu de base inconditionnel versé à vie.

Sachant qu’il n’est pas possible d’empêcher totalement la fraude et que Duniter promeut la confiance envers l’autre, il existe alors une autre approche du problème qui consiste à accepter la fraude et faire en sorte que les utilisateurs ne soient pas motivés pour frauder.

Je pars du principe “non pas résoudre mais éviter” alors je m’interroge encore sur l’utilité d’une fonction d’audit des comptes qui présenterai une élévation rapide de leur solde. Avec la blockchain je pense qu’il est possible de tracer toutes les transactions et en cas de suspicion de fraude cela permettrait de vérifier si l’enrichissement est légitime ou frauduleux. A voir si cela peut rassurer les utilisateurs et renforcer leur confiance…

2 Likes
15

Soyons pragmatiques. “Vaut mieux prévenir que guérir”. La confiance ne peut intervenir qu’en amont. Personnellement, je ne fais pas confiance à un logiciel non sécurisé ou que je ne connais pas. Par contre, aucune raison de ne pas faire confiance aux personnes que je connais d’une manière ou d’une autre et aux logiciels dont la priorité est l’ouverture du code. De nos jours, nous sommes sensibilisés au numérique et l’utilisateur lambda connait de mieux en mieux ses usages et ses dangers.

Pour conclure, avoir un système sécurisé ne veut pas dire méfiance. Tu ne confierais pas ton portefeuille, les clés de chez toi à n’importe qui, non? alors pourquoi le ferais-tu pour Duniter? :slight_smile:

16

Nous sommes d’accord, non pas résoudre mais éviter. Selon le référentiel une solution adaptée s’exprimera différemment. De la même manière que tu peux choisir la géométrie qui convient le mieux pour un problème donné dans un référentiel donné tu peux choisir un ensemble de protocoles qui conviendra le mieux pour garantir une confiance suffisante des utilisateurs envers Duniter.

Aucun ne sera meilleur que l’autre, ce sont deux points de vue différents. Si tu prends pour référentiel que les autres ne sont a priori pas dignes de confiance alors oui la mise en place des mesures exposées ci-dessus prend sens. Si tu prends pour référentiel que les autres sont a priori dignes de confiance alors les mêmes mesures n’ont pas lieu d’être. C’est ce deuxième point de vue qui n’apparaissait pas ici que je souhaitais présenter.

Ce qui m’intéresse avec Duniter c’est justement de pouvoir expérimenter ça. De la même manière et pour répondre à ta question, pourquoi pas jeter mes clefs comme dans l’An 01 : http://www.sami.is.free.fr/gebe/L.an.01-46.jpg

2 Likes
17

Est-ce qu’il est possible de se faire une transaction à soi–même contenant 0 de monnaie?
Dans ce cas il suffirait d’utiliser le champs commentaire pour “s’attacher” une information à sa clé pub !

Il pourra y avoir plusieurs type d’information ( ville, age, adresse, etc ).
Une seule information par transaction.
Les clients pourrait proposer à l’utilisateur d’inscrire des informations relatifs au dit client avec des sous-types.

Cela permet:

  • de compter les transactions de moi à moi >> afficher le taux de remplissage des infos
  • de lister les transaction de moi à moi >> lister informations liés à se compte
  • les afficher avant la certification, et le certifieur peuut vérifier ces infos
  • permettre certains réglages de l’unicité >> on ne verifie que le champs nom et prenom unique lors de l’inscription ou bien l’adresse doit être renseignée ainsi que année de naissance.
  • lister toutes les transactions de type adresse et vérifier qu’il n’y à pas trop de compte à la même adresse ou un autre type donné
  • permet à des services tiers d’apposer une certification supplémentaire, telle qu’une app FB, que l’utilisateur doit installer qui le lierait avec sa clé pub.

bref des infos dans la blockchain !
Et libre à l’utilisateur de les remplir ou non. C’est quand un compte mal rempli ou infos pas vérifiables que les soupçons permettrons à la personne de ne pas certifier…
Un peu comme quand on te demande en ami sur FB, et que le compte est vide ou il à des informations bidons, tu refuses.

18

Une autre idée:

Dans ethereum, ils ont créé un service qui vérifie les adresse très astucieux:

Tu envoi une transaction avec attaché ton adresse postale et un peu de monnaie à un service qui automatiquement envoi un courrier à cette adresse avec un QRcode (le montant sert au courrier), un token de validation qui valide l’adresse et l’associe à la clé pub auprès de ce service.
Ensuite les marchants qui ont besoin de valider une adresse, interrogent le service avec l’adresse qu’ils ont et la clé pub le service renvois oui ou non.

On reste dans le tiers de confiance… mais spécialisé, ils ne font que ca, valider une adresse.
https://proofofphysicaladdress.com/

19

Et sinon encore plus souple pour le partage de donnée:

Lier un nœud DUniter avec un nœud IPFS, ce qui permet d’avoir plusieurs gateway IPFS par blockchain. Ensuite il est facile de créer un ou des fichiers immuables dans l’IPFS, même à réseau privé IPFS seulement réservé pour cette blockchain. Et puis inscrire le hash dans le commentaire d’une transaction. Et hop tu as lié un fichier partagé en p2p qui a un hash immuable à une transaction dans une blockchain immuable !

20

Cette solution, utilisée dans Monnaie M, est à mon sens facilement contournable.