@Dusk_Foundation
Ich hatte erwartet, dass KYC „on-chain“ ungefähr so funktioniert wie anderswo.
Reiche deine Identität einmal pro Dienst ein, und dieser Dienst hält nun eine Kopie davon, wer du bist.
Citadel hat mich umdenken lassen.
Ein Nutzer wird einmal durch einen License Provider verifiziert, der eine Lizenz ausstellt. Von dort aus kann ein Service Provider prüfen, ob diese Lizenz gültig ist, ohne die Identität dahinter zu sehen.
Ich hatte mir etwas vorgestellt, das näher an einem Passwort-Manager ist. Eine einzige Anmeldedaten-Quelle, überall wiederverwendet, bleibt jedes Mal als zu derselben Person gehörig erkennbar, wenn jemand sie überprüft.
So ist es aber nicht.
Wenn zwei verschiedene Dienste die Lizenz derselben Person prüfen, können sie nicht erkennen, dass sie dieselbe Person ansehen. Jede Verifizierung ist nicht miteinander verknüpfbar, auch wenn dieselbe zugrunde liegende Lizenz geprüft wird.
Die spannende Aussage ist also nicht einfach „deine Daten bleiben privat“.
Sondern: Wiederholte Compliance-Checks müssen nicht zwangsläufig eine Spur erzeugen, die diese Prüfungen miteinander verbindet.
Das verändert die Abwägung.
Unabhängiges KYC bei jedem Dienst ist repetitiv und teuer, aber jeder Dienst kontrolliert seine eigene Verifizierung. Citadel schafft diese Wiederholung ab, indem der License Provider die Partei ist, die die ursprüngliche Lizenz festlegt.
Auch die Wiederherstellung folgt dieser Architektur: Die Wallet aus ihrer Seed-Phrase wiederherzustellen, reicht aus, um die Lizenzen wiederherzustellen, ohne dass der Nutzer ein separates Lizenz-Backup pflegen muss.
Das Erlebnis im weiteren Verlauf wird einfacher und zugleich privater.
Aber die Vertrauensfrage verlagert sich nach oben.
Was ich immer noch nicht weiß, ist, wie ein License Provider überhaupt zu dieser Rolle kommt – oder ob die Compliance-Verpflichtung, die früher bei jedem einzelnen Dienst lag, wirklich verschwunden ist, oder einfach nur um eine Ebene nach oben gewandert ist.
$DUSK wird für mich hier erst interessant, wenn ich verstehe, wer ein License Provider werden kann und was diese Rolle daran hindert, zum neuen zentralen Single Point of Failure zu werden.
#dusk
Ich hatte erwartet, dass KYC „on-chain“ ungefähr so funktioniert wie anderswo.
Reiche deine Identität einmal pro Dienst ein, und dieser Dienst hält nun eine Kopie davon, wer du bist.
Citadel hat mich umdenken lassen.
Ein Nutzer wird einmal durch einen License Provider verifiziert, der eine Lizenz ausstellt. Von dort aus kann ein Service Provider prüfen, ob diese Lizenz gültig ist, ohne die Identität dahinter zu sehen.
Ich hatte mir etwas vorgestellt, das näher an einem Passwort-Manager ist. Eine einzige Anmeldedaten-Quelle, überall wiederverwendet, bleibt jedes Mal als zu derselben Person gehörig erkennbar, wenn jemand sie überprüft.
So ist es aber nicht.
Wenn zwei verschiedene Dienste die Lizenz derselben Person prüfen, können sie nicht erkennen, dass sie dieselbe Person ansehen. Jede Verifizierung ist nicht miteinander verknüpfbar, auch wenn dieselbe zugrunde liegende Lizenz geprüft wird.
Die spannende Aussage ist also nicht einfach „deine Daten bleiben privat“.
Sondern: Wiederholte Compliance-Checks müssen nicht zwangsläufig eine Spur erzeugen, die diese Prüfungen miteinander verbindet.
Das verändert die Abwägung.
Unabhängiges KYC bei jedem Dienst ist repetitiv und teuer, aber jeder Dienst kontrolliert seine eigene Verifizierung. Citadel schafft diese Wiederholung ab, indem der License Provider die Partei ist, die die ursprüngliche Lizenz festlegt.
Auch die Wiederherstellung folgt dieser Architektur: Die Wallet aus ihrer Seed-Phrase wiederherzustellen, reicht aus, um die Lizenzen wiederherzustellen, ohne dass der Nutzer ein separates Lizenz-Backup pflegen muss.
Das Erlebnis im weiteren Verlauf wird einfacher und zugleich privater.
Aber die Vertrauensfrage verlagert sich nach oben.
Was ich immer noch nicht weiß, ist, wie ein License Provider überhaupt zu dieser Rolle kommt – oder ob die Compliance-Verpflichtung, die früher bei jedem einzelnen Dienst lag, wirklich verschwunden ist, oder einfach nur um eine Ebene nach oben gewandert ist.
$DUSK wird für mich hier erst interessant, wenn ich verstehe, wer ein License Provider werden kann und was diese Rolle daran hindert, zum neuen zentralen Single Point of Failure zu werden.
#dusk