Quando eu li Citadel 2, parei numa frase antes dela — não era longa: contratos on-chain só verificam a validade criptográfica de uma sessão. Se você deve ou não ter acesso, a decisão fica com o Service Provider.🤔
O usuário, com mil esforços, gera uma prova válida; a história ainda não acabou — e, de certo modo, está apenas começando.
Você pode provar que possui uma licença válida emitida por algum License Provider. Os dados nem precisam ser enviados para a blockchain; a proteção da privacidade é extremamente rígida. Mas o provedor de serviço ainda tem um monte de coisas para julgar por conta própria: em quem eu confio nesse LP? Quais atributos aceitar? A sessão expirou? Foi revogada? Este cookie ainda pode ser usado na segunda vez?
A privacidade é protegida, mas as políticas do negócio não vão decidir por você.
Como seria o cenário ruim?
O usuário gera a proof com sucesso e, na página, aparece uma mensagem: “Sem autorização para acessar.”
São só quatro palavras. Acabou.🥶
Aí o usuário começa a adivinhar: a prova falhou? o provedor não confia no emissor? ou os atributos não atendem às regras? Ele chuta, chuta de novo — e não faz ideia.
A privacidade realmente não vaza, mas o tempo se vai tentando resolver o enigma. Para o usuário, a privacidade fica preservada; a experiência, desaba.
Para o provedor de serviço, todas as recusas ficam escondidas atrás de um único código de erro, e nem as fronteiras de conformidade ficam explicadas.
Essa contenção, na verdade, é lucidez.
O valor do Citadel 2 está justamente nisso: ele prova que você tem credenciais adequadas, mas nunca finge que “você precisa de um serviço”.
A prova é sua; a decisão é do serviço. As duas coisas ficam bem separadas.
$DUSK quer usá-lo para um onboarding real; @Dusk deve incentivar o app a informar ao usuário separadamente quando a proof é válida e quando a policy é negada.
Foi a prova que não passou? Ou a prova passou, mas a política foi negada? Colocar tudo num único código simplifica; separar em dois é respeitar a capacidade de julgamento do usuário.
O usuário sabe em que camada travou; só assim a experiência de privacidade do #dusk fica completa.
Caso contrário, por melhor que seja a proteção da privacidade, o usuário só vai lembrar daquelas quatro palavras.🤷♂️
O usuário, com mil esforços, gera uma prova válida; a história ainda não acabou — e, de certo modo, está apenas começando.
Você pode provar que possui uma licença válida emitida por algum License Provider. Os dados nem precisam ser enviados para a blockchain; a proteção da privacidade é extremamente rígida. Mas o provedor de serviço ainda tem um monte de coisas para julgar por conta própria: em quem eu confio nesse LP? Quais atributos aceitar? A sessão expirou? Foi revogada? Este cookie ainda pode ser usado na segunda vez?
A privacidade é protegida, mas as políticas do negócio não vão decidir por você.
Como seria o cenário ruim?
O usuário gera a proof com sucesso e, na página, aparece uma mensagem: “Sem autorização para acessar.”
São só quatro palavras. Acabou.🥶
Aí o usuário começa a adivinhar: a prova falhou? o provedor não confia no emissor? ou os atributos não atendem às regras? Ele chuta, chuta de novo — e não faz ideia.
A privacidade realmente não vaza, mas o tempo se vai tentando resolver o enigma. Para o usuário, a privacidade fica preservada; a experiência, desaba.
Para o provedor de serviço, todas as recusas ficam escondidas atrás de um único código de erro, e nem as fronteiras de conformidade ficam explicadas.
Essa contenção, na verdade, é lucidez.
O valor do Citadel 2 está justamente nisso: ele prova que você tem credenciais adequadas, mas nunca finge que “você precisa de um serviço”.
A prova é sua; a decisão é do serviço. As duas coisas ficam bem separadas.
$DUSK quer usá-lo para um onboarding real; @Dusk deve incentivar o app a informar ao usuário separadamente quando a proof é válida e quando a policy é negada.
Foi a prova que não passou? Ou a prova passou, mas a política foi negada? Colocar tudo num único código simplifica; separar em dois é respeitar a capacidade de julgamento do usuário.
O usuário sabe em que camada travou; só assim a experiência de privacidade do #dusk fica completa.
Caso contrário, por melhor que seja a proteção da privacidade, o usuário só vai lembrar daquelas quatro palavras.🤷♂️
