Eu costumava assumir que, quando uma blockchain consegue provar que alguém possui uma credencial válida, a decisão de acesso estaria essencialmente encerrada.
Ao ler sobre o Citadel 2 no @Dusk, percebi que são, na verdade, duas questões separadas.
O Citadel 2 permite que um usuário gere uma prova de conhecimento zero mostrando que ele possui uma licença registrada e assinada por um License Provider, sem revelar qual licença específica está sendo usada. O contrato do Citadel verifica a prova e registra uma sessão pública.
Mas uma sessão criptograficamente válida não significa automaticamente que o acesso deva ser concedido.
A documentação do Dusk deixa essa distinção explícita. O Service Provider ainda decide em quais License Providers ele confia, quais atributos ele aceita, se a sessão está expirada ou revogada, e se o cookie da sessão pode ser reutilizado.
Essa separação mudou a forma como penso sobre identidade digital.
O protocolo pode verificar a validade criptográfica de uma sessão, enquanto deixa a política de serviço para o Service Provider.
Para mim, isso sugere um limite importante: provar que uma sessão baseada em credenciais é válida não é a mesma coisa que decidir se aquela prova atende aos requisitos de um serviço específico.
Então talvez a melhor pergunta sobre identidade não seja simplesmente se um usuário consegue provar algo sobre suas credenciais.
É: o que a criptografia deve verificar e o que deve permanecer como uma decisão de política para o serviço que utiliza essa prova?
Para mim, essa distinção é uma das ideias mais interessantes por trás do Citadel 2.
$DUSK #dusk @Dusk
Ao ler sobre o Citadel 2 no @Dusk, percebi que são, na verdade, duas questões separadas.
O Citadel 2 permite que um usuário gere uma prova de conhecimento zero mostrando que ele possui uma licença registrada e assinada por um License Provider, sem revelar qual licença específica está sendo usada. O contrato do Citadel verifica a prova e registra uma sessão pública.
Mas uma sessão criptograficamente válida não significa automaticamente que o acesso deva ser concedido.
A documentação do Dusk deixa essa distinção explícita. O Service Provider ainda decide em quais License Providers ele confia, quais atributos ele aceita, se a sessão está expirada ou revogada, e se o cookie da sessão pode ser reutilizado.
Essa separação mudou a forma como penso sobre identidade digital.
O protocolo pode verificar a validade criptográfica de uma sessão, enquanto deixa a política de serviço para o Service Provider.
Para mim, isso sugere um limite importante: provar que uma sessão baseada em credenciais é válida não é a mesma coisa que decidir se aquela prova atende aos requisitos de um serviço específico.
Então talvez a melhor pergunta sobre identidade não seja simplesmente se um usuário consegue provar algo sobre suas credenciais.
É: o que a criptografia deve verificar e o que deve permanecer como uma decisão de política para o serviço que utiliza essa prova?
Para mim, essa distinção é uma das ideias mais interessantes por trás do Citadel 2.
$DUSK #dusk @Dusk
