Identifikator-Bestätigung (aka Zertifikate für Issuer und Verifier)

[christianheimann]

Beim Pilotprojekt der IDwallet in Deutschland mit war bei der Lancierung eines der Mankos, dass für den Holder nicht überprüfbar war, ob er mit einem vertrauenswürdigen Issuer oder Verifier kommuniziert.

Hierzu braucht es die Möglichkeit einer "Identifikator-Bestätigung", weil der Holder beim Kommunikationskanal-Aufbau eine DID sieht, aber eben durch dritte Bestätigt haben möchte, dass diese DID auch einem spezifischen Akteur gehört. In der Präsentation des Online-Partizipationsmeetings vom 03.03.2022 in den Folien 13 und 14 wurde dieses Element als "Trust Mechanism" resp. "Trust Directory" bezeichnet.

Gibt es Vorstellungen, welche Mechanismen ideal wären und warum?
Habt ihr Kenntnisse, wo welche Ansätze schon einmal erprobt wurden?

---

Dans le projet pilote de l'IDwallet en Allemagne, l'un des défauts lors du lancement était qu'il n'était pas possible pour le détenteur de vérifier s'il communiquait avec le "vrai" émetteur ou vérificateur.

Pour cela, il faut la possibilité de la "confirmation de l'identifiant", car le détenteur voit un DID lors de l'établissement du canal de communication, mais souhaite justement que des tiers confirment que ce DID appartient également à un acteur spécifique. Dans la présentation de la réunion participative en ligne du 03.03.2022 dans les diapositives 13 et 14, cet élément a été désigné comme "Trust Mechanism" ou "Trust Directory".

Avez-vous des idées sur les mécanismes qui seraient idéaux et pourquoi ?
Avez-vous des connaissances sur les approches qui ont déjà été testées ?

---

Uno dei difetti del progetto pilota IDwallet in Germania era che non era possibile per il titolare controllare se stava comunicando con un emittente o verificatore affidabile.

Questo richiede la possibilità di una "conferma dell'identificatore", perché il titolare vede un DID quando imposta il canale di comunicazione, ma vuole avere la conferma da una terza parte che questo DID appartiene anche a un attore specifico. Nella presentazione della riunione di partecipazione online del 03.03.2022 nelle diapositive 13 e 14, questo elemento è stato descritto come un "meccanismo di fiducia" o "directory di fiducia".

Ci sono idee su quali meccanismi sarebbero ideali e perché?
Sapete dove sono già stati testati gli approcci?

[pascalgottret]

Spannende Frage und tatsächlich gibt es Lösungen dazu. Sie nennt sich Domain Verification ID. Der Issuer bindet seine DID an seine registrierte Domain (z.B. www.admin.ch). Das Wallet des Holder resp. des Verifier prüft kryptographisch, dass eine DID einer bestimmten Domain zugeordnet ist und zeigt dem Benutzer die Domain. Diese Lösung existiert bereits und nähere Infos kann ich gerne dazu liefern.

Der Vorteil ist enorm: wir können ein "trusted" Ecosystem aufbauen, das nicht auf ein zentrales Register angewiesen ist. Der Verifier und Holder können selbst entscheiden, ob sie dem jeweiligen Akteur vertrauen oder nicht.

Mir ist bewusst, dass diese Lösung ein Governance Framework, wo rechtliche und ökonomische Fragen geklärt werden müssen, nicht vollständig ersetzt. Zum Beispiel kann ein Verifier aus Deutschland vermutlich nicht wissen, dass nur www.be.ch (die Kantone) berechtigt ist, ein Rechtsanwaltszertifikat für Berner Anwälte auszustellen. Bei solchen Anwendungsfällen braucht es ein Governance Framework, wo Issuer / Verifier aufgenommen werden.

Mir ist zudem bewusst, dass die Lösung für die ältere Generation, die nicht mit www aufgewachsen sind, herausfordernd ist. Auch kann es schwierig sein zwischen www.sbb.io oder www.sbb.ch zu unterscheiden. Hier kann es erforderlich sein, ein breit ausgelegtes Bewertungssystem der Vertrauenswürdigkeit zu integrieren. Das wird auch bei einem Governance Framework nötig sein, da eine zentrale Instanz Betrug nicht zwingend verhindern kann.

[grt-dti]

Ich bin ganz grundsätzlich kein Freund davon, mit dem Schweizer Taschenmesser "DNS" Trust-Probleme lösen zu wollen - dafür wurde DNS nicht geschaffen....
Zum konkreten (bedenkenswerten) Vorschlag: dieses DID-Bindung an eine DNS-Domain würde den Einsatz von DNSSec zwingend voraussetzen oder man müsste ein anderes integritätsgesichertes Verfahren für die Namensauflösung verwenden (z.B. DNSoverHTTPS,...). Wir lösen aber das Trust-Problem nicht wirklich, sondern verlagern es auf ein anderes (eben genau nicht wirklich gelöstes) Trustproblem; das der vertrauens(un)würdigen Domainnamen.
Bei all der schönen Technisierung müssen wir eines im Blick behalten - es geht bei der E-ID am Ende um global-rechtlich verbindliche Konstrukte (die Technologie spielt da eine absolut untergeordnete Rolle!). Damit wir die E-ID im E-Government einsetzen können, braucht's zwingend eine (verwaltungs-)rechtlich stabile Basis - DNS und DNSSec oder Domainnamen etc. sind dies (heute zumindest) genau NICHT; das sind privatwirtschaftliche/privatrechtliche Konstrukte, die keine Rechtswirkung in der Verwaltung herstellen können. Wenn das ganze wirklich stabil werden soll (also den rein privatrechtlichen Rahmen verlassen), brauchen wir andere DID-Bindings und dies wahrscheinlich sogar wirklich sowohl für die Verifier als auch die Issuer. Wir brauchen eine Technik, um Identitäten zweifelsfrei den sie repräsentierenden juristischen und natürlichen Personen zuordnen zu können, ohne dabei auf andere (mit Löchern behaftete) Techniken zurückgreifen zu müssen. Dummerweise muss diese Zuordnung auch noch (zumindest zur EU) auf die gleiche Art&Weise erfolgen (oder es braucht wieder ein zentrales EU-Gateway zur Transformation einer CH-eID zu einer EU-eID)
Und um das nochmal klar herauszustellen: für den privatrechtlichen/privatwirtschaftlichen Rahmen wäre dieses DID-2-DNSDomain-Binding schon bedenkenswert; nur könnten wir das wahrscheinlich heute ohne E-ID-Gesetz bereits....

[pascalgottret]

Ich teile die Meinung, dass diese Lösung nur im privatrechtlichen/privatwirtschaftlichen Rahmen diskutiert werden darf. Wenn wir über ein Ambitionsniveau 3 diskutieren, gehört diese Ebene dann aber dazu.

Für andere DID-Binding muss ein zentral verwaltetes Registry oder ein pro Ecosystem vorhandenes Registry (wie von DIDAS vorgeschlagen) vorhanden sein, das eine (verwaltungs-)rechtlich stabile Basis bildet. Absolut einverstanden.

[KasparEtter]

Ich bin zwar kein Fan des X.509 Standards, doch Extended Validation Certificates scheinen durchaus erprobt zu sein.