Während ich Citadel 2 lese, bleibe ich an einem einzigen Satz hängen. Er ist nicht lang: „Smart Contracts sind nur dafür da, die kryptografische Gültigkeit des Session- Nachweises zu verifizieren — ob du Zutritt bekommst, liegt in der Hand des Service Providers.“ 🤔
Der Nutzer hat sich alle Mühe gemacht, einen gültigen Nachweis zu erzeugen. Die Geschichte ist noch nicht vorbei — man kann sogar sagen: Sie fängt gerade erst an.
Du kannst beweisen, dass du einen gültigen, von einem License Provider ausgestellten License besitzt. Die Daten müssen nicht on-chain, die Privatsphäre ist streng geschützt. Aber der Dienstanbieter hat noch eine Menge Fragen, die er selbst beurteilen muss: Vertraue ich diesem LP? Welche Attribute akzeptiere ich? Ist die Session abgelaufen? Wurde sie widerrufen? Kann dieses Cookie ein zweites Mal verwendet werden?
Die Privatsphäre ist geschützt — aber die Geschäftsrichtlinien entscheiden nicht für dich.
Wie sieht ein schlechtes Szenario aus?
Der Nutzer generiert erfolgreich einen proof, und auf der Seite poppt nur dieser Satz auf: „Unberechtigt.“
Nur vier Wörter. Nichts weiter. 🥶
Dann beginnt der Nutzer zu raten: Ist der Nachweis ungültig? Vertraut der Dienstanbieter dem Aussteller nicht? Oder stimmen die Attribute nicht mit den Regeln überein? Man rät herum — und hat am Ende keine Ahnung.
Es wird zwar nichts geleakt, aber die Zeit geht fürs Raten drauf. Für Nutzer bleibt die Privatsphäre zwar erhalten, aber die Erfahrung bricht zusammen.
Für den Dienstanbieter liegen alle Ablehnungen hinter einem einzigen Fehlercode verborgen — nicht einmal die Compliance-Grenzen lassen sich sauber erklären.
Diese Zurückhaltung ist eigentlich Klarheit.
Der Wert von Citadel 2 liegt darin: Es beweist, dass du gültige Credentials besitzt — und tut nie so, als müsstest du „den Dienst“ zwingend bekommen.
Der Nachweis gehört dir, die Entscheidung gehört dem Dienstanbieter. Beides wird klar getrennt.
$DUSK will die Ecosystem-Seite damit für echtes onboarding nutzen, und @Dusk sollte dazu beitragen, dass die App dem Nutzer mitteilt, ob der proof gültig ist und ob die policy abgelehnt wurde — getrennt voneinander.
War der Nachweis nicht bestanden? Oder wurde zwar bestanden, aber die policy abgelehnt? Es ist zwar einfacher, das in einen Fehlercode zu packen — aber es ist respektvoller, dem Nutzer seine eigene Urteilskraft zuzutrauen, es in zwei Codes zu trennen.
Der Nutzer weiß, in welcher Ebene es hakt, dann ist die Privatsphäre-Experience von #dusk wirklich vollständig.
Sonst gilt: Selbst wenn die Privatsphäre noch so gut geschützt ist — der Nutzer erinnert sich am Ende nur an diese vier Worte. 🤷♂️
Der Nutzer hat sich alle Mühe gemacht, einen gültigen Nachweis zu erzeugen. Die Geschichte ist noch nicht vorbei — man kann sogar sagen: Sie fängt gerade erst an.
Du kannst beweisen, dass du einen gültigen, von einem License Provider ausgestellten License besitzt. Die Daten müssen nicht on-chain, die Privatsphäre ist streng geschützt. Aber der Dienstanbieter hat noch eine Menge Fragen, die er selbst beurteilen muss: Vertraue ich diesem LP? Welche Attribute akzeptiere ich? Ist die Session abgelaufen? Wurde sie widerrufen? Kann dieses Cookie ein zweites Mal verwendet werden?
Die Privatsphäre ist geschützt — aber die Geschäftsrichtlinien entscheiden nicht für dich.
Wie sieht ein schlechtes Szenario aus?
Der Nutzer generiert erfolgreich einen proof, und auf der Seite poppt nur dieser Satz auf: „Unberechtigt.“
Nur vier Wörter. Nichts weiter. 🥶
Dann beginnt der Nutzer zu raten: Ist der Nachweis ungültig? Vertraut der Dienstanbieter dem Aussteller nicht? Oder stimmen die Attribute nicht mit den Regeln überein? Man rät herum — und hat am Ende keine Ahnung.
Es wird zwar nichts geleakt, aber die Zeit geht fürs Raten drauf. Für Nutzer bleibt die Privatsphäre zwar erhalten, aber die Erfahrung bricht zusammen.
Für den Dienstanbieter liegen alle Ablehnungen hinter einem einzigen Fehlercode verborgen — nicht einmal die Compliance-Grenzen lassen sich sauber erklären.
Diese Zurückhaltung ist eigentlich Klarheit.
Der Wert von Citadel 2 liegt darin: Es beweist, dass du gültige Credentials besitzt — und tut nie so, als müsstest du „den Dienst“ zwingend bekommen.
Der Nachweis gehört dir, die Entscheidung gehört dem Dienstanbieter. Beides wird klar getrennt.
$DUSK will die Ecosystem-Seite damit für echtes onboarding nutzen, und @Dusk sollte dazu beitragen, dass die App dem Nutzer mitteilt, ob der proof gültig ist und ob die policy abgelehnt wurde — getrennt voneinander.
War der Nachweis nicht bestanden? Oder wurde zwar bestanden, aber die policy abgelehnt? Es ist zwar einfacher, das in einen Fehlercode zu packen — aber es ist respektvoller, dem Nutzer seine eigene Urteilskraft zuzutrauen, es in zwei Codes zu trennen.
Der Nutzer weiß, in welcher Ebene es hakt, dann ist die Privatsphäre-Experience von #dusk wirklich vollständig.
Sonst gilt: Selbst wenn die Privatsphäre noch so gut geschützt ist — der Nutzer erinnert sich am Ende nur an diese vier Worte. 🤷♂️
