Was meine Aufmerksamkeit erregt hat, ist, dass Dusks Datenschutzmodell ein Autorisierungsereignis sichtbar machen kann, während die Identitätsnachweise, die dahinterstehen, verborgen bleiben.
In Citadel 2 weist eine Nutzerin/ein Nutzer mit Zero-Knowledge nach, dass sie/er über eine registrierte, vom Anbieter signierte Berechtigung verfügt. Der Vertrag überprüft den Nachweis und protokolliert eine öffentliche Sitzung. Aber Dusks Dokumentation sagt, dass diese Sitzung keinen Wallet-Schlüssel, die verwendete konkrete Lizenz, den Lizenzanbieter-Schlüssel, den Serviceanbieter-Schlüssel, signierte Attribute oder den Merkle-Proof-Pfad offenlegt.
Das ist eine interessantere Designentscheidung als einfach nur „private KYC“ zu sagen.
Ich hatte erwartet, dass die Blockchain selbst entscheidet, ob eine Nutzerin/ein Nutzer konform ist. Das tut sie nicht. Citadel zeigt, dass das Berechtigungs-/Sitzungs-Setup kryptografisch gültig ist; der Serviceanbieter entscheidet weiterhin, welchen Berechtigungs-Ausstellern er vertraut, welche Attribute seiner Richtlinie genügen, ob eine Sitzung abgelaufen oder widerrufen ist, und ob ein Sitzungscookie wiederverwendet werden kann.
Für mich ist diese Trennung für Finanzanwendungen entscheidend. Der Datenschutz wird vom Proof-System übernommen, während Geschäfts- und regulatorische Richtlinien auf der Anwendungsebene konfigurierbar bleiben, statt in einer einzigen universellen Regel eingefroren zu werden.
Das schafft auch einen echten Zielkonflikt: Flexibilität ist nützlich, aber Sicherheit hängt davon ab, dass Serviceanbieter diese Richtlinien korrekt definieren.
Bei dusk_foundation und DUSK ist der Teil, den ich beobachte, nicht nur, ob Berechtigungen privat bleiben, sondern wie konsistent reale Anwendungen die Policy-Ebene um sie herum implementieren.
@Dusk $DUSK #dusk
In Citadel 2 weist eine Nutzerin/ein Nutzer mit Zero-Knowledge nach, dass sie/er über eine registrierte, vom Anbieter signierte Berechtigung verfügt. Der Vertrag überprüft den Nachweis und protokolliert eine öffentliche Sitzung. Aber Dusks Dokumentation sagt, dass diese Sitzung keinen Wallet-Schlüssel, die verwendete konkrete Lizenz, den Lizenzanbieter-Schlüssel, den Serviceanbieter-Schlüssel, signierte Attribute oder den Merkle-Proof-Pfad offenlegt.
Das ist eine interessantere Designentscheidung als einfach nur „private KYC“ zu sagen.
Ich hatte erwartet, dass die Blockchain selbst entscheidet, ob eine Nutzerin/ein Nutzer konform ist. Das tut sie nicht. Citadel zeigt, dass das Berechtigungs-/Sitzungs-Setup kryptografisch gültig ist; der Serviceanbieter entscheidet weiterhin, welchen Berechtigungs-Ausstellern er vertraut, welche Attribute seiner Richtlinie genügen, ob eine Sitzung abgelaufen oder widerrufen ist, und ob ein Sitzungscookie wiederverwendet werden kann.
Für mich ist diese Trennung für Finanzanwendungen entscheidend. Der Datenschutz wird vom Proof-System übernommen, während Geschäfts- und regulatorische Richtlinien auf der Anwendungsebene konfigurierbar bleiben, statt in einer einzigen universellen Regel eingefroren zu werden.
Das schafft auch einen echten Zielkonflikt: Flexibilität ist nützlich, aber Sicherheit hängt davon ab, dass Serviceanbieter diese Richtlinien korrekt definieren.
Bei dusk_foundation und DUSK ist der Teil, den ich beobachte, nicht nur, ob Berechtigungen privat bleiben, sondern wie konsistent reale Anwendungen die Policy-Ebene um sie herum implementieren.
@Dusk $DUSK #dusk
