J’ai trouvé une frontière étrange dans Citadel 2 : la preuve à connaissance nulle peut être valide et l’utilisateur peut quand même être refusé.
Le flux est plus strict que « prouver son identité, obtenir l’accès ». Un fournisseur de licence vérifie l’utilisateur hors chaîne, signe les attributs pertinents, puis enregistre une licence chiffrée dans un contrat Citadel. Plus tard, l’utilisateur prouve qu’il possède une licence signée par le fournisseur, enregistrée, sans mettre sur la chaîne les détails personnels ni le texte exact de la licence. Citadel vérifie la preuve et consigne une session publique.
Mais cette session n’est pas une autorisation. Le fournisseur de service doit encore décider quels fournisseurs de licences il considère comme dignes de confiance, si l’attribut divulgué satisfait à sa règle, si la session est expirée ou révoquée, et si le cookie peut être réutilisé.
C’est ce découpage que je continue d’observer. Si je construis un service réglementé sur Dusk, la cryptographie prouve le chemin d’obtention des identifiants. Ma politique conserve la décision finale d’accès. Une session périmée ou à tort jugée digne de confiance devrait mourir à cette frontière, et ne pas devenir un passage qui « a l’air » valide.
Le point de pression est simple : quand la politique change plus vite que les identifiants, le service rejette-t-il la bonne session avant d’accorder l’accès ?
#dusk $DUSK @Dusk
#USJulyCPI&PPIDueThisWeek
Le flux est plus strict que « prouver son identité, obtenir l’accès ». Un fournisseur de licence vérifie l’utilisateur hors chaîne, signe les attributs pertinents, puis enregistre une licence chiffrée dans un contrat Citadel. Plus tard, l’utilisateur prouve qu’il possède une licence signée par le fournisseur, enregistrée, sans mettre sur la chaîne les détails personnels ni le texte exact de la licence. Citadel vérifie la preuve et consigne une session publique.
Mais cette session n’est pas une autorisation. Le fournisseur de service doit encore décider quels fournisseurs de licences il considère comme dignes de confiance, si l’attribut divulgué satisfait à sa règle, si la session est expirée ou révoquée, et si le cookie peut être réutilisé.
C’est ce découpage que je continue d’observer. Si je construis un service réglementé sur Dusk, la cryptographie prouve le chemin d’obtention des identifiants. Ma politique conserve la décision finale d’accès. Une session périmée ou à tort jugée digne de confiance devrait mourir à cette frontière, et ne pas devenir un passage qui « a l’air » valide.
Le point de pression est simple : quand la politique change plus vite que les identifiants, le service rejette-t-il la bonne session avant d’accorder l’accès ?
#dusk $DUSK @Dusk
#USJulyCPI&PPIDueThisWeek