Je pensais autrefois qu’une fois qu’une blockchain peut prouver qu’une personne détient un identifiant (credential) valide, la décision d’accès est essentiellement terminée.
En lisant à propos de Citadel 2 sur @Dusk, j’ai réalisé que ce sont en fait deux questions distinctes.
Citadel 2 permet à un utilisateur de générer une preuve de connaissance zéro montrant qu’il possède une licence enregistrée et signée par un License Provider, sans révéler quelle licence spécifique est utilisée. Le contrat Citadel vérifie la preuve et enregistre une session publique.
Mais une session valide sur le plan cryptographique ne signifie pas automatiquement que l’accès doit être accordé.
La documentation de Dusk fait cette distinction explicitement. Le Service Provider décide toujours quels License Providers il accepte, quels attributs il prend en compte, si la session est expirée ou révoquée, et si le cookie de session peut être réutilisé.
Cette séparation a changé la façon dont je pense l’identité numérique.
Le protocole peut vérifier la validité cryptographique d’une session tout en laissant la politique de service au Service Provider.
Pour moi, cela implique une limite importante : prouver qu’une session basée sur des identifiants est valide n’est pas la même chose que décider si cette preuve satisfait les exigences d’un service particulier.
Alors, peut-être que la meilleure question liée à l’identité n’est pas simplement de savoir si un utilisateur peut prouver quelque chose à propos de ses identifiants.
C’est plutôt : que doit vérifier la cryptographie, et qu’est-ce qui doit rester une décision de politique pour le service qui utilise cette preuve ?
Pour moi, cette distinction fait partie des idées les plus intéressantes derrière Citadel 2.
$DUSK #dusk @Dusk
En lisant à propos de Citadel 2 sur @Dusk, j’ai réalisé que ce sont en fait deux questions distinctes.
Citadel 2 permet à un utilisateur de générer une preuve de connaissance zéro montrant qu’il possède une licence enregistrée et signée par un License Provider, sans révéler quelle licence spécifique est utilisée. Le contrat Citadel vérifie la preuve et enregistre une session publique.
Mais une session valide sur le plan cryptographique ne signifie pas automatiquement que l’accès doit être accordé.
La documentation de Dusk fait cette distinction explicitement. Le Service Provider décide toujours quels License Providers il accepte, quels attributs il prend en compte, si la session est expirée ou révoquée, et si le cookie de session peut être réutilisé.
Cette séparation a changé la façon dont je pense l’identité numérique.
Le protocole peut vérifier la validité cryptographique d’une session tout en laissant la politique de service au Service Provider.
Pour moi, cela implique une limite importante : prouver qu’une session basée sur des identifiants est valide n’est pas la même chose que décider si cette preuve satisfait les exigences d’un service particulier.
Alors, peut-être que la meilleure question liée à l’identité n’est pas simplement de savoir si un utilisateur peut prouver quelque chose à propos de ses identifiants.
C’est plutôt : que doit vérifier la cryptographie, et qu’est-ce qui doit rester une décision de politique pour le service qui utilise cette preuve ?
Pour moi, cette distinction fait partie des idées les plus intéressantes derrière Citadel 2.
$DUSK #dusk @Dusk
