#dusk $DUSK @Dusk
J’ai comparé deux générations de la documentation interne de Citadel sous $DUSK #dusk @Dusk et j’ai constaté un changement que je n’avais pas anticipé. La conception originale de 2023 décrit la révocation de licence comme étant imposée par le réseau : un SP prouve qu’une licence doit être retirée, et, une fois l’accord obtenu au consensus, elle est supprimée de l’arbre de Merkle.
Le dépôt GitHub actuel — Citadel 2, la version reconstruite — décrit l’extrémité (endpoint) différemment. Un utilisateur prouve sur la chaîne qu’une licence existe, puis divulgue un cookie de session à un fournisseur de services (Service Provider) qui applique sa propre politique pour accorder ou refuser l’accès. L’existence est prouvée sur la chaîne. La décision réelle se lit comme provenant du côté du SP.
Ce qui a changé pour moi : je pensais que la génération plus récente pousserait davantage le processus sur la chaîne, pas moins. Il se peut que ce soit encore le cas ailleurs dans la spécification — je n’ai que la façon dont le README le présente, pas le document de protocole complet, donc je ne parle pas d’un recul, mais plutôt d’une différence dans la formulation entre les versions que je n’avais pas prévu de trouver.
À vérifier directement : si la spécification du protocole de Citadel 2 implémente encore une révocation basée sur le consensus comme le faisait l’article original, ou si la politique propre du SP constitue désormais la porte finale réelle d’accès.
J’ai comparé deux générations de la documentation interne de Citadel sous $DUSK #dusk @Dusk et j’ai constaté un changement que je n’avais pas anticipé. La conception originale de 2023 décrit la révocation de licence comme étant imposée par le réseau : un SP prouve qu’une licence doit être retirée, et, une fois l’accord obtenu au consensus, elle est supprimée de l’arbre de Merkle.
Le dépôt GitHub actuel — Citadel 2, la version reconstruite — décrit l’extrémité (endpoint) différemment. Un utilisateur prouve sur la chaîne qu’une licence existe, puis divulgue un cookie de session à un fournisseur de services (Service Provider) qui applique sa propre politique pour accorder ou refuser l’accès. L’existence est prouvée sur la chaîne. La décision réelle se lit comme provenant du côté du SP.
Ce qui a changé pour moi : je pensais que la génération plus récente pousserait davantage le processus sur la chaîne, pas moins. Il se peut que ce soit encore le cas ailleurs dans la spécification — je n’ai que la façon dont le README le présente, pas le document de protocole complet, donc je ne parle pas d’un recul, mais plutôt d’une différence dans la formulation entre les versions que je n’avais pas prévu de trouver.
À vérifier directement : si la spécification du protocole de Citadel 2 implémente encore une révocation basée sur le consensus comme le faisait l’article original, ou si la politique propre du SP constitue désormais la porte finale réelle d’accès.
