Fui procurar a Citadel esperando o antigo documento de identidade soberana self-sovereign identity paper e encontrei que ele na verdade foi reconstruído na Citadel 2.
o fluxo é assim: um usuário solicita a um provedor de licenças um credential, o provedor verifica isso fora da cadeia (off-chain) e assina os atributos relevantes; em seguida, registra uma licença criptografada em um contrato da Citadel.. mais tarde, quando o.
usuário quer acesso a um serviço, ele gera uma prova de conhecimento zero mostrando que possui uma licença registrada válida sem revelar qual é ela. o contrato verifica isso e registra uma sessão pública, e o usuário.
entrega um cookie de sessão ao provedor do serviço.
seis coisas específicas nunca tocam a cadeia, a chave da wallet, qual licença foi usada, a chave do lp, a chave do sp, os atributos assinados e o caminho da prova de Merkle.....
o que é interessante é que a Citadel só prova que a sessão é criptograficamente válida; ela não decide política. a documentação é explícita ao dizer que o sp decide quais provedores de licenças confiar e se uma sessão está expirada ou.
revogada: essa autoridade fica totalmente com o sp.
o que os docs não explicam é como um sp miraria uma única licença comprometida para revogação, já que a sessão em si nunca revela qual
licença ela embasou em primeiro lugar...
se você fosse um sp, criaria a revogação baseada em IDs de sessão em vez de identidade de licença, considerando que a licença nunca realmente aparece??
#dusk @Dusk $DUSK
o fluxo é assim: um usuário solicita a um provedor de licenças um credential, o provedor verifica isso fora da cadeia (off-chain) e assina os atributos relevantes; em seguida, registra uma licença criptografada em um contrato da Citadel.. mais tarde, quando o.
usuário quer acesso a um serviço, ele gera uma prova de conhecimento zero mostrando que possui uma licença registrada válida sem revelar qual é ela. o contrato verifica isso e registra uma sessão pública, e o usuário.
entrega um cookie de sessão ao provedor do serviço.
seis coisas específicas nunca tocam a cadeia, a chave da wallet, qual licença foi usada, a chave do lp, a chave do sp, os atributos assinados e o caminho da prova de Merkle.....
o que é interessante é que a Citadel só prova que a sessão é criptograficamente válida; ela não decide política. a documentação é explícita ao dizer que o sp decide quais provedores de licenças confiar e se uma sessão está expirada ou.
revogada: essa autoridade fica totalmente com o sp.
o que os docs não explicam é como um sp miraria uma única licença comprometida para revogação, já que a sessão em si nunca revela qual
licença ela embasou em primeiro lugar...
se você fosse um sp, criaria a revogação baseada em IDs de sessão em vez de identidade de licença, considerando que a licença nunca realmente aparece??
#dusk @Dusk $DUSK
