Bon, la biométrie, ça va pas le faire… Et le séquençage ADN ?
Ok, je sors 
2 Likes
La biométrie pourrait 1 élément d’identification parmi d’autres…
On pourrait imaginer des identités avec X proof, toutes ne se valant pas et les certifieurs certifierait telle ou telle preuve ou toutes et on pourrait déterminé un niveau de confiance par nb de certif / nb de preuve.
Si tu veux certifier un compte mais que tu ne peux vérifier aucune preuve, attention.
Si tu souhaite que certifier des identités avec Carte d’Identité FR et adresse par exemple tu peux… lors de la rencontre vérifier la CI et envoyer un code par courrier pour l’adresse.
Il faudrait une sorte d’API Proof Object attaché à une identité et possibilité de certifier toute l’identité et/ou juste un object preuve… C’est à l’humain de vérifier la preuve et de la certifier ensuite
Si un compte n’as qu’une preuve “compte FB” par exemple tu ne fait pas confiance…
Plus de souplesse dans les certif, sans sacrifier sécurité.
Idée comme ça jetée en l’air…
Edit: pour l’adresse, le certifieur peut envoyer le document de certif signé encodé dans un qrcode par la poste. Le certifié à la reception scanne le qrcode et envoi la certif en blockchain. Méthodologie applicable à d’autres scénarios peut-être…
Ces éléments d’identification ne devraient par contre pas être intégré à la blockchain, ou en tout cas pas dans le protocole Duniter, mais dans une couche au dessus.
Une idée que j’ai mis en application lors de mon inscription, c’est de se prendre en photo avec un papier sur lequel est écrit la clé publique ainsi que la date, envoyer cette photo aux certificateurs et mettre son hash sur la blockchain (commentaire de transaction par exemple). On sait alors que la clé est bien possédée par cette personne, et aucune information n’est publique (uniquement le hash de la photo). On peut y ajouter une carte d’identité par exemple, et l’idée d’un courrier est pas mal non plus, mais pas gratuit.
Je ne parlais pas de mettre les données (senssibles) dans la blockchain, mais plutot des entrées libre du genre:
- “photo avec data+key” (certifié pas X personnes)
- “rencontre physique” (certifié pas X personnes)
- “réseaux sociaux” (certifié pas X personnes)
…
Certain te diront que c’est insuffisant car tu peux avoir un pirate qui se fait passer pour ton pote et t’envoi une photo de lui retouchée avec sa clé sibylle et tout le reste de vrai, mais c’est pas la personne que tu crois… avec une vidéo c’est déjà plus dur, mais on peut voir plus haut que ça se fake aussi…
Bien entendu la clé publique à été communiquée avant, par exemple pendant un Apéro Monnaie Libre.
En effet. Après je pense qu’il ne faut pas le rendre obligatoire, mais on pourrait ajouter un champ “commentaire” dans le document de certification qui pourrait servir à stocker cette liste de hashs, ainsi que de rajouter un outils permettant de chercher un hash spécifique dans les certifications passées. Il ne faut par contre pas que ces hash soient issus de photos, sinon chaque nouvelle photo du même document physique donnera un hash différent. On pourrait adopter par convention un certain format texte qui serait ensuite hashé, et que chaque document physique ne puisse donner qu’un unique résultat.
Je me demande si on ne pourrait pas stocker ces documents hors-chaine. Il faut juste qu’ils fassent référence à des blocks valides pour qu’ils ne puissent pas être anti datés, non ?
Pas besoin de stocker les documents, mais juste les hashs.
En les stockant hors-chaine, tu ne peux pas les dater dans le futur, mais tu peux le dater n’importe quand dans le passé. A voir si ça pose problème.
Si tu les poste on-chain, alors le block qui le contient prouve que ce document à existé au moins à partir de ce block. Donc en combinant les 2 (inclure un id de bloc et le mettre dans un bloc), on peut prouver que ce document à été créé dans l’intervalle de temps entre ces 2 blocs. Je pense que cette propriété peut être intéressante dans notre situation.
1 Like
Perso, je suis farouchement opposé à la biométrie, on ne fait pas identité avec son corps, mais avec son nom et la reconnaissance de ses pairs. Sinon, c’est de la gestion de troupeau !
6 Likes
Bonjour @Carole_Fabre
« faire identité avec un nom… »
que penses -tu de la situation suivante:
l’Arabie Saoudite est le 1er pays a avoir reconnu un robot en tant que citoyen.
Le robot à une identité , il porte un nom : Sophia
Il est reconnu par ses pairs 
Si cette “personne” arrive a créer un compte sur Césium (ou autre)
et arrive a convaincre 5 membres de la certifier… bah “elle” sera membre…
Le “problème” c’est bien la responsabilité des 5 membres
2 Likes
faut comprendre que c’est un fake cette IA que l’on nous vend … quand on sera au temps des cyborgs mi-humains, mi-machines, on avisera
3 Likes
Carole,
IA faible => depuis des années les algos sont a plein regime dans la vie courante
IA forte => bien malin celui qui peut affirmer
" on a le temps de vivre 100 vies avant qu’une telle réalisation ne voit le jour "
ce qui est " fake " :
c’est nier les travaux dans les domaines des NBIC et de l’IA et l’impact de ces technologies
“mi-humains <=> mi-machines”
comment qualifier cette situation ?
ou https://www.inria.fr/centre/nancy/innovation/rii/demos/bras-robotique
et les différents organes mécaniques que l’on prototype a travers le monde…
Comment qualifies tu une personne avec un pace-maker ?
et quoi penser des nombreux hack de ces pace-maker ?
1 Like
Oui je penses qu’un simple champ commentaire à l’instar des transactinos suffirait au niveau du protocol, et puis ensuite c’est libre d’implémentation.
Comme pour les transaction, un client peut remplir ce champ à l’aide d’une syntaxe spécifiée quelque part…
Dès lors, nous pourrons certifier des objets de la blockchain par leur uid, qui pourront être juste indication, relié un autre système d’information externe, ou bien texte clair pour les humains.
Je penses que le protocol doit définir juste un chhamps text, comme pour les TX, et c’est aux différentes implémentation de clients de se mettre d’accord pour une syntaxe commune en dehors du protocol lui même…
Ou bien l’inverse: la certification (infalsifiable en blockchaîne) contient des liens vers des hash donné d’un système d’information externe…
Et pour ca le meilleur des candidats serait IPFS, un noeud companion de chaque noeud DUniter suffirait à pouvoir accéder de façon identique à tel ou tel document linké par son hash de contenu ds la certif et/ou les transactions…
Un hash IPFS peut pointer vers un dossier, un fichier, ou une données d’un arbre merkel, c’est assez souple pour permettre de référencer n’importe quoi, et le tout sans encombrer la blockchaîne.
L’intéret est qu’un hash donné pointera TOUJOURS sur le même contenu de fichier, si le fichier est modifé même de façon minime, le hash sera différent. Donc un hash IPFS ds un champ comm permet de pointer avec assurance vers TOUJOURS le même contenu… Infalsifiabilité !
De plus il y aurait moyen de déterminer un IPNS par personne ce qui lui donne un “dossier” perso dans lequel il peut mettre tout un tas de chose (publique) ou bien des choses privée à l’aide d’un hash non diffusé publiquement…
C’est bien ce que à quoi je pensais.
De même ici, IPFS étant un support possible de l’information. On pourrait très bien imaginer aussi un champ libre “commentaire” dans le bloc qui puisse par exemple stocker le hash d’un bloc d’une sidechain, permettant ainsi de faire du merge mining. Ces sidechains pourraient permettre de stocker de nouvelles informations pour des protocoles annexes, par exemple ce système de documents hachés.
Je pense rajouter ces différents champs dans la future version du protocole, ce qui pourrait permettre pas mal d’extensions de Duniter sans modifier le protocole central.
On est parti sur une idée de système généraliste permettant de renseigner une preuve biometrique pour ceux qui le souhaitent, ou tout autre preuves pertinentes pour les autres, sans forcer quoi que ce soit, juste laissant la possibilité de le faire. Du coup liberté totale des certifieurs de faire confiance à la “preuve biométrique” ou bien la “preuve de rencontre” ou encore la “preuve de réseaux sociaux cohérents” etc…
Et pour des cas de nom identiques? il va bien falloir trouver un élément distinct pour ces 2 personnes.
Par exemple j’ai déjà au moins 2 homonymes exacts sur FB (nom et prénom) et au moins 10 personnes avec le même nom que moi…
Il faut prévoir les cas particuliers… Maintenant je suis d’accord que la biométrie n’est pas souhaitable (pour moi) car ce n’est pas sûr ni certain à 100% et peut entraîner des abus sur les corps des gens à des fins de vol d’identité, ce qui est inacceptable!!
Par contre peut-être que adns 80% des cas le nom/prenom suffit, mais pour d’autres ils auront besoin, je sais pas, par exemple du lieu/date de naissance pour être différenciés…
Ouais bon alors carrement revoir la structure de bloc, pour n’avoir que les headers utiles aux clients light (style SegWit) et un champ “content” qui pointe un hash à récupérer sur IPFS…
Ce hash serait un lien vers un dossier IPFS listant les données des ce bloc en blockchaîne :
content
/members
/transactions
/certifications
… etc
Pour vérifier la BC il faut lire les header de bloc 1 par 1 et faire un get du folder IPFS pour savoir ce qu’il y a eu ds chacun des block…
Par contre sa implique de la gestion de “pin” de document IPFS, car il y’a des données qui devront être loadé par chaque noeud et non garbage collectée, donc ya du dev à faire 
Je pense qu’il est important de se dissocier de tout autre protocole. IPFS peut être intéressant pour des données annexes, mais pas pour les données de blocs. Ca fait une dépendance de plus et rajoute de la complexité, ce que j’essaye justement de limiter au maximum.
Sinon ma RFC va définir une nouvelle structure pour tous les documents actuels, avec entre autre l’utilisation d’arbres de Merkle qui pourraient permettre à des clients léger de vérifier que les sources sont valides en ne téléchargeant que les en-tête de blocs.
2 Likes
Attention : pas sur que ça soit nécessaire. Dans Duniter, les clients ne sont pas sybilizable (chaque noeud est identifié). Un client SPV qui ferait des vérifications suivant ce qu’on imagine pour l’API GraphQL n’aurait ainsi pas besoin de télécharger les entêtes des blocs, qui n’apporteraient il me semble aucune sécurité par rapport aux requêtes validées sur plusieurs noeuds distincts.