Le mois dernier, je suis arrivé dans un hôtel après un vol tardif. La réceptionniste n’avait besoin que de vérifier que la réservation était bien à mon nom et que je respectais les exigences de l’établissement. Au lieu de cela, j’ai remis mon passeport, révélant mon nom complet, ma date de naissance, mon numéro de passeport, ma nationalité et plusieurs détails qui n’avaient rien à voir avec l’obtention d’une chambre.
C’est le même schéma auquel se heurte la crypto « réglementée ». Une plateforme peut n’avoir besoin de savoir que si une adresse (wallet) appartient à un participant éligible, ou si certaines vérifications de conformité ont été effectuées. Mais l’authentification d’identité traditionnelle prouve souvent l’éligibilité en révélant l’identité elle-même. Sur une blockchain publique, cela crée un compromis inconfortable entre conformité et confidentialité financière.
@Dusk_Foundation aborde ce sujet différemment avec Citadel 2. Un fournisseur de licence vérifie l’utilisateur hors chaîne, signe les attributs requis, chiffre la licence obtenue et l’enregistre auprès d’un contrat Citadel. Ensuite, l’utilisateur peut générer une preuve à connaissance zéro démontrant qu’il détient une licence valide signée par LP, sans révéler quelle licence précise a été utilisée. Après la vérification, le contrat crée une session publique, et l’utilisateur présente un cookie de session au fournisseur de services au lieu d’exposer l’identifiant sous-jacent.
Auto-critique : mais l’analogie avec l’hôtel révèle aussi la limite. Même si je pouvais prouver que j’étais un client éligible sans montrer mon passeport, l’hôtel décide quand même quels documents il accepte comme fiables, ce qui compte comme valable, quand l’autorisation expire et à quel moment l’accès doit être révoqué. Citadel 2 ne supprime pas cette couche de politique. Le fournisseur de services choisit toujours des fournisseurs de licences de confiance, les attributs acceptés, les règles d’expiration, les conditions de révocation, et la question de savoir si un cookie de session peut être réutilisé. La confidentialité peut réduire les divulgations inutiles, mais elle ne peut pas faire disparaître de mauvaises politiques d’admission.
$DUSK doit être évalué en fonction de la façon dont sa couche d’identité minimise la divulgation tout en gardant des politiques de confiance, de révocation, d’expiration et de crédits/identifiants (credentials) applicables, et pas uniquement sur le point de savoir s’il utilise des preuves à connaissance zéro.
#dusk $JCT $ON
C’est le même schéma auquel se heurte la crypto « réglementée ». Une plateforme peut n’avoir besoin de savoir que si une adresse (wallet) appartient à un participant éligible, ou si certaines vérifications de conformité ont été effectuées. Mais l’authentification d’identité traditionnelle prouve souvent l’éligibilité en révélant l’identité elle-même. Sur une blockchain publique, cela crée un compromis inconfortable entre conformité et confidentialité financière.
@Dusk_Foundation aborde ce sujet différemment avec Citadel 2. Un fournisseur de licence vérifie l’utilisateur hors chaîne, signe les attributs requis, chiffre la licence obtenue et l’enregistre auprès d’un contrat Citadel. Ensuite, l’utilisateur peut générer une preuve à connaissance zéro démontrant qu’il détient une licence valide signée par LP, sans révéler quelle licence précise a été utilisée. Après la vérification, le contrat crée une session publique, et l’utilisateur présente un cookie de session au fournisseur de services au lieu d’exposer l’identifiant sous-jacent.
Auto-critique : mais l’analogie avec l’hôtel révèle aussi la limite. Même si je pouvais prouver que j’étais un client éligible sans montrer mon passeport, l’hôtel décide quand même quels documents il accepte comme fiables, ce qui compte comme valable, quand l’autorisation expire et à quel moment l’accès doit être révoqué. Citadel 2 ne supprime pas cette couche de politique. Le fournisseur de services choisit toujours des fournisseurs de licences de confiance, les attributs acceptés, les règles d’expiration, les conditions de révocation, et la question de savoir si un cookie de session peut être réutilisé. La confidentialité peut réduire les divulgations inutiles, mais elle ne peut pas faire disparaître de mauvaises politiques d’admission.
$DUSK doit être évalué en fonction de la façon dont sa couche d’identité minimise la divulgation tout en gardant des politiques de confiance, de révocation, d’expiration et de crédits/identifiants (credentials) applicables, et pas uniquement sur le point de savoir s’il utilise des preuves à connaissance zéro.
#dusk $JCT $ON