Je suis allé chercher la citadelle en m’attendant à l’ancien papier d’identité auto-souveraine, et j’ai découvert qu’elle avait en fait été reconstruite en Citadel 2.
iLe flux est le suivant : un utilisateur demande à un fournisseur de licence une accréditation, le fournisseur les vérifie hors chaîne et signe les attributs pertinents, puis enregistre une licence chiffrée dans un contrat de citadelle.. Plus tard, lorsque l’utilisateur veut accéder à un service, il génère une preuve de connaissance zéro montrant qu’il possède une licence enregistrée valide sans révéler laquelle.
Le contrat vérifie cela et enregistre une session publique, et l’utilisateur.
remet un cookie de session au fournisseur de service.
six choses spécifiques ne touchent jamais la chaîne : la clé du portefeuille, quelle licence a été utilisée, la clé du fournisseur de licence (lp), la clé du fournisseur de service (sp), les attributs signés et le chemin de preuve Merkle.....
Ce qui est intéressant, c’est que Citadel ne prouve que que la session est valablement valide de façon cryptographique ; il ne décide pas de la politique. La documentation est explicite : le sp décide quels fournisseurs de licence faire confiance et si une session est expirée ou.
révoquée ; cette autorité reste entièrement au sp.
Ce que la documentation ne précise pas, c’est comment un sp pourrait cibler une licence compromise spécifique pour la révocation, puisque la session elle-même ne révèle jamais laquelle
licence la sous-tendait au départ...
Si vous étiez un sp, construiriez-vous une révocation autour des identifiants de session plutôt que de l’identité de la licence, puisque la licence ne se révèle jamais en tant que telle ??
#dusk @Dusk $DUSK
iLe flux est le suivant : un utilisateur demande à un fournisseur de licence une accréditation, le fournisseur les vérifie hors chaîne et signe les attributs pertinents, puis enregistre une licence chiffrée dans un contrat de citadelle.. Plus tard, lorsque l’utilisateur veut accéder à un service, il génère une preuve de connaissance zéro montrant qu’il possède une licence enregistrée valide sans révéler laquelle.
Le contrat vérifie cela et enregistre une session publique, et l’utilisateur.
remet un cookie de session au fournisseur de service.
six choses spécifiques ne touchent jamais la chaîne : la clé du portefeuille, quelle licence a été utilisée, la clé du fournisseur de licence (lp), la clé du fournisseur de service (sp), les attributs signés et le chemin de preuve Merkle.....
Ce qui est intéressant, c’est que Citadel ne prouve que que la session est valablement valide de façon cryptographique ; il ne décide pas de la politique. La documentation est explicite : le sp décide quels fournisseurs de licence faire confiance et si une session est expirée ou.
révoquée ; cette autorité reste entièrement au sp.
Ce que la documentation ne précise pas, c’est comment un sp pourrait cibler une licence compromise spécifique pour la révocation, puisque la session elle-même ne révèle jamais laquelle
licence la sous-tendait au départ...
Si vous étiez un sp, construiriez-vous une révocation autour des identifiants de session plutôt que de l’identité de la licence, puisque la licence ne se révèle jamais en tant que telle ??
#dusk @Dusk $DUSK
