@NewtonProtocol Jedes Mal, wenn du fliegst, beweist du genau einmal, wer du bist.
An der Sicherheitskontrolle gleicht ein Mitarbeiter deine ID mit deiner Bordkarte ab. Danach fragt jede Gate-Mitarbeiterin und jedes Flugbegleitpersonal, das sich während des restlichen Trips mit dir befasst, nur noch nach der Bordkarte.
Niemand am Gate prüft noch einmal deinen Pass. Sie brauchen weder dein Geburtsdatum noch deine Wohnadresse. Sie müssen nur wissen, dass du freigegeben wurdest.
Ich hatte nicht viel darüber nachgedacht, wie seltsam diese Trennung ist, bis ich anfing zu betrachten, wie Kryptosysteme Identität und Compliance handhaben.
Der gängige Ansatz scheint Alles-oder-nichts zu sein. Entweder hält eine Plattform an Ihren vollständigen Identitätsdaten fest, um jede Aktion zu prüfen, die Sie ausführen, oder eine Kette führt überhaupt keine Checks durch und hofft auf das Beste.
Wie würde es aussehen, wenn man beweisen könnte, dass man dazu berechtigt ist, etwas zu tun, ohne dass ein System immer wieder neu prüfen muss, wer man ist?
Diese Frage hat mich dazu gebracht, wie @NewtonProtocol die Autorisierungsschicht gestaltet.
Newton trennt die Identitätsverifikation von der eigentlichen Autorisierungsentscheidung. Durch eine Integration mit Persona fließen verifizierte Identitäts- und Aufenthaltsattribute in N ewtons Policy-Engine ein, aber die Prüfung erfolgt einmalig über eine vertrauenswürdige Ausführungsumgebung, statt jedes Mal offen neu ausgeführt zu werden.
Was sich On-Chain danach bewegt, sind nicht die Identitätsdaten. Es ist das Ergebnis einer kryptografischen Bestätigung, die belegt, dass eine Transaktion die erforderliche Richtlinie erfüllt hat, aufgezeichnet, damit sie später verifiziert werden kann, ohne offenzulegen, was sich dahinter befindet.
So wie ich es verstehe, werden die Richtlinien selbst in Rego geschrieben und vor dem Abschluss einer Transaktion von einem dezentralen Netzwerk von Operatoren ausgewertet—ähnlich wie ein Karten- Netzwerk Betrugsregeln und Identität prüft, bevor eine Zahlung durchgeht.
Der interessante Teil war nicht der Datenschutz-Aspekt an sich. Es war die Erkenntnis, dass Authentifizierung und Autorisierung tatsächlich zwei verschiedene Probleme sind, die die meisten Systeme stillschweigend zu einem zusammenführen.
Authentifizierung fragt, wer du bist, und muss idealerweise nur einmal beantwortet werden. Autorisierung fragt, was dir gerade erlaubt ist, und muss bei jeder einzelnen Aktion beantwortet werden.
Wenn man sie vermischt, zwingt man zu einer unangenehmen Entscheidung. Entweder wird die Identität wiederholt offengelegt, um sie weiter zu verifizieren, oder die Prüfungen werden übersprungen, um die Privatsphäre zu schützen.
Wenn man sie trennt, verändert sich das. Die Identitätsprüfung bleibt privat und passiert selten. Die Autorisierungsprüfung passiert ständig, aber sie legt nur jemals ein Ja oder Nein offen, nicht die Gründe dafür.
Ich frage mich nur ständig, was das eigentlich kostet. Sie gewinnen Privatsphäre, aber Sie verlieren die Fähigkeit, persönlich zu verifizieren, was in dieser privaten Prüfung passiert ist.
Du vertraust dem Orakel, der Enklave und den Operatoren, die Identität in eine Entscheidung übersetzen, statt die zugrunde liegenden Daten selbst zu sehen. Das ist eine andere Art von Vertrauen—nicht das Fehlen von Vertrauen.
Für Entwickler scheint das eine echte Bürde zu beseitigen. Das Speichern einer vollständigen Identitätsdatenbank Ihrer eigenen Nutzer ist eine Haftung, die die meisten Teams nicht wollen und die sie ohnehin nicht vollständig sichern können.
Für Nutzer bedeutet das: Es gibt eine öffentliche, prüfbare Aufzeichnung darüber, was autorisiert wurde, ohne dass es eine öffentliche Aufzeichnung darüber gibt, an wen genau du dabei gebunden bist.
Für Institutionen bietet es etwas, das man woanders schwerer bekommt: einen Nachweis, dass eine Regel befolgt wurde—ohne dafür zum Verwahrer der persönlichen Daten aller werden zu müssen.
Je länger ich darüber nachdenke, desto mehr fühlt es sich so an, als läge die eigentliche Erkenntnis nicht einzeln in Datenschutz oder Compliance. Es ist einfacher als das.
Der Nachweis erfordert keine Offenlegung.
Ich bin immer noch nicht ganz davon überzeugt, dass das Vertrauen in eine Infrastruktur, die man persönlich nicht prüfen kann, sich sinnvollerweise davon unterscheidet, dass man früher demjenigen vertraute, der direkt Ihre Daten gehalten hat.
Vielleicht ist die eigentliche Frage nicht, ob Identität und Berechtigung getrennt werden sollten. Vielleicht geht es darum, wie viel stilles Vertrauen diese Trennung von uns in allem fordert, was dazwischen liegt.
