Zusammenfassung

  • Der aktuelle REGEXT-Entwurf kann abbilden, welche RDAP-Kontaktangaben wann, von wem, mit welcher Methode und Evidenz sowie unter welchem Vertrauensrahmen geprüft wurden. Fast alle beschreibenden Felder sind optional; keines begründet eine allgemeine Veröffentlichungs- oder Vertrauensbefugnis.
  • Betreiber sollten jede Offenlegung mit einem Adressaten- und Gültigkeitsbeleg verbinden: Wer erhielt welche Felder für welchen Zweck, nach welcher Regel und mit welchem Aktualitätshorizont? Dieser Beleg ist ein redaktioneller Betriebsvorschlag von Daniel Kade, keine Forderung des IETF-Entwurfs.

Derselbe Prüfvorgang, unterschiedliche Antworten

Auf denselben RDAP-Datensatz können drei Anfragen treffen. Ein anonymer Nutzer ruft den öffentlichen Dienst auf. Ein authentifizierter Abuse-Bearbeiter nennt einen konkreten Untersuchungszweck. Eine zuständige Behörde verlangt auf einer eigenen Rechtsgrundlage einen begrenzten Datensatz. Im System des Registrars liegt nur ein Prüfvorgang für die E-Mail-Adresse. Trotzdem müssen die drei Antworten weder gleich umfangreich sein noch dieselbe Begründung haben.

Verifikation beschreibt, was mit einem bestimmten Anspruch geschehen ist. Offenlegung entscheidet, welche Information an welchen Empfänger gehen darf. Die anschließende Verwendung entscheidet, welche Schlussfolgerung dieser Empfänger ziehen darf. Wer alle drei Ebenen in ein grünes Häkchen presst, macht die Oberfläche einfacher und die Aussage zugleich unkontrollierbar.

Die Verfälschung entsteht oft nicht an der Quelle, sondern auf dem Weg. Das erste System kennt Anspruch, Datum und Methode. Ein Portal übernimmt nur den Status. Ein Export lässt das Datum fallen. Eine Risikoplattform macht daraus einen Score. So wird aus „E-Mail-Erreichbarkeit am 10. März bestätigt“ unbemerkt „Registrant verifiziert“. Keine einzelne Schnittstelle muss fehlerhaft sein; der Fehler liegt in der fortgesetzten Entfernung der Grenzen.

Der Status von Revision 04

Revision 04 von Registration Data Access Protocol (RDAP) Extension for Verified Contact Information trägt das Datum 24. August 2026. Der IETF Datatracker führt sie als aktiven Internet-Draft im REGEXT-Kontext, mit dem Arbeitsgruppenstatus „Candidate for WG Adoption“ und dem IESG-Status „I-D Exists“. Sie ist weder ein verabschiedeter Standard noch formell vom IETF gebilligt. „Intended status: Standards Track“ im Dokumentkopf beschreibt ein Ziel, nicht den Abschluss des Verfahrens.

Der Entwurf schlägt in RDAP-Entity-Objekten ein Array namens verifiedContacts_data vor. Ein Eintrag kann festhalten, welche Angaben geprüft wurden: etwa E-Mail, Telefonnummer, Fax, Anschrift, Name oder Geburtsdatum. Hinzukommen können Abschlusszeitpunkt, Kennung und Name des Prüfers, Kennung des Prüfvorgangs, Vertrauensrahmen, Methode, Evidenzart, Bemerkungen und Erweiterungsdaten.

Mehrere Einträge dürfen nebeneinander bestehen. Der Name kann anhand eines Dokuments, die E-Mail über einen Link und die Anschrift gegen eine Datenbank geprüft worden sein. Akteure, Zeitpunkte und Regeln unterscheiden sich. Das Array bewahrt diese Trennung. Eine Benutzeroberfläche, die daraus ein einziges Ja oder Nein macht, beseitigt den wertvollsten Teil des Modells.

Die zentralen Erläuterungsfelder sind überwiegend optional. Fehlt eine Angabe, ist sie unbekannt und nicht stillschweigend positiv. Revision 04 stellt für verificationDate klar: Das Feld bezeichnet den Abschluss des Prüfvorgangs; sein Fehlen bedeutet nicht, dass die Verifikation aktuell ist. Auch ein vorhandenes Datum ist kein Ablaufdatum. Ob ein Ergebnis für einen bestimmten Zweck noch genügt, bestimmen die lokale Aktualitätsregel, spätere Änderungen und das Risiko der Entscheidung.

Der Vergleich mit Revision 03 zeigt korrigierte JSON-Beispiele, Anpassungen an den neueren RDAP-Versionierungsentwurf und die ergänzte Erläuterung zum Abschlusszeitpunkt. Die Änderungshistorie der Revision 04 fasst dies als Korrektur der Beispiele, Aktualisierung für die aktuelle Versionierung und Textbereinigung zusammen. Betreiber sollten deshalb nicht nur den Namen des Entwurfs, sondern die tatsächlich ausgewertete Fassung festhalten.

Was wurde wie verifiziert?

Der Entwurf trennt Methode und Evidenz. reachability verlangt eine aktive Empfangsbestätigung, zum Beispiel einen eingegebenen Code, einen angeklickten Link oder eine bestätigte Zustellung. Weitere Methoden reichen von Dokumenten- und Registerabgleichen über kryptografische Prüfung, elektronische Authentisierung und Token bis zu Wissensfragen, persönlicher oder entfernter Sichtprüfung und Biometrie.

Als Evidenzarten nennt der Text unter anderem Ausweis, Reisepass, Aufenthaltstitel, Bank- und Versorgerauszug, Steuer- und Geburtsunterlagen, Bevölkerungsregister, schriftliche oder digitale Bestätigungen sowie Protokolle einer E-Mail- oder Postverifikation und Adressdatenbanken. Dieselbe Evidenz kann auf verschiedene Weise geprüft werden; dieselbe Methode kann auf unterschiedliche Evidenz treffen. Aussagekräftig ist nur die Kombination aus Anspruch, Methode, Evidenz und Rahmen.

Ein erreichbares Postfach beweist nicht automatisch die bürgerliche Identität. Eine geprüfte Identität beweist keine aktuelle Vollmacht für ein Unternehmen. Eine Vollmacht belegt nicht ohne Weiteres die gegenwärtige Kontrolle über eine Domain oder Nummernressource. Und ein geprüftes Feld garantiert nicht die Vollständigkeit des gesamten Registrierungsdatensatzes.

Diese Begrenzungen entwerten die Prüfung nicht. Sie machen sie entscheidungsfähig. Für die Priorisierung einer Abuse-Kommunikation kann eine junge Erreichbarkeitsprüfung genügen. Für einen Transfer oder eine rechtlich folgenreiche Handlung können andere Nachweise nötig sein. Die Evidenz muss zur Entscheidung passen, nicht zur Farbe eines Siegels.

Ein privater Vertrauensrahmen braucht eine Fundstelle

trustFramework ist erweiterbar. Der Entwurf definiert unter anderem eidas und private. Letzteres bezeichnet eine Prüfung nach der Richtlinie des Serverbetreibers und nicht nach einem registrierten externen Rahmen. Das ist weder wertlos noch global selbsterklärend.

Wer lediglich private speichert, verweist auf „die Richtlinie“, ohne ihre Ausgabe zu nennen. Akzeptierte Dokumente, Wiederholungsfristen, befugte Prüfer und Ausnahmen können sich ändern. Um eine frühere Entscheidung zu rekonstruieren, braucht der Empfänger eine stabile Richtlinienkennung und die damals gültige Version oder Prüfsumme.

Auch ein externer Rahmen erklärt nicht alles durch seinen Namen. Relevant bleiben der konkrete Anspruch, ein etwaiges Vertrauensniveau, die Rechtsordnung und die eingesetzte Methode. Interoperabilität bedeutet nicht, unterschiedliche Ergebnisse gleich aussehen zu lassen. Sie bedeutet, Unterschiede zuverlässig lesbar zu halten.

Schon die Evidenzkategorie kann sensibel sein

Dass Passkopien oder biometrisches Rohmaterial nicht über RDAP ausgeliefert werden dürfen, ist selbstverständlich. Doch auch die Information, ein Aufenthaltstitel, ein Steuerregister oder ein biometrischer Vergleich sei verwendet worden, beschreibt den Identitätsprüfpfad einer Person. Für einen berechtigten Empfänger kann das nötig sein; für die anonyme Öffentlichkeit kann es übermäßig sein.

Die Security Considerations des Entwurfs sagen ausdrücklich, dass Kontaktverifikationsdaten Auswirkungen auf die Privatsphäre haben können. Server müssen sicherstellen, dass die Offenlegung mit den geltenden Datenschutzgesetzen und Richtlinien übereinstimmt. In der Einleitung nennt der Entwurf sowohl öffentlich erreichbare RDAP-Dienste als auch geschlossene Dienste, die eine vorherige Autorisierung legitimer Antragsteller oder Behörden voraussetzen.

Das Format ist also für mehrere Zugangsmodelle gedacht. Es ordnet nicht an, dass alle Empfänger alles sehen. Ein Betreiber kann in der öffentlichen Antwort nur eine Redaktionsinformation ausgeben, im authentifizierten Dienst einen engen Satz von Metadaten zeigen und bestimmte Evidenzarten grundsätzlich zurückhalten.

Auch der Verweis des Entwurfs auf Artikel 28 der NIS2-Richtlinie darf nicht überdehnt werden. Er bildet den Kontext für richtige und vollständige Domain-Registrierungsdaten. Daraus folgt kein allgemeines Gebot, Verifikationsmetadaten weltweit öffentlich zu machen. Erheben, pflegen, prüfen, eingeschränkt zugänglich machen und veröffentlichen sind getrennte Verarbeitungsschritte.

Fünf Leerstellen hinter dem Häkchen

Ein universelles Siegel verschweigt mindestens fünf Dinge: das betroffene RDAP-Objekt, den geprüften Anspruch, Methode und Evidenz, Zeitpunkt und Aktualitätsregel sowie den vorgesehenen Empfängerkreis. Ändert sich die Mailbox, die Richtlinie oder der Verifikationsstatus, kann das Häkchen trotzdem unverändert grün bleiben.

Der umgekehrte Fehlschluss ist ebenso gefährlich. Wenn eine öffentliche Antwort keine Verifikationsmetadaten zeigt, heißt das nicht, dass keine Prüfung stattfand. Vielleicht ist nur der aktuelle Leser nicht zur Einsicht berechtigt. Datenqualität und Offenlegungsstatus müssen auf getrennten Achsen geführt werden.

Nach der Weitergabe wird der Fehler schwer umkehrbar. Suchindizes, Datenhändler und Fallsysteme können das Siegel speichern, während die Quelle später korrigiert oder ersetzt wird. Eine ursprünglich wahre, enge Aussage lebt dann als breite, veraltete Reputation fort.

Der Adressaten- und Gültigkeitsbeleg

Bei jeder Umwandlung gespeicherter Verifikationsdaten in eine RDAP-Antwort sollte ein interner Beleg entstehen. Er erweitert nicht das Protokollformat. Er dokumentiert die Entscheidung, die genau diese Offenlegung hervorgebracht hat.

Auf der Quellseite verbindet er RDAP-Objekt und exakte Anspruchsliste mit Verifikationskennung, Prüfer und Abschlusszeitpunkt, soweit vorhanden. Methode, Evidenzart und Vertrauensrahmen gehören dazu, ebenso die konkrete Richtlinie und Version, mit der der Rahmen interpretiert wurde. Fehlende Felder bleiben ausdrücklich fehlend.

Auf der Empfängerseite hält er Antragstellerklasse, gegebenenfalls authentifizierte Identität, erklärten Zweck, öffentlichen oder beschränkten Kanal und die tatsächlich offengelegten, redigierten oder zurückgehaltenen Felder fest. Rechtsnorm, Vertrag, veröffentlichte Zugangspolitik oder Einzelfallentscheidung müssen als Ermächtigungsgrund auffindbar sein. Verantwortlicher und Überprüfungsweg runden die Entscheidung ab.

Der Gültigkeitsteil nennt Wiederholungsintervall, ereignisbezogene Auslöser, den Umgang mit fehlenden Daten und den Stand von Korrektur, Widerruf oder Ersetzung. Damit wird verificationDate nicht heimlich um eine Protokollbedeutung ergänzt. Dokumentiert wird die lokale Entscheidung, ob ein vergangenes Ergebnis für den heutigen Zweck noch verwendbar ist.

Der Beleg kopiert keine Ausweise, biometrischen Merkmale oder Geheimnisse des Prüfers. Er speichert die Begründungsgrenze, nicht das sensible Ausgangsmaterial.

Klein anfangen, ohne die Zukunft festzuschreiben

Heng Lus Leitbild einer minimalen Anfangsspezifikation, lokalisierter späterer Entscheidungen und freiwilliger Einführung passt zu diesem Feld. Gemeinsame Bezeichnungen für Ansprüche, Methoden, Evidenz und Rahmen verbessern die Verständigung. Sie verlangen nicht, sofort eine einzige weltweite Offenlegungspolitik festzulegen.

Ein Betreiber kann mit einem Anspruch, einer versionierten privaten Richtlinie, einer authentifizierten Empfängergruppe und einem kurzen Überprüfungsintervall beginnen. Öffentliche Antworten können auf redigierte Felder hinweisen, ohne die Evidenzart zu verraten. Erst nach der Beobachtung von veralteten Daten, Fehlverwendungen und Einwänden wird der Umfang erweitert.

Die gemeinsame Syntax macht Erfahrungen vergleichbar; der lokale Beleg hält Verantwortung und Umkehrbarkeit aufrecht. Der Mindestansatz ist kein Dauerprovisorium. Er verhindert, dass ein früher Versuch ohne ausdrückliche Entscheidung zur globalen Reputationsinfrastruktur wird.

Quellen