Ich habe gestern Abend die Dusk-Dokumentation durchgesehen und wollte herausfinden, wie „selektive Offenlegung“ in der Praxis überhaupt ausgelöst wird. Die Doku klingt ziemlich gut: Standardmäßig Privatsphäre, Offenlegung nur nach Bedarf, Aufsichtsfälle durch Zertifikate nachvollziehbar. Aber als ich im Kapitel zum Berechtigungsmanagement angekommen bin, bin ich stehen geblieben: Dort steht im Grunde nur, dass „der Autorisierende die Einsichtsschlüssel hält“, doch es steht nicht dabei, ob diese Autorisierung widerrufen werden kann, ob es eine Ablaufzeit gibt oder wer die autorisierenden Handlungen protokolliert.
Also bin ich kurzerhand ins Testnetz gegangen und habe es einmal ausprobiert: Ich habe eine Identität erstellt und die Einsichtsberechtigung an einen simulierten Prüfer autorisiert. Der Ablauf funktioniert — es sind vier Schritte: Autorisierungsschlüssel generieren, Transaktion einreichen, dass der andere es verifiziert. Insgesamt dauert es etwa zwei Minuten. Doch als ich danach die Autorisierungsaufzeichnungen geprüft habe, habe ich festgestellt: Das Widerrufen der Autorisierung ist in keiner Dokumentation beschrieben, und im Testnetz-Console gibt es auch keinen passenden Einstieg. Ein Schalter, der nur „an“ kann, aber kein „aus“, ist in Compliance-Szenarien gefährlich — wenn die Prüfberechtigung einmal erteilt wurde und sich nicht widerrufen lässt, wird „Offenlegung nach Bedarf“ im Ergebnis zu „einmal autorisiert, dauerhaft sichtbar“.
Dann habe ich auf GitHub den Smart-Contract-Code des Autorisierungsmoduls durchforstet: Ich habe nach „revoke“ und „expire“ gesucht — ohne Treffer. Vielleicht habe ich nicht den richtigen Repository-Zweig erwischt, oder diese Funktionen sind noch geplant. Aber als Nutzer kann ich eben nur anhand der vorhandenen Dokumentation und des vorhandenen Codes urteilen.
Später ist mir etwas klar geworden: Das ist kein spezifisches Problem von Dusk — sondern das gemeinsame Lernfeld für diesen Weg des „programmierbaren Datenschutzes“: Das Erteilen von Berechtigungen ist Kryptografie, das Widerrufen von Berechtigungen ist Governance. Das Erteilen kann man mit Mathematik hinkriegen, das Widerrufen nur mit Prozessen. Und die Prozesse fehlen derzeit in der Dokumentation.
Darum haben sich in meinem Testnet-Wallet ein paar hundert DUSK angesammelt, aber die Vermögenswerte im Mainnet lasse ich vorerst unangetastet. Ich warte, bis der offizielle Teil das Autorisierungsmanagement (Widerruf, Ablauf, Audit-Logs) in Dokumentation und Code schreibt — dann setze ich erst wirklich Geld ein. Bis dahin muss ich zugeben: „Selektive Offenlegung“ ist zwar ein guter Entwurf, aber ein Entwurf darf nicht nur eine „An“-Taste haben — ohne eine „Aus“-Taste.
@Dusk_Foundation $DUSK #dusk
Also bin ich kurzerhand ins Testnetz gegangen und habe es einmal ausprobiert: Ich habe eine Identität erstellt und die Einsichtsberechtigung an einen simulierten Prüfer autorisiert. Der Ablauf funktioniert — es sind vier Schritte: Autorisierungsschlüssel generieren, Transaktion einreichen, dass der andere es verifiziert. Insgesamt dauert es etwa zwei Minuten. Doch als ich danach die Autorisierungsaufzeichnungen geprüft habe, habe ich festgestellt: Das Widerrufen der Autorisierung ist in keiner Dokumentation beschrieben, und im Testnetz-Console gibt es auch keinen passenden Einstieg. Ein Schalter, der nur „an“ kann, aber kein „aus“, ist in Compliance-Szenarien gefährlich — wenn die Prüfberechtigung einmal erteilt wurde und sich nicht widerrufen lässt, wird „Offenlegung nach Bedarf“ im Ergebnis zu „einmal autorisiert, dauerhaft sichtbar“.
Dann habe ich auf GitHub den Smart-Contract-Code des Autorisierungsmoduls durchforstet: Ich habe nach „revoke“ und „expire“ gesucht — ohne Treffer. Vielleicht habe ich nicht den richtigen Repository-Zweig erwischt, oder diese Funktionen sind noch geplant. Aber als Nutzer kann ich eben nur anhand der vorhandenen Dokumentation und des vorhandenen Codes urteilen.
Später ist mir etwas klar geworden: Das ist kein spezifisches Problem von Dusk — sondern das gemeinsame Lernfeld für diesen Weg des „programmierbaren Datenschutzes“: Das Erteilen von Berechtigungen ist Kryptografie, das Widerrufen von Berechtigungen ist Governance. Das Erteilen kann man mit Mathematik hinkriegen, das Widerrufen nur mit Prozessen. Und die Prozesse fehlen derzeit in der Dokumentation.
Darum haben sich in meinem Testnet-Wallet ein paar hundert DUSK angesammelt, aber die Vermögenswerte im Mainnet lasse ich vorerst unangetastet. Ich warte, bis der offizielle Teil das Autorisierungsmanagement (Widerruf, Ablauf, Audit-Logs) in Dokumentation und Code schreibt — dann setze ich erst wirklich Geld ein. Bis dahin muss ich zugeben: „Selektive Offenlegung“ ist zwar ein guter Entwurf, aber ein Entwurf darf nicht nur eine „An“-Taste haben — ohne eine „Aus“-Taste.
@Dusk_Foundation $DUSK #dusk