Zusammenfassung

  • Revision 02 von Identity Verification Methods Values vom 2. Oktober 2026 besagt: Ein ivm-Wert bedeutet, dass die bezeichnete Methode der Identitätsprüfung erfolgreich war. Der Claim liefert aber weder den zugrunde liegenden Beleg noch Einzelheiten dazu, wie die Methode eingesetzt wurde.
  • Das vorgeschlagene Vokabular kann Interoperabilität verbessern. Für sich genommen belegt es weder die Güte eines Anbieters noch die Autorität einer Quelle, die Gleichwertigkeit zweier Verfahren, die Aktualität, ein Vertrauensniveau, die rechtliche Eignung oder die nachgelagerte Entscheidung.

Kompression ist nützlich, bis ein kurzer Code beginnt, sich die Autorität all dessen zu leihen, was er auslässt. Genau diese Governance-Grenze legt draft-skyfire-oauth-id-verification-02 offen.

Der Entwurf schlägt ivm als JSON-Array aus Zeichenketten vor, bei denen Groß- und Kleinschreibung relevant ist. Das erste Vokabular umfasst Datenbankprüfungen mit einer nicht festgelegten Zahl, mit einer oder mit mehreren Verbraucher-Auskunftsquellen; die Prüfung digitaler und physischer Identitätsdokumente; Sekundärdokumente; eine persönliche Prüfung vor Ort; sowie ein Live-Videointerview. Ein empfangendes System bekommt damit eine knappe Angabe darüber, welche Familien von Methoden erfolgreich waren.

Revision 02 enthält den Satz, der jede Nutzung dieser Angabe bestimmen sollte. Das Vorhandensein eines Wertes zeigt an, dass die Methode erfolgreich war. Der Claim enthält weder Beweismaterial noch Einzelheiten darüber, wie die Methode verwendet wurde. Für Einsätze, die diese Tiefe benötigen, verweist der Entwurf auf OpenID Identity Assurance oder Vectors of Trust – zusätzlich zu ivm oder an dessen Stelle.

Dieser Vorbehalt ist kein Mangel des Vokabulars. Er beschreibt dessen richtige Aufgabe. Eine Methodenkennung kann verhindern, dass zwei Systeme für dieselbe grobe Technik verschiedene Begriffe erfinden. Sie kann Protokolle durchsuchbar, Richtlinien portabler und Assertions kleiner machen. Sie kann nicht den vollständigen Prüfungsfall transportieren, ohne selbst zu einer anderen Datenstruktur zu werden.

Das zeigt sich an dbv1 und dbvm. Der erste Wert sagt, dass eine Quelle aus dem Bereich der Verbraucherauskunft verwendet wurde; der zweite, dass es mehrere waren. Keines der Labels benennt die Quellen, belegt ihre Unabhängigkeit, identifiziert die abgefragten Datensätze oder erhält deren Stand. Es bleibt offen, ob Befunde einander widersprachen, welcher Schwellenwert für eine Übereinstimmung galt und welche Merkmale tatsächlich übereinstimmten. Quellen zu zählen heißt nicht, ihre Autorität oder Verschiedenheit nachzuweisen.

Auch die dokumentbezogenen Werte bergen erhebliche innere Unterschiede. phy kann eine Echtzeitaufnahme eines Führerscheins oder einer Passseite bezeichnen. Das Label nennt jedoch weder Dokumentversion und ausstellende Rechtsordnung noch Aufnahmegerät, Manipulationsprüfung oder biometrischen Vergleich. dig verrät nicht, welches Vertrauensrahmenwerk für eine digitale Berechtigung galt. vid bezeichnet ein Live-Interview, nicht dessen Liveness-Kontrolle, Prüfer, Gesprächsleitfaden, Aufzeichnungsregel oder Ausnahmebehandlung. inp identifiziert weder Ort und prüfende Person noch beaufsichtigte Geräte.

Selbst das Wort „erfolgreich“ ist an ein lokales Verfahren gebunden. Es sagt dem Empfänger, dass der Aussteller seinen eigenen Erfolgszustand erreicht hat. Es legt den Schwellenwert nicht offen, zeigt keine gemeinsame Schwelle zwischen zwei Ausstellern und beweist nicht, dass die behauptete reale Identität richtig ist. Ein signiertes JWT kann authentisieren, wer die Aussage abgegeben hat, und unbemerkte Veränderungen verhindern. Es kann keine Tatsachen wiederherstellen, die nie Teil der Aussage waren.

Auch die vorgeschlagene IANA-Struktur verlangt diese Präzision. Revision 02 beantragt einen JWT-Claim ivm und ein neues Register für Identity Verification Methods. Vorgesehen sind Expert Review, eine dreiwöchige Prüfung auf der Mailingliste und Kriterien wie die Vermeidung von Doppelungen, allgemeine Verwendbarkeit, tatsächliche Nutzung und eine klare Beschreibung. Das verbessert die Qualität des Namensraums. Es akkreditiert keine Anbieter, zertifiziert keine Implementierungen und vergibt keinen universellen Vertrauenswert.

Für tatsächliche Zuweisungen bleiben die aktiven IANA-Register maßgeblich. Eine Tabelle in einem individuellen Internet-Draft ist ein Vorschlag für den anfänglichen Inhalt, kein Beweis dafür, dass IANA das Register bereits eingerichtet hat. Der eingefrorene Datatracker-Datensatz weist weder einen Stream noch eine angestrebte oder erreichte Standardsstufe aus. Die Nähe zum OAuth-Bereich und dessen Diskussionsforum macht den Entwurf nicht zu einem angenommenen Working-Group-Dokument und nicht zu einem RFC.

Der Vergleich mit amr ist lehrreich. RFC 8176 standardisierte Referenzwerte für Authentifizierungsmethoden, warnte jedoch davor, Richtlinien unmittelbar an bestimmte Methoden zu binden: Angriffe und Einsatzformen verändern sich, solche Regeln können spröde werden. Methodennamen helfen zu berichten, was geschah. Ein weiter gefasster Authentifizierungskontext kann ausdrücken, welche Richtlinienklasse ein Dienst verlangt hat. Auch Identitätsprüfung braucht die Trennung zwischen dem Mechanismus-Label und dem Assurance-Vertrag, unter dem das Ergebnis angenommen wurde.

OpenID Identity Assurance zeigt, wie ein reichhaltigerer Transport aussehen kann. Das Modell kann Vertrauensrahmen, Assurance-Level und Prozess unterscheiden; den Zeitpunkt der Gesamtprüfung, eine Referenz auf den Prüfungsfall und Belegobjekte festhalten; sowie einzelne Prüfschritte mit Methode, Organisation, Ereigniskennung und Abschlusszeit beschreiben. RFC 8485 stellt ebenfalls klar, dass Vektorwerte innerhalb eines bestimmten Vertrauensrahmens Bedeutung erhalten, den die relying party verstehen muss.

NIST SP 800-63A-4 liefert eine weitere hilfreiche Zerlegung. Die Richtlinie trennt Identitätsauflösung, Erfassung und Stärke der Nachweise, Validierung und Verifikation. Ein Code für „physisches Dokument“ oder „Video“ belegt nur eine semantische Koordinate. Allein sagt er nichts über die Stärke des Belegs, die zur Validierung genutzte autoritative oder glaubwürdige Quelle oder die Bindung der antragstellenden Person an den Beleg.

Die operative Antwort lautet deshalb nicht, kompakte Claims abzulehnen. Sie lautet, sie nicht zu Schatten in Beweisform werden zu lassen. Neben dem Token gehört eine Belegquittung: exakte Vokabularversion; Aussteller und Vertrauensrahmen; Bindung an Subjekt und Transaktion; Methodenwerte; Anbieter- und Richtlinienversion; unveränderliche Belegreferenz; Quelle und Rechtsordnung; Validierungs- und Verifikationsprüfungen; Ergebnis von Liveness- oder menschlicher Prüfung; Zeitstempel; Assurance-Klasse; Ausnahmen; lokale Entscheidung; und Anwendungsergebnis.

Diese Liste ist redaktionelle Betriebsempfehlung, kein Text des Entwurfs. Ihr Zweck ist die spätere Rekonstruktion. Ändert ein Anbieter einen Schwellenwert, wird eine Datenbank aktualisiert, läuft ein Dokument ab, ändert eine Rechtsordnung ihre Regeln oder fragt ein Auditor nach dem Vorgang, kann die Organisation ihre Entscheidung nachvollziehen, ohne so zu tun, als habe der dreibuchstabige Code eine Fallakte enthalten.

Heng Lus Minimum Initial Specification stützt diese Grenze: Standardisiert wird das kleinste Vokabular, das freiwillige Interoperabilität ermöglicht; die Verantwortung für folgenreiche Entscheidungen bleibt lokal. Running-Code Primacy fragt, welche Prüfungen tatsächlich ausgeführt wurden – nicht, welches Label ein Token trug. Reality Layers verhindert, dass ein Registerbegriff, die Assertion eines Ausstellers, ein Belegdatensatz, ein Assurance-Urteil und die endgültige Handlung zu einem einzigen Status verschmelzen.

ivm kann also gerade deshalb wertvoll sein, weil es klein ist. Voraussetzung sind intellektuelle und operative Ehrlichkeit. Das Label soll die Methode benennen. Der Beleg muss den Fall tragen. Die relying party muss die Folgen verantworten.

Sources