Zusammenfassung

  • RFC 9560 erlaubt RDAP-Servern, Nutzer über OpenID Connect und OAuth zu identifizieren und Bearer Tokens zu prüfen, ohne bei jedem Dienst eigene Zugangsdaten anzulegen.
  • Optionale Zweck- und Do-not-track-Claims sind Eingaben für lokale Regeln. Sie beweisen weder Motiv noch Abfragerecht, lückenlose Nichtprotokollierung oder Qualität der Registerdaten.
  • Eine belastbare Spur verbindet die Tokenprüfung mit Richtlinienversion, Abfragezweck, offengelegten Feldern, Herkunft des Ausgangsdatensatzes und späterem Ermittlungsergebnis.

Das Bearer Token wurde akzeptiert. Aussteller, Zielgruppe, Ablaufzeit und Struktur reichen dem Server aus, um fortzufahren. Das ist ein präziser technischer Befund. Ungenau wird es oft im nächsten Satz: Aus „authentifizierter Nutzer“ wird „berechtigte Abfrage“, aus einem erlaubten Zweck ein wahrer Beweggrund und aus der Antwort eine bestätigte Wirklichkeit. RFC 9560 vollzieht keinen dieser Sprünge.

Der im April 2024 auf dem IETF Standards Track veröffentlichte RFC 9560 führt föderierte Authentifizierung in das Registration Data Access Protocol ein. Clients entdecken unterstützte OpenID Provider und arbeiten sitzungs- oder tokenorientiert. Die gemeinsame Schicht reduziert lokale Konten; die Zugriffspolitik verbleibt beim einzelnen RDAP-Server.

Authentifizierung beantwortet genau eine Frage

Bei einer tokenorientierten Abfrage muss der Server das Token nach lokaler Richtlinie prüfen und als legitimes Access Token bestätigen. Er kann RFC-7662-Introspektion oder JWT-Analyse verwenden. Die Audience zählt: Ein für eine andere Relying Party ausgestelltes Token kann abgelehnt werden; RFC 8693 bietet einen Austausch auf eine passende Audience.

Damit steht fest, dass der Server sich in dieser Interaktion auf den Nachweis stützen will. Noch nicht fest steht, welche Daten die Identität sehen darf. Nach der Validierung wertet der Server Claims aus, bestimmt das Berechtigungsniveau und entscheidet je Abfrage. Ablehnung, Auslassung, Schwärzung und Offenlegung sind getrennte Ergebnisse.

Ein zugeteilter Zweck ist kein Beweis innerer Absicht

Der optionale Claim rdap_allowed_purposes enthält Zwecke, die eine Identität geltend machen darf. Der Identity Provider darf sie nur berechtigten Identitäten zuteilen. Mit farv1_qp nennt der Client den Zweck der konkreten Abfrage; liegt er nicht im erlaubten Satz, muss der Server 403 liefern.

Die Regel ordnet den Zugriff, liest aber keine Gedanken. Eine Zweckkategorie zu besitzen, sie jetzt anzugeben und die Daten später in ihrem Rahmen zu verwenden sind drei Tatsachen. Widersprechen Claim und Parameter der lokalen Richtlinie, darf der Server beide ignorieren. Fehlt farv1_qp, bleibt die Pflicht zur Zugriffsentscheidung anhand anderer Informationen bestehen.

Ein Dienstausweis kann den Beschäftigten identifizieren und eine Tür öffnen. Er belegt nicht den Grund des Eintritts, die Notwendigkeit jeder Akte oder deren spätere Verwendung. Genau diese Grenze hält föderierte Identität überprüfbar.

Do not track tauscht eine Zusicherung gegen eine andere

rdap_dnt_allowed kann verlangen, die Zuordnung zwischen Identität und Abfrage nicht aufzuzeichnen. Voraussetzung sind Identifikation, Berechtigung, der Wert true und Vereinbarkeit mit lokalen Protokollregeln. Der RFC benennt die Grenze offen: Das Versprechen hängt vom guten Willen des Servers und seiner Proxys sowie von außerbandlichem Vertrauen ab; Informationsverlust kann die Auditierbarkeit ernsthaft beeinträchtigen.

Sensible Ermittlungen können diese Vertraulichkeit brauchen. Dann sind Vergabestelle, abgedeckte Zwischenstationen, Ersatznachweis und Ablaufdatum festzulegen. „Do not track akzeptiert“ ist ein Richtlinienereignis, kein kryptografischer Beweis, dass nirgendwo eine Verknüpfung gespeichert wurde.

Auch die Antwort trägt eine Beweislast

farv1 meldet Konformität mit der Erweiterung, nicht Wahrheit des zugrunde liegenden Registers. Eine technisch korrekte Antwort kann nur ein richtlinienbedingter Ausschnitt sein. Der Ausgangsdatensatz hat eigenes Aktualisierungsdatum, Prüfverfahren, Korrekturen und Mehrdeutigkeiten. HTTP 200 beweist weder Vollständigkeit noch Nutzen; HTTP 403 kein Fehlverhalten.

Die minimale gemeinsame Schicht soll Discovery, Tokenbehandlung, Claim-Namen und Parameter standardisieren. Sie soll keine weltweite Einheitlichkeit rechtmäßiger Zwecke, Offenlegungsschwellen oder Ermittlungsergebnisse vortäuschen. In Lu Hengs Realitätsschichten sind Identität, Token, Zweckprivileg, Entscheidung, offengelegter Datensatz und reales Ergebnis jeweils wirklich — aber keines erbt automatisch die Beweiskraft des nächsten.