#dusk $DUSK @Dusk Wenn es Zero-Knowledge-Proof-Dienste gibt, muss man dich dann automatisch einlassen? Als ich mir die Citadel-2-Dokumentation von @Dusk durchgelesen habe, fand ich die Antwort allerdings eher umgekehrt: Der Citadel-Vertrag ist nur dafür zuständig, zu verifizieren, dass die Session kryptografisch gültig ist. Die eigentliche Entscheidung, ob der Zutritt gewährt wird, trifft weiterhin der Service Provider. Diese Grenze lässt sich sehr leicht mit einem Satz wie „Keine Offenlegung persönlicher Daten erforderlich“ überdecken: Der Nutzer erhält zuerst vom License Provider einen Nachweis, erzeugt dann den Beweis und zeigt damit, dass er eine registrierte Lizenz besitzt, die von einer vertrauenswürdigen Stelle ausgestellt wurde. On-Chain ist jedoch nicht sichtbar, welches Ausweisdokument er verwendet. Aber beim Service-Eingang muss der SP selbst beurteilen, welchen LP er vertraut und welche Attribute er akzeptiert—außerdem ob die Session abgelaufen oder widerrufen ist und ob Cookies wiederverwendet werden können.
Ich finde, das ist gerade ehrlicher bei Citadel 2: Es verpackt „Der Beweis gilt“ nicht als „Berechtigung wird automatisch erteilt“, sondern trennt kryptografische Verifikation und geschäftliche Autorisierung in zwei Schritte. Für Nutzer wird weniger persönliche Information offengelegt, für Service-Anbieter verschwinden die Regeln nicht—sie verlagern sich lediglich von der Erfassung eines vollständigen Datensatzes hin zur Auswahl von vertrauenswürdigen Quellen und zur Prüfung des Session-Status. Auch die Belastungsszenarien sind sehr konkret: Der Nutzererzeugt einen vollständig korrekten Nachweis, aber der Service verweigert den Zugriff, weil er dem LP, der diese Lizenz ausgestellt hat, nicht vertraut, oder weil er feststellt, dass die Session abgelaufen ist. Dann könnte der Nutzer glauben, es liege ein Fehler on-Chain vor, während der SP der Ansicht ist, dass er nur seine Richtlinien korrekt umsetzt. Wenn die Seite nur „Verifizierung fehlgeschlagen“ anzeigt, können beide Seiten keine echte Stelle für Verantwortung ausmachen.
Daher sehe ich mir bei meinem Blick auf das Identitätsdesign von DUSK nicht nur an, wie viele Attribute es verbergen kann. Ich will vor allem wissen, ob jede Anwendung den Unterschied zwischen „Beweis ist gültig“ und „Service wird freigegeben“ klar erklärt. Citadel 2 von @Dusk kann zwar unnötige Offenlegung reduzieren, aber es kann nicht anstelle einer Anwendung entscheiden, wem vertraut wird. Das, was künftig am meisten beobachtenswert ist, ist: Kann der Nutzer bei einer Ablehnung verstehen, ob das Problem beim Beweis, beim Nachweis (Credential) oder bei den Service-Richtlinien liegt? #dusk
Ich finde, das ist gerade ehrlicher bei Citadel 2: Es verpackt „Der Beweis gilt“ nicht als „Berechtigung wird automatisch erteilt“, sondern trennt kryptografische Verifikation und geschäftliche Autorisierung in zwei Schritte. Für Nutzer wird weniger persönliche Information offengelegt, für Service-Anbieter verschwinden die Regeln nicht—sie verlagern sich lediglich von der Erfassung eines vollständigen Datensatzes hin zur Auswahl von vertrauenswürdigen Quellen und zur Prüfung des Session-Status. Auch die Belastungsszenarien sind sehr konkret: Der Nutzererzeugt einen vollständig korrekten Nachweis, aber der Service verweigert den Zugriff, weil er dem LP, der diese Lizenz ausgestellt hat, nicht vertraut, oder weil er feststellt, dass die Session abgelaufen ist. Dann könnte der Nutzer glauben, es liege ein Fehler on-Chain vor, während der SP der Ansicht ist, dass er nur seine Richtlinien korrekt umsetzt. Wenn die Seite nur „Verifizierung fehlgeschlagen“ anzeigt, können beide Seiten keine echte Stelle für Verantwortung ausmachen.
Daher sehe ich mir bei meinem Blick auf das Identitätsdesign von DUSK nicht nur an, wie viele Attribute es verbergen kann. Ich will vor allem wissen, ob jede Anwendung den Unterschied zwischen „Beweis ist gültig“ und „Service wird freigegeben“ klar erklärt. Citadel 2 von @Dusk kann zwar unnötige Offenlegung reduzieren, aber es kann nicht anstelle einer Anwendung entscheiden, wem vertraut wird. Das, was künftig am meisten beobachtenswert ist, ist: Kann der Nutzer bei einer Ablehnung verstehen, ob das Problem beim Beweis, beim Nachweis (Credential) oder bei den Service-Richtlinien liegt? #dusk
