Quand j’ai vu « faire un seul KYC et pouvoir le réutiliser partout » dans Citadel 2 en lisant $DUSK , ça m’a vraiment parlé. J’ai pris un peu de temps pour me poser, relire la documentation et parcourir le dépôt de code, et c’est là que j’ai découvert qu’il y avait des prérequis bien cachés.
L’ensemble du processus, en résumé, se déroule comme suit : l’utilisateur passe par un LP pour effectuer une vérification d’identité hors ligne, obtient ensuite un jeton chiffré enregistré on-chain, puis lorsqu’il accède aux différentes applications par la suite, il prouve sa conformité via des preuves ZK, sans avoir à exposer d’informations privées.
Au début, je pensais que tant qu’on fait une fois un KYC et qu’on obtient un jeton, on pourrait l’utiliser partout. Mais en poussant la logique du protocole de Citadel plus loin, j’ai trouvé un détail clé : le Service Provider a le droit de décider lui-même à quels License Provider il fait confiance.
Citadel n’impose pas que tous les SP acceptent la même norme de justificatifs. Par exemple : dans le cadre du business A, on fait confiance aux LP de ce choix ; dans le business B, on peut ne pas les accepter. Si tu as fait ton KYC dans le business A et que le business B n’accepte pas les justificatifs émis par ce LP, il faut recommencer. Le périmètre de réutilisation d’un « KYC une fois pour toutes » est donc naturellement limité à un « petit cercle » où l’on se reconnaît mutuellement un même ensemble de LP. En dehors de ce cercle, la réutilisation ne fonctionne plus $BTR .
Je voulais voir à quoi ressemblait la documentation d’intégration pour les institutions. En parcourant, j’ai bien vu que le W3sper SDK existe, mais je n’ai pas trouvé une version suffisamment complète pour les guides d’intégration au niveau institutionnel ni pour les solutions de gestion des permissions. Peut-être que je ne suis pas allé au bon endroit, mais au moins via les canaux publics, il semble que pour qu’une institution s’y connecte directement, les barrières d’entrée ne sont pas faibles.
Faisons une comparaison avec l’eIDAS de l’Union européenne : dans le monde réel, la reconnaissance mutuelle des identités avance déjà depuis longtemps, même si ce n’est pas basé sur ZK. La démarche technique de Citadel ne pose pas de problème, mais le protocole d’identité dépend énormément des effets de réseau. Pour que le système tourne, il faut beaucoup de LP agréés, et il faut aussi que divers SP de services acceptent ces justificatifs. J’ai essayé de chercher des exemples de LP agréés externes déjà déployés, mais je n’ai pas trouvé d’informations publiques très claires après plusieurs tours. Peut-être qu’on est encore dans une phase très précoce et que les informations ne sont pas encore diffusées — mais pour l’instant, ce qu’on voit surtout, c’est que #dusk pousse déjà, tandis que les traces de participation de parties externes agréées ne sont pas évidentes.
Je ne tranche pas pour l’instant en annonçant un verdict négatif, mais je vais continuer à surveiller deux signaux clés : le déploiement de LP agréés externes, et le lancement officiel du JS SDK. Tant que je ne vois pas ces deux changements, le « KYC réutilisable à vie » a encore un long chemin à parcourir @Dusk .
L’ensemble du processus, en résumé, se déroule comme suit : l’utilisateur passe par un LP pour effectuer une vérification d’identité hors ligne, obtient ensuite un jeton chiffré enregistré on-chain, puis lorsqu’il accède aux différentes applications par la suite, il prouve sa conformité via des preuves ZK, sans avoir à exposer d’informations privées.
Au début, je pensais que tant qu’on fait une fois un KYC et qu’on obtient un jeton, on pourrait l’utiliser partout. Mais en poussant la logique du protocole de Citadel plus loin, j’ai trouvé un détail clé : le Service Provider a le droit de décider lui-même à quels License Provider il fait confiance.
Citadel n’impose pas que tous les SP acceptent la même norme de justificatifs. Par exemple : dans le cadre du business A, on fait confiance aux LP de ce choix ; dans le business B, on peut ne pas les accepter. Si tu as fait ton KYC dans le business A et que le business B n’accepte pas les justificatifs émis par ce LP, il faut recommencer. Le périmètre de réutilisation d’un « KYC une fois pour toutes » est donc naturellement limité à un « petit cercle » où l’on se reconnaît mutuellement un même ensemble de LP. En dehors de ce cercle, la réutilisation ne fonctionne plus $BTR .
Je voulais voir à quoi ressemblait la documentation d’intégration pour les institutions. En parcourant, j’ai bien vu que le W3sper SDK existe, mais je n’ai pas trouvé une version suffisamment complète pour les guides d’intégration au niveau institutionnel ni pour les solutions de gestion des permissions. Peut-être que je ne suis pas allé au bon endroit, mais au moins via les canaux publics, il semble que pour qu’une institution s’y connecte directement, les barrières d’entrée ne sont pas faibles.
Faisons une comparaison avec l’eIDAS de l’Union européenne : dans le monde réel, la reconnaissance mutuelle des identités avance déjà depuis longtemps, même si ce n’est pas basé sur ZK. La démarche technique de Citadel ne pose pas de problème, mais le protocole d’identité dépend énormément des effets de réseau. Pour que le système tourne, il faut beaucoup de LP agréés, et il faut aussi que divers SP de services acceptent ces justificatifs. J’ai essayé de chercher des exemples de LP agréés externes déjà déployés, mais je n’ai pas trouvé d’informations publiques très claires après plusieurs tours. Peut-être qu’on est encore dans une phase très précoce et que les informations ne sont pas encore diffusées — mais pour l’instant, ce qu’on voit surtout, c’est que #dusk pousse déjà, tandis que les traces de participation de parties externes agréées ne sont pas évidentes.
Je ne tranche pas pour l’instant en annonçant un verdict négatif, mais je vais continuer à surveiller deux signaux clés : le déploiement de LP agréés externes, et le lancement officiel du JS SDK. Tant que je ne vois pas ces deux changements, le « KYC réutilisable à vie » a encore un long chemin à parcourir @Dusk .