BrightID - Identité unique décentralisée

Il ne faut pas courir deux lièvres à la fois, si on se lance dans des tests d’un pont Duniter<->BrightID ce sera sans Oracle.
L’utilisation d’un Oracle pour la WoT est intéressante et je suis favorable a très long-terme mais c’est un autre sujet qui n’a pas de rapport avec BrightID et qui n’a donc pas a rentrer en compte dans la future décision d’utiliser ou non BrightID :wink:

1 « J'aime »

L’utilisation d’un oracle simpliferait largement ce pont. Pour le “ce sera sans Oracle”, il serait bon que ce genre de décision découle d’une decision commune et non d’un choix personnel. Des personnes ont l’air interessées par cette solution, pourquoi faire une impasse dessus ?

J’ai bien montré qu’il avait un rapport précédement, puisqu’il permet d’externaliser la gestion des membres, permettant à la suite de remplacer facilement la WoT par un autre système comme BrightID. On a donc de meilleures perfomances, une séparation des différentes parties de la G1 ainsi que la possibilité de remplacer celles-ci.

Cela n’empèche pas de réfléchir à des méthodes qui pourront être utiles pour d’autres besoins.

4 « J'aime »

Il ne s’agit pas d’une “impasse” mais de séparer les sujets !

Il n’est pas “certain” que passé par un Oracle soit pertinent, ça rajoute un intermédiaire donc ça rajoute des sources d’erreur.
Et ce présent fil fut relancé par poka car l’un des dev de BrightID est intéressé maintenant par la réalisation d’un pont technique, donc soit on fait avec l’existant (donc sans Oracle) soit on ne fait rien et la collaboration est très mal engagée :confused:

Non, ça évite surtout d’adapter l’un des système à l’autre et réciproquement. BrightID ne dépend pas de Duniter, et Duniter ne dépends de BrightID que par son oracle qui abstrait la prise de décision. Je ne vois pas en quoi ce n’est pas pertinent.

Mais l’oracle est le pont technique ! C’est quelque chose de plutôt simple et qui permettrait de récupérer la base des utilisateurs de BrightID sans incorporer la logique de BrightID dans Duniter. C’est exactement ce qu’il nous faut pour réaliser une connexion avec BrightID. (surtout qu’avec le système d’identité unique il est assez simple de faire un oracle sans risque de manipulation tant que le premier est fonctionnel)

Il faudrait aussi que tu explique comment faire “à partir de l’existant” ? Comment l’existant permettrait d’utiliser BrightID sans modification ? Il ne peut pas. On doit remplacer le code de la WoT par quelque chose qui gère BrightID. Donc soit on fait un développement spécifique à BrightID (ce qui pose problème dans le cas où BrightID n’est finalement pas une bonne solution), soit un développement permettant de remplacer de manière générique la WoT (par BrightID, une WoT améliorée, autre chose), soit on ne fait rien et il restera laborieux de mettre à jour la système d’identité (qui est clairement la partie la plus complèxe de Duniter actuellement).

6 « J'aime »

Je suis plutôt d’accord avec @nanocryk : si on veut utiliser BrightID pour Duniter, il faut d’abord découpler Duniter de la WoT et de la gestion de la légitimité des identités.

Je ne sais pas si l’oracle est la seule solution pour faire ça, mais c’est une des solutions possibles.

De plus, il n’est pas envisageable de publier une “liste d’identités membres” et de s’y référer. Pour des millions d’utilisateurs, ce n’est pas du tout utilisable. Il est a mon avis préférable que l’on ait plutôt un système de questions/réponse type “cette clé publique est elle membre?” -> oui/non (avec la preuve associée).

2 « J'aime »

Je pense que @nanocryk utilise le terme “Oracle” de manière bien plus générique que les autres, d’où certaines incompréhensions.

L’Oracle est un service chargé d’entrer manuellement une donnée extérieure dans la blockchain. A l’instant T, qui aura été défini à l’avance, le service va récupérer l’information qui lui a été demandée et l’insère dans la blockchain à l’endroit qui lui a été désigné.

Donc il me semble qu’à peu près n’importe quelle transmission entre BrightID et la blockchain du protocole Duniter peut être qualifiée d’Oracle (du moment que c’est une API pas trop crado).

5 « J'aime »

C’est aussi la définition que j’en retiens, pont = oracle, nécessairement. Car si Duniter intègre tout BrightID en lui-même alors on n’est plus sur un système externes.

Par contre @elois peux-tu détailler le lien que tu envisage avec BrightID “sans oracle” ? Je ne sais même pas de quoi on parle pour l’instant :slight_smile:

1 « J'aime »

Le problème c’est que cette question/réponse prend du temps et de la place (vote d’un grand nombre de membres pour s’assurer que la donnée est valide).

Par contre, au lieux de poster la liste entiere, on peut simplement poster la racine d’un arbre de Merkle stockant l’ensemble des membres, demandant alors uniquement la preuve à l’utilisation.

J’avoue que je ne comprend plus… quand je demande la binarisation du protocole on me dit que c’est trop compliqué et quand je demande de tester un pont avec BrightID sans Oracle via une simple API Rest comme expliqué dans ce post on me dit qu’il faut faire plus compliqué pour que ce soit générique :sweat_smile:

Puisque vous semblez touts d’accord pour passer par un Oracle je vous laisse voir ça avec castall (un dev de BrightID), vous pouvez le contacter sur decstack : https://hub.decstack.com/projects/channels/brightid.
Perso je n’ai pas la possibilité de me lancer dans un tel chantier, c’est pour ça que je proposait de faire au plus simple dans un premier temps.

C’est encore plus compliqué avec une “simple API REST”. Chaque noeud va appeller cette API vers un BrightID, pouvant répondre quelque chose de différent à chaque fois, et dont le resultat peut changer au court du temps. Comment est-ce que l’on peut avoir un consensus sur ça ?

On ne peut pas, et c’est bien pour ça que le domaine des oracles est interessant : il permet justement de se mettre d’accord sur un élément exterieur. Ici chaque membre participant fait une requete à l’API REST de BrightID et poste son vote à l’oracle. S’il y a plus de X% de votes identiques, on peut considérer la réponse comme fiable et s’en servir pour la monnaie. Tu remplace cette API REST par un logiciel ou un module gérant la WOT, un “noeud BrightID directement” ou un autre système, l’oracle reste le même.

On a donc bien un système générique permettant de faire un pont avec BrightID, tout en permettant dans un premier lieu d’externaliser les calculs de la WOT.

1 « J'aime »

Il n’y a pas urgence à migrer sur BrightID non plus :slight_smile:

Pour moi, la première étape est de modulariser la gestion des identités au sein de la blockchain.

Une solution possible, comme proposé par @nanocryk, est d’intégrer la racine d’un arbre de merkle de la liste des membres dans la chaine.

Cette racine étant un hash, elle peut être compatible quelque soit le système sous-jacent : il suffit de trouver une construction sous la forme d’un arbre de merkle listant les membres.

On ajoute un champs “membersMerkleRoot” dans chaque bloc.

Avec Duniter en mode BrightID :

  • les noeuds requêtent une racine de merkle si BrightID est capable de la fournir, sinon ils requêtent une liste dont ils fabriquent un arbre de merkle et génèrent un merkle root (beaucoup moins optimal).

Avec Duniter en mode WoT :

  • Soit on génère 2 blockchains en parallèle. La blockchain qui gère la monnaie fait référence à la blockchain qui gère la WoT via ce membersMerkleRoot.
  • Soit on garde la blockchain standard, et on ajoute un champs “membersMerkleRoot”. Cette méthode me semble moins propre (les blocks contiennent des données différentes suivant le système de gestion des identités sous-jacent). Mais potentiellement c’est plus simple à réaliser.

Dans chaque cas :

  • Un noeud, lorsqu’il calcule un bloc, doit inclure une preuve de merkle pour montrer que sa clé correspond à un membre
  • Lors de la consommation des DU, le client doit inclure une preuve de merkle pour montrer que sa clé correspond à un membre à la date du bloc du DU généré
  • Est-ce qu’il existe d’autres actions qui nécessiteraient de prouver qu’on a une clé membre ?
2 « J'aime »

6 messages ont été déplacés vers un nouveau sujet : Systèmes de reconnaissance d’identité alternatifs

C’est surtout que définir “API REST” dans un protocole non-réseau est super difficile (je pense même que c’est impossible, c’est pour ça que je te demandais des détails sur l’idée que tu avais), alors que définir un Oracle non, c’est “facile” ou à tout le moins “possible”.

Moins optimal, mais permet de se plugger directement sur BrightID sans le modifier, ce qui est pas mal. Et quand on voit le nombre de Hash/s de nos machines, c’est plutôt négligeable tant qu’il n’est pas fait trop souvent (4 synchro par jour par exemple).

Les 2 blockchains me semblent plus simple, et évite d’avoir un doublon d’information ainsi qu’une généricité.

Yeap, ainsi que :

  • quand un nouveau membre publie ses 5 certifications, il doit donner la preuve de membre de ses 5 certifieurs.
  • quand une certification vers un membre existant à lieu, la preuve de Merkle des 2 comptes doit être fournie.
2 « J'aime »

Au cas où ça intéresse, la beta de BrightID est là :

3 « J'aime »

À suivre avec attention. Quelques un parmi vous ont déjà créé un groupe pour tester ?

Test wot brightID :wink:

3 « J'aime »

Pour info, le projet Mannabase se tourne aussi vers brightID (voir publi FB du 1er aout 2019)

1 « J'aime »

BrightID et WOT sont similaires dans leur construction d’une base de données d’identités décentralisée et non intrusive. Ce qui fera la différence seront les API qui seront mises à disposition pour être compatible avec les solutions d’authentification actuelles (oAuth, LDAP, …)

Un service d’authentification décentralisé et libre est un indispensable pour contrecarrer les OneID privatifs qui vont vouloir s’imposer… Votre trousseau de clef sera détenu pour vous par votre banquier ou par vous même? Quels seront les membres libres qui se joindront à la réalisation de cette mission?

Héhé, le RGPD a un vrai problème, comment une entreprise peut vérifier l’identité de quelqu’un ?

C’est vraiment le Graal cette histoire d’identité et les solutions centralisées ne sont visiblement pas fiables :

2 « J'aime »