$SPK $MORPHO $DUSK
Ich dachte früher, dass der Nachweis, dass du für etwas onchain berechtigt bist, bedeutet, dass du die Anmeldeinformationen offenlegst, die das belegen.
Citadel hat mich darüber neu nachdenken lassen.
Das Spannende ist nicht einfach, dass Dusk Zero-Knowledge-Beweise nutzt.
Sondern: Der Beweis kann eine konkrete Frage beantworten, ohne die zugrunde liegende Berechtigung herauszugeben.
Ein Lizenzanbieter stellt ein signiertes Zertifikat aus. Du kannst dann einen ZK-Beweis erzeugen, der zeigt, dass du die erforderliche Bedingung erfüllst, ohne das Zertifikat selbst offenzulegen.
So kann ein Dienstanbieter etwas prüfen wie:
Bist du lizenziert?
Bist du berechtigt?
Erfüllt dein Zertifikat die Anforderung?
Ohne das zugrunde liegende Dokument zu brauchen, nur um Ja oder Nein zu beantworten.
Aber es gibt hier noch eine zweite Ebene, die ich noch spannender finde.
Citadel entfernt keinen dem System innewohnenden Vertrauensaspekt. Es verlagert einen Teil dieses Vertrauens zum Aussteller der Berechtigung.
Der Dienstanbieter entscheidet, welche Lizenzanbieter er akzeptiert.
So kann die Datenschutzmechanik die Informationen verbergen, die du nicht offenlegen musst, während das Aussteller-Auswahlmodell festlegt, deren Aussagen überhaupt als vertrauenswürdig gelten.
Diese Unterscheidung ist wichtig für regulierte Finanzen.
Das Ziel ist nicht zwangsläufig, Identitätsprüfungen vertrauenslos zu machen.
Sondern: Verifikation selektiver zu gestalten.
Beweise die Bedingung.
Behalte den Rest privat.
Das lässt mich fragen:
Könnte das für regulierte Anwendungen ein besseres Modell werden als jedes Mal wiederholt das vollständige Identitätsdokument einzusammeln, nur weil die Berechtigung geprüft werden muss? 👀
#dusk @Dusk
Tan
Was sollten regulierte Apps prüfen? 👀
Ich dachte früher, dass der Nachweis, dass du für etwas onchain berechtigt bist, bedeutet, dass du die Anmeldeinformationen offenlegst, die das belegen.
Citadel hat mich darüber neu nachdenken lassen.
Das Spannende ist nicht einfach, dass Dusk Zero-Knowledge-Beweise nutzt.
Sondern: Der Beweis kann eine konkrete Frage beantworten, ohne die zugrunde liegende Berechtigung herauszugeben.
Ein Lizenzanbieter stellt ein signiertes Zertifikat aus. Du kannst dann einen ZK-Beweis erzeugen, der zeigt, dass du die erforderliche Bedingung erfüllst, ohne das Zertifikat selbst offenzulegen.
So kann ein Dienstanbieter etwas prüfen wie:
Bist du lizenziert?
Bist du berechtigt?
Erfüllt dein Zertifikat die Anforderung?
Ohne das zugrunde liegende Dokument zu brauchen, nur um Ja oder Nein zu beantworten.
Aber es gibt hier noch eine zweite Ebene, die ich noch spannender finde.
Citadel entfernt keinen dem System innewohnenden Vertrauensaspekt. Es verlagert einen Teil dieses Vertrauens zum Aussteller der Berechtigung.
Der Dienstanbieter entscheidet, welche Lizenzanbieter er akzeptiert.
So kann die Datenschutzmechanik die Informationen verbergen, die du nicht offenlegen musst, während das Aussteller-Auswahlmodell festlegt, deren Aussagen überhaupt als vertrauenswürdig gelten.
Diese Unterscheidung ist wichtig für regulierte Finanzen.
Das Ziel ist nicht zwangsläufig, Identitätsprüfungen vertrauenslos zu machen.
Sondern: Verifikation selektiver zu gestalten.
Beweise die Bedingung.
Behalte den Rest privat.
Das lässt mich fragen:
Könnte das für regulierte Anwendungen ein besseres Modell werden als jedes Mal wiederholt das vollständige Identitätsdokument einzusammeln, nur weil die Berechtigung geprüft werden muss? 👀
#dusk @Dusk
Tan
Was sollten regulierte Apps prüfen? 👀
✨ Only what’s required
0%
🔒 The full credential
0%
⚡ Depends on the use case
0%
👁️ Both, when needed
0%
0 Stimmen • Abstimmung beendet