#dusk $DUSK @Dusk
J'ai comparé deux générations de la propre documentation de Citadel sous $DUSK #dusk @Dusk et j'ai constaté un changement que je n’attendais pas. Le design original de 2023 décrit la révocation de licence comme imposée par le réseau : un SP prouve qu’une licence doit être retirée, et, avec l’accord du 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é 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 autoriser ou refuser l’accès. L’existence est prouvée sur la chaîne. La décision réelle se lit comme étant du côté du SP.
Ce qui a changé pour moi : je pensais que la nouvelle génération pousserait davantage du 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 mise en contexte du README, pas le document complet du protocole, donc je ne parle pas d’une régression, seulement d’une différence de formulation entre les versions que je n’avais pas anticipée.
Cela vaut la peine d’être vérifié directement : si la spécification du protocole de Citadel 2 implémente encore une révocation basée sur le consensus comme dans l’article original, ou si la politique propre du SP est désormais la porte finale réelle d’accès.
J'ai comparé deux générations de la propre documentation de Citadel sous $DUSK #dusk @Dusk et j'ai constaté un changement que je n’attendais pas. Le design original de 2023 décrit la révocation de licence comme imposée par le réseau : un SP prouve qu’une licence doit être retirée, et, avec l’accord du 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é 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 autoriser ou refuser l’accès. L’existence est prouvée sur la chaîne. La décision réelle se lit comme étant du côté du SP.
Ce qui a changé pour moi : je pensais que la nouvelle génération pousserait davantage du 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 mise en contexte du README, pas le document complet du protocole, donc je ne parle pas d’une régression, seulement d’une différence de formulation entre les versions que je n’avais pas anticipée.
Cela vaut la peine d’être vérifié directement : si la spécification du protocole de Citadel 2 implémente encore une révocation basée sur le consensus comme dans l’article original, ou si la politique propre du SP est désormais la porte finale réelle d’accès.
