#dusk $DUSK @Dusk Passei um tempo na documentação do Citadel de Dusk e encontrei um detalhe no artigo acadêmico que a descrição de marketing de identidade auto-soberana nunca menciona.
O mecanismo de revogação.
Citadel é descrito como um sistema de identidade auto-soberana. Os usuários gerenciam suas próprias credenciais. Prove atributos sem revelá-los. Faixa etária. Residência. Status de acreditação. A prova de conhecimento zero significa que o provedor de serviço aprende apenas que você atende aos requisitos. Nada mais.
Essa parte é real e genuinamente bem projetada.
Então encontrei esta linha no artigo do Citadel.
"Se, em algumas circunstâncias, o SP deixar de aceitar algumas licenças emitidas anteriormente, eles podem provar à rede que uma determinada nota não é mais válida."
O Provedor de Serviço inicia a revogação. Não o usuário.
Hmmmm Identidade auto-soberana normalmente implica que o usuário controla suas credenciais. O modelo de revogação do Citadel inverte esse controle. O SP decide quando uma licença deixa de ser válida e prova isso para a rede. A rede aceita a revogação. A licença do usuário deixa de funcionar.
Em uma cadeia de privacidade em que as notas de licença são armazenadas de forma privada, o usuário não tem visibilidade on-chain sobre se sua licença foi revogada até tentar usá-la e ela falhar.
O artigo do Citadel lista três partes: o usuário, o provedor de serviço e o contrato da licença. O contrato da licença impõe a validade. O SP controla o que significa validade.
A documentação descreve isso como conformidade programável. A UE pode programar regulamentos dentro do próprio Citadel. Esse enquadramento faz a revogação soar como uma ferramenta regulatória.
Ela também é uma ferramenta administrativa. O mesmo mecanismo que permite a um regulador revogar o acesso de um usuário sancionado permite que qualquer SP revogue qualquer usuário por qualquer motivo.
Qual recurso existe após a revogação e quem arbitra as revogações contestadas é a pergunta que a documentação não responde.