#dusk @Dusk
Hier, je pensais que, dans un système d’identité basé sur la blockchain, il fallait surtout prouver qu’une personne était éligible pour accéder à quelque chose. Je voyais principalement l’identité à travers ce prisme, donc l’idée de placer des identifiants sur la chaîne m’a assez facilement convaincu.
Mais quand j’ai creusé davantage du côté de Citadel 2, j’ai commencé à voir que le problème se situe dans ce qui est exposé lorsque l’on prouve qu’un identifiant est valide. Citadel 2 est en train d’être conçu non seulement pour vérifier qu’une personne détient une licence valable, mais aussi autour de la préservation de la licence et de ses attributs sous-jacents en privé. Ce détail m’a fait comprendre que prouver quelque chose et révéler les informations qui se cachent derrière cette preuve sont en réalité deux choses très différentes.
Ce qu’il faut se demander, c’est que Citadel 2 veut que ce processus se fasse via des preuves à divulgation nulle de connaissance, en plus de licences signées par LP, et avec une vérification de session sur la chaîne. Je pensais autrefois qu’une blockchain pouvant vérifier publiquement une affirmation d’identité, cela devrait suffire. Mais, pour de vrais services, le fait de publier des attributs personnels — voire même l’identifiant exact utilisé — sur la chaîne n’est parfois pas le choix le plus pratique. Un service peut avoir besoin de savoir qu’un utilisateur est valide, tandis que l’utilisateur peut ne pas vouloir tout révéler sur lui-même.
À partir de là, j’ai commencé à voir Citadel 2 moins comme un système d’« identité on-chain » typique. La vraie ambition semble être de prouver qu’un utilisateur dispose d’un identifiant valide sans exposer l’identifiant lui-même, tout en laissant la décision finale d’accès au fournisseur du service.
Je ne sais toujours pas si ce modèle de confidentialité sera assez simple pour que de vrais services puissent l’adopter à grande échelle. Peut-être que c’est la prochaine chose à surveiller.
$DUSK
$BTC
$TRUMP
Qu’est-ce qui compte le plus pour l’identité on-chain ?
Hier, je pensais que, dans un système d’identité basé sur la blockchain, il fallait surtout prouver qu’une personne était éligible pour accéder à quelque chose. Je voyais principalement l’identité à travers ce prisme, donc l’idée de placer des identifiants sur la chaîne m’a assez facilement convaincu.
Mais quand j’ai creusé davantage du côté de Citadel 2, j’ai commencé à voir que le problème se situe dans ce qui est exposé lorsque l’on prouve qu’un identifiant est valide. Citadel 2 est en train d’être conçu non seulement pour vérifier qu’une personne détient une licence valable, mais aussi autour de la préservation de la licence et de ses attributs sous-jacents en privé. Ce détail m’a fait comprendre que prouver quelque chose et révéler les informations qui se cachent derrière cette preuve sont en réalité deux choses très différentes.
Ce qu’il faut se demander, c’est que Citadel 2 veut que ce processus se fasse via des preuves à divulgation nulle de connaissance, en plus de licences signées par LP, et avec une vérification de session sur la chaîne. Je pensais autrefois qu’une blockchain pouvant vérifier publiquement une affirmation d’identité, cela devrait suffire. Mais, pour de vrais services, le fait de publier des attributs personnels — voire même l’identifiant exact utilisé — sur la chaîne n’est parfois pas le choix le plus pratique. Un service peut avoir besoin de savoir qu’un utilisateur est valide, tandis que l’utilisateur peut ne pas vouloir tout révéler sur lui-même.
À partir de là, j’ai commencé à voir Citadel 2 moins comme un système d’« identité on-chain » typique. La vraie ambition semble être de prouver qu’un utilisateur dispose d’un identifiant valide sans exposer l’identifiant lui-même, tout en laissant la décision finale d’accès au fournisseur du service.
Je ne sais toujours pas si ce modèle de confidentialité sera assez simple pour que de vrais services puissent l’adopter à grande échelle. Peut-être que c’est la prochaine chose à surveiller.
$DUSK
$BTC
$TRUMP
Qu’est-ce qui compte le plus pour l’identité on-chain ?
Private proof
21%
Transparency
29%
User control
14%
Both
36%
14 Votes • Vote fermé