#dusk $DUSK @Dusk Com o serviço de provas de conhecimento zero, é preciso colocá-lo dentro? Ao ler a documentação do Citadel 2 do @Dusk , encontrei uma resposta diferente: o contrato do Citadel só se encarrega de verificar se a sessão é válida do ponto de vista criptográfico; quem realmente decide se você passa ou não continua sendo o Service Provider. Essa fronteira é fácil de ser apagada com uma frase como “não é necessário expor dados pessoais”: o usuário primeiro obtém as credenciais do License Provider e depois gera a prova, provando que possui uma licença já registrada e assinada por uma instituição confiável. A blockchain não mostra qual documento ele usou. Mas quando chega na entrada do serviço, o SP ainda precisa decidir em quem confiar (quais LPs), quais atributos aceitar, se a sessão expirou ou foi revogada, e até se o cookie pode ou não ser reutilizado.
Acho que isso torna o Citadel 2 mais honesto: ele não empacota “a prova é válida” como “o acesso é automaticamente concedido”; em vez disso, separa a verificação criptográfica da autorização de negócio em duas etapas. Para o usuário, há menos exposição de informações pessoais; para o provedor do serviço, as regras não desaparecem — apenas deixam de exigir a coleta de um conjunto inteiro de dados, passando a envolver a escolha de fontes confiáveis e a checagem do status da sessão. O cenário de pressão também é bem concreto: a prova do usuário está totalmente correta, mas o serviço nega o acesso porque não confia no LP que emitiu aquela licença ou porque identifica que a sessão já expirou. O usuário pode achar que houve um erro na blockchain, mas o SP entende que é apenas uma aplicação das próprias políticas. Se a página só mostrar “verificação falhou”, as duas partes não conseguem identificar onde está o ponto real de responsabilidade.
Então, ao olhar para o design de identidade do DUSK agora, eu não quero apenas saber quanto ele consegue esconder de atributos; eu quero ver se cada aplicação deixa claro a diferença entre “a prova é válida” e “o serviço libera a entrada”. O Citadel 2 do @Dusk de fato reduz a divulgação desnecessária de informações, mas não consegue fazer a aplicação decidir em quem confiar. No futuro, o mais importante a observar é se, quando o acesso for negado, o usuário consegue saber exatamente se o problema foi na prova, nas credenciais ou nas políticas do serviço. #dusk
Acho que isso torna o Citadel 2 mais honesto: ele não empacota “a prova é válida” como “o acesso é automaticamente concedido”; em vez disso, separa a verificação criptográfica da autorização de negócio em duas etapas. Para o usuário, há menos exposição de informações pessoais; para o provedor do serviço, as regras não desaparecem — apenas deixam de exigir a coleta de um conjunto inteiro de dados, passando a envolver a escolha de fontes confiáveis e a checagem do status da sessão. O cenário de pressão também é bem concreto: a prova do usuário está totalmente correta, mas o serviço nega o acesso porque não confia no LP que emitiu aquela licença ou porque identifica que a sessão já expirou. O usuário pode achar que houve um erro na blockchain, mas o SP entende que é apenas uma aplicação das próprias políticas. Se a página só mostrar “verificação falhou”, as duas partes não conseguem identificar onde está o ponto real de responsabilidade.
Então, ao olhar para o design de identidade do DUSK agora, eu não quero apenas saber quanto ele consegue esconder de atributos; eu quero ver se cada aplicação deixa claro a diferença entre “a prova é válida” e “o serviço libera a entrada”. O Citadel 2 do @Dusk de fato reduz a divulgação desnecessária de informações, mas não consegue fazer a aplicação decidir em quem confiar. No futuro, o mais importante a observar é se, quando o acesso for negado, o usuário consegue saber exatamente se o problema foi na prova, nas credenciais ou nas políticas do serviço. #dusk
