Es gibt etwas, zu dem ich immer wieder zurückkehre, wenn ich mich mit @Dusk l auseinandersetze: Ist Compliance wirklich so etwas wie ein Trade-off mit Privacy wert – und dass ein Großteil der Design-Logik darin liegt, dass Citadel 2 „Nachweis erbracht/überprüft“ von „Offenlegung der Person hinter der Identität“ trennt.

Der Ablauf beginnt damit, dass der License Provider den Nutzer off-chain überprüft und die notwendigen Attribute signiert.

Ab dann erstellt der Nutzer einen Zero-Knowledge-Proof, um zu beweisen, dass er eine gültige, signierte und on-chain registrierte License besitzt – das ist der Teil, der mich am meisten interessiert.

Der Proof läuft über Kryptografie ab, ohne Wallet-Schlüssel, Attribute oder die konkrete License offenzulegen, und hier wird die Frage nach Privacy wirklich überprüft.

Die Service-Policy ist stets „im Hintergrund“ vorhanden: Sie wartet darauf, dass der Service Provider entscheidet, welchem Provider man vertraut, welche Attribute akzeptiert werden und ob die Session noch gültig ist.

Am Ende bestätigt der Contract lediglich den gültigen Proof und protokolliert eine öffentliche Session. On-chain bleibt nur noch der Nachweis, dass ein gültiges Credential verwendet wurde.

Was ich noch nicht weiß, ist, wie dieses Mechanismus funktioniert, wenn sich die Policy ändert, wenn ein Provider falsche Credentials ausstellt oder wenn eine alte Session weiterhin gültig ist, obwohl die idealen Bedingungen nicht mehr gegeben sind.

Die Frage ist also: Entfernt die Kryptografie tatsächlich die Notwendigkeit, die Identität für das Access Control offenzulegen, oder verlagert sie lediglich den Trust auf den Aussteller und dessen Interpretation des Credentials.

Ich verfolge gerade, wie #dusk x die Grenze zwischen kryptografischem Proof und Service Policy handhabt, wenn reguliertes Finance damit wirklich beginnt. $DUSK $UAI $MarsCoin