Observar $DUSK do Citadel2, “fazer um KYC uma vez e reutilizar em qualquer lugar” foi um ponto que realmente me deixou atento. Passei um tempo acalmando a mente para ler a documentação e os repositórios de código e só então descobri que aqui estão enterradas algumas premissas.
No geral, todo o fluxo é assim: o usuário faz a verificação de identidade presencial por meio do LP, obtém credenciais criptografadas na cadeia; depois, ao acessar diferentes aplicativos, ele prova sua conformidade com ZK, sem precisar expor informações privadas.
No começo, pensei que bastava fazer um KYC, receber as credenciais e pronto: daria para usar em todo lugar. Mas seguindo a lógica do protocolo do Citadel, cheguei a um detalhe-chave: o Service Provider tem o direito de decidir por conta própria quais License Providers ele confia.
O Citadel em si não exige que todos os SPs aceitem o mesmo padrão de credenciais. Por exemplo: o negócio A confia nos LPs que ele usa, enquanto o negócio B pode não reconhecer. Se você fez o KYC no negócio A, mas o negócio B não aceita as credenciais emitidas por aquele LP, você tem que refazer tudo. O escopo da “reutilização do KYC” fica naturalmente limitado a “um pequeno círculo em que todos reconhecem a mesma remessa de LPs”. Sai desse círculo, a reutilização falha $BTR
Eu queria ver como estava a documentação de integração para instituições. Dei uma olhada por alto e o W3sper SDK até existe, mas em termos de um guia de integração em nível institucional e um plano de gerenciamento de permissões, não encontrei uma versão suficientemente completa. Pode ser também que eu não tenha procurado no lugar certo, mas pelo menos pelos canais públicos, parece que a porta para uma instituição entrar diretamente não é tão baixa.
Vamos comparar com o eIDAS da União Europeia: no mundo real, a interoperabilidade de identidades já vinha sendo avançada há tempo, só que não depende de ZK. A ideia técnica do Citadel está ok, mas o protocolo de identidade depende muito de efeito de rede. Para esse sistema funcionar, é preciso haver muitos LPs licenciados, e que diversos SPs de diferentes negócios estejam dispostos a aceitar essas credenciais. Eu tentei procurar casos de LPs licenciados externos já implementados, mas depois de vasculhar, não achei informações públicas bem claras. Talvez ainda esteja no estágio inicial, e a informação ainda não tenha se espalhado; mas ao menos agora, o que dá para ver é que ainda é basicamente #dusk empurrando sozinho, sem sinais muito evidentes de participação de terceiros licenciados.
Por enquanto, não vou tirar uma conclusão negativa, mas vou acompanhar continuamente dois sinais-chave: a implementação de LPs licenciados externos e o lançamento oficial do JS SDK. Sem ver essas duas mudanças, a “reutilização vitalícia do KYC” ainda tem um longo caminho a percorrer @Dusk .
No geral, todo o fluxo é assim: o usuário faz a verificação de identidade presencial por meio do LP, obtém credenciais criptografadas na cadeia; depois, ao acessar diferentes aplicativos, ele prova sua conformidade com ZK, sem precisar expor informações privadas.
No começo, pensei que bastava fazer um KYC, receber as credenciais e pronto: daria para usar em todo lugar. Mas seguindo a lógica do protocolo do Citadel, cheguei a um detalhe-chave: o Service Provider tem o direito de decidir por conta própria quais License Providers ele confia.
O Citadel em si não exige que todos os SPs aceitem o mesmo padrão de credenciais. Por exemplo: o negócio A confia nos LPs que ele usa, enquanto o negócio B pode não reconhecer. Se você fez o KYC no negócio A, mas o negócio B não aceita as credenciais emitidas por aquele LP, você tem que refazer tudo. O escopo da “reutilização do KYC” fica naturalmente limitado a “um pequeno círculo em que todos reconhecem a mesma remessa de LPs”. Sai desse círculo, a reutilização falha $BTR
Eu queria ver como estava a documentação de integração para instituições. Dei uma olhada por alto e o W3sper SDK até existe, mas em termos de um guia de integração em nível institucional e um plano de gerenciamento de permissões, não encontrei uma versão suficientemente completa. Pode ser também que eu não tenha procurado no lugar certo, mas pelo menos pelos canais públicos, parece que a porta para uma instituição entrar diretamente não é tão baixa.
Vamos comparar com o eIDAS da União Europeia: no mundo real, a interoperabilidade de identidades já vinha sendo avançada há tempo, só que não depende de ZK. A ideia técnica do Citadel está ok, mas o protocolo de identidade depende muito de efeito de rede. Para esse sistema funcionar, é preciso haver muitos LPs licenciados, e que diversos SPs de diferentes negócios estejam dispostos a aceitar essas credenciais. Eu tentei procurar casos de LPs licenciados externos já implementados, mas depois de vasculhar, não achei informações públicas bem claras. Talvez ainda esteja no estágio inicial, e a informação ainda não tenha se espalhado; mas ao menos agora, o que dá para ver é que ainda é basicamente #dusk empurrando sozinho, sem sinais muito evidentes de participação de terceiros licenciados.
Por enquanto, não vou tirar uma conclusão negativa, mas vou acompanhar continuamente dois sinais-chave: a implementação de LPs licenciados externos e o lançamento oficial do JS SDK. Sem ver essas duas mudanças, a “reutilização vitalícia do KYC” ainda tem um longo caminho a percorrer @Dusk .