Nachweisbare Berechtigungen (Verifiable Credentials)

Quasi eine Abkürzung beim Aufbau eines Vertrauensnetzwerkes ist in unserem Fall die Eichung des Stromzählers. Diese ist meist als Aufkleber auf dem Stromzähler für Menschen erkennbar und wir gehen davon aus, dass es eine Prüfung im Hintergrund gegeben hat, der wir (Menschen) vertrauen können. Die Aufgabe, die der Aufkleber erfüllt, kann eine digital signierte Präsentation übernehmen. Wichtig ist, dass die Signatur ein Ablaufdatum hat, denn auch die Eichung wird eines haben. Im bereits eingeführten Transportformat der JSON-Webtokens gibt es ein Alaufdatum, welches per Konvention im Feld "exp" angezeigt wird.

Prozess der Sigelerstellung auf Seiten des Prüfers.

Wurde die Prüfung durchgeführt, so wird eine Gültigkeit dieser Eichung festgelegt bis zum 01.01.2025 (Zeitstempel: 1735689600). Der Stromzähler, den Alice genutzt hat, besitzt die Kennung „0xD8955Ff3a0Cca094Af0B8b73690297F6bCB5888D“, was das „Subject“ (Feld "sub") der Bescheinigung ist.

Im Prozess auf der Linken Seite ergibt sich als „Payload“ (Nutzlast) des Nachweises:

{
"exp":1735689600,
"sub":"0xD8955Ff3a0Cca094Af0B8b73690297F6bCB5888D"
}

Digital signiert und als JWT verpackt erhalten wir als Äquivalent zum Prüfsiegel in Form eines Aufklebers:

eyJ0eXAiOiJKV1QiLCJhbGciOiJFUzI1NkstUiJ9.eyJpYXQiOjE2NDY1NzE2NDMsImV4cCI6MTczNTY4OTYwMCwic3ViIjoiMHhEODk1NUZmM2EwQ2NhMDk0QWYwQjhiNzM2OTAyOTdGNmJDQjU4ODhEIiwiX2FkZHJlc3MiOiIweDhCRTYxNzkzZTM1Q0RBZDY3NGRGNWYwMzVBQTQ2ODc1OUIyQTU2OTkiLCJfcmV2aXNpb24iOiIweDhCRTYxNzkzZTM1Q0RBZDY3NGRGNWYwMzVBQTQ2ODc1OUIyQTU2OTkiLCJpc3MiOiJkaWQ6ZXRocjo2MjI2OjB4OEJFNjE3OTNlMzVDREFkNjc0ZEY1ZjAzNUFBNDY4NzU5QjJBNTY5OSJ9.vNyV09eFpDbVg9ZYeXokfqbB9HmaS2-voxxIgVWMCbfvnkeLITFRqPN4TJTyVvLAAuvBP-8F1IfsezzwD3vbhwE

Soll der Stromzähler nun seine Prüfung nachweisen, so genügt es diesen String zu präsentieren, welchen man natürlich auch als QR-Code auf die Säule machen könnte:

JWT als QR-Code für die „Prüfung“ eines Stromzählers.

Mit den Verfahren, die wir bislang eingeführt haben, ist es uns gelungen eine nachweisbare Berechtigung zu erstellen. Die Anzeige als QR-Code ist dabei ein eindrückliches Beispiel dafür, wie wenig High-Tech man eigentlich benötigt und bestehende Techniken durchaus auch anders verwenden kann.

Verifiable Credentials (kurz VCs) sind in der Welt der digitalen Identitäten das Salz in der Suppe. Wobei im Projektalltag es zu neuen Herausforderungen kommt, denn die Flugebene, in der man sich mit den Partnern im Projekt abstimmt muss immer geklärt werden und die darunter liegenden Techniken können nur selten als „klar“ oder „gegeben“ angenommen werden.

Web-Of-Trust und Graphen

Das Kapitel „Relationale Datenbanken meiden“ hat bereits die Nutzung von Graphen vorgestellt. Im Zuge der Verwendung von Verified Credentials im Rahmen eines Vertrauensnetzwerkes, entstehen erneut Graphen.

Vertrauensnetz

Auf Basis von insgesamt vier Präsentationen (JWTs), entsteht ein impliziter Konsens (gemeinsames Verständnis), welcher unabhängig (durch Unbeteiligte) überprüfbar ist. Damit diese wichtige Funktion überhaupt erbracht werden kann, muss das entstehen des Graphen (Netzwerk des Vertrauens) kontrolliert erfolgen. Kontrolliert bedeutet, dass die Entstehung einem festen Ablauf/Logik/Algorithmus folgt.

Exemplarisches Flowchart für Abrechnung (ohne Prüfstelle)

Wie man im Ablaufdiagramm (Flowchart) erkennen kann, wird durch die einfache Fallunterscheidung, ob eine Messstelle bereits bei Bob bekannt ist, der eigentlich recht einfache Prozess sofort deutlich komplexer. Die von Alice übermittelten Zählerstände müssen zwischengespeichert werden und, sobald der Prüfsiegel vorhanden ist, wieder zugeordnet werden. Viel einfacher würde der Ablauf sein, wenn man diesen Fall so implementiert, wie er aktuell in der Marktkommunikation der Energiewirtschaft (EDI-Energy, EDIfact) umgesetzt würde:

Vereinfachter Prozess mit Abbruch

Umgangssprachlich ausgedrückt: Soll sich doch Alice darum kümmern, den Prüfnachweis des Zählers vorzulegen und dann die Zählerstände gemeinsam mit einem Prüfnachweis erneut einreichen.

Es ist erstaunlich, was mit dem Vorschlag zu dieser Herangehensweise immer passiert. Es klingt falsch, da wir (als Menschen) besonders im Berufsalltag auf Service gepolt sind. Wir empfinden es als eine Schikane, wenn Bob eine Gutschrift ablehnt mit der Begründung, dass er diesen bestimmten Zähler nicht kennt. Aus Sicht von Alice mag dies auch sich etwas willkürlich aussehen, besonders wenn ihr vielleicht bekannt ist, dass andere an anderen Ladesäulen nicht von Bob nicht nach einem Nachweis gefragt wurden.

Unser Glück ist, dass Alice eine APP nutzt und wir wissen, wie man verhindert, dass Alice auf die Palme steigt. Angenommen der Wunsch zur Gutschrift würde unmittelbar nach dem Ende des Ladevorgangs erfolgen, dann ist es wahrscheinlich, dass Alice noch in räumlicher Nähe zur Ladesäule sich aufhält und bei der Einholung des Prüfsiegels eine Erfüllungsgehilfin sein kann. In einem schönen Farbton, ansehnlich gelayoutet, erscheint auf dem Display des Smartphones von Alice die Bitte, ob sie zufällig den QR-Code abfotografieren könne. Klick sie auf die Auswahl „Leider im Moment nicht möglich“, so erhält sie die Nachricht, dass die Gutschrift bedauerlicherweise etwas länger dauert, dann aber sofort erfolgt.

Dieser kurze Ausflug in das Produkt/App-Design zeigt, wie man mit dem Problem von fehlenden Zeigern (DIDs) und der damit verbundenen technischen Herausforderungen am Rande des IT-Kosmos (vergl. Kapitel „Am Rande des IT-Kosmos kann man abstürzen. Grenzen von P2P„) umgehen kann. Der Ausflug zeigt allerdings auch, dass plötzlich die Disziplin App-Design und Psychologie ins Spiel kommt. Wichtig, wenn man für ein Vorhaben ein Projektteam auswählt.

Meint man es mit digitalen, selbstbestimmten Identitäten wirklich ernst, dann muss man Wahrscheinlichkeiten, die einem helfen das Vertrauen digital zu verbessern nutzen. In diesem Fall die Mithilfe von Alice. Gerade am „Edge“, dem Rande des IT-Kosmos, bleibt einem keine andere Wahl, wenn das System funktionieren und den gewünschten Nutzen bringen soll. Die Alternativen sind ziemlich schauerlich… man bedenke nur, wie „nützlich“ das System sein würde, wenn jeder, bei jeder Gutschrift den Nachweis bringen müsste. Oder wenn Alice diesen erst Tage nach dem Ladevorgang nachreichen soll.

Schaut man genau hinter das Anwendungsdesign vieler existierender APPs, dann sieht man, dass diese Herangehensweise deutlich verbreiteter ist, als man zunächst denkt. Ein Beispiel ist der „Positive Test“ in der Corona-Warn-App oder die Validierung von Orten bei Google-Locals.

Seiten: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

Inhalt nicht verfügbar.
Bitte erlauben Sie Cookies, indem Sie auf Übernehmen Sie auf das Banner