Zusammenfassung

  • Revision 02 ersetzt ein einzelnes Bewertungsobjekt durch eine Ergebnisliste und verlangt für jeden Eintrag Schema und Aussteller-URI.
  • Die URI benennt den zugeschriebenen Prüfer; sie belegt weder Urheberschaft noch unveränderte Weitergabe noch die Güte der Methode.
  • Automatisierung muss Subjekt, Schema, Aussteller, veröffentlichenden Server, Zeit, Status und Beleg gemeinsam behandeln.

Eine farbige Zahl neben einem Domainnamen wirkt wie ein fertiges Urteil. Genau gegen diesen Bedeutungsüberschuss richtet sich draft-bertoldi-regext-rdap-reliability-scoring-02, eingereicht am 6. September. Die Revision fügt nicht bloß ein Feld hinzu. Sie versucht, die Macht der Darstellung auf das tatsächlich Nachweisbare zu begrenzen.

Aus reliabilityScoring wird reliabilityAssessment. Das Einzelobjekt weicht dem Array reliabilityAssessment_results, in dem mehrere Aussteller und Methoden nebeneinander stehen können. scoreScheme und scoreIssuer werden Pflicht; hinzu kommen Gültigkeitshorizont, Ergebniskennung und die Zustände aktiv, in Prüfung und zurückgezogen. Eine bekannte Implementierung gibt es laut Autoren noch nicht.

Zuschreibung ist keine Herkunftssicherung

Der Entwurf trennt Identität, Vertrauen und Authentizität. Identität beantwortet, wem das Ergebnis zugeschrieben wird. Vertrauen beschreibt den Grund, dieser Stelle zu folgen. Authentizität belegt, dass die Aussage tatsächlich von ihr stammt und unverändert ankam.

scoreIssuer liefert die erste Eigenschaft. Die URI muss global eindeutig und stabil sein und soll unter Kontrolle des Ausstellers stehen. Sie ist jedoch keine Signatur des Ergebnisses. Vertrauen bleibt außerhalb des Protokolls; eine signierte Bewertung wird ausdrücklich vertagt.

Auch HTTPS überbrückt diese Lücke nicht. RFC 7481 authentisiert den antwortenden Server und schützt die Übertragung. Damit lässt sich der liefernde Endpunkt bestimmen, nicht die Urheberschaft eines im JSON genannten Dritten. Transportintegrität und sachliche Richtigkeit sind verschiedene Garantien.

Drei Veröffentlichungswege, drei Kontrolllagen

Vorgesehen sind der eigene RDAP-Dienst des Prüfers, die Weiterveröffentlichung durch Registry, Registrar oder anderen Server sowie die Selbstbewertung. Die Datenstruktur kann gleich aussehen, obwohl die Vertrauenskette wechselt.

Beim eigenen Dienst lassen sich Endpunkt und Prüfer gemeinsam konfigurieren. Bei der Weiterveröffentlichung muss der Nutzer dem Prüfer und dem Vermittler vertrauen; aus der Antwort allein sind ihre Rollen nicht beweisbar. Bei der Selbstbewertung kann die Zuschreibung stimmen, während der Anreiz zur günstigen Darstellung besonders groß ist.

Deshalb nimmt der Entwurf Bewertungsdienste nicht in den Bootstrap nach RFC 9224 auf, der autoritative Registrierungsdatendienste auffindbar macht. Auch ein gewöhnlicher Verweis vom autoritativen Server wird verworfen, weil er als Empfehlung des Prüfers erscheinen könnte. Auffindbarkeit ist keine Anerkennung.

Ohne Kontext verliert die Zahl ihre Bedeutung

Die Reihenfolge im Array bedeutet weder Vorrang noch Autorität noch Aktualität. Eine Sieben ist über zwei Schemata hinweg nicht automatisch vergleichbar. validUntil beendet die Zusicherung der Aktualität, erklärt die frühere Aussage aber nicht rückwirkend für ungültig. Fehlender Status bedeutet nicht aktiv. Zurückgezogene Ergebnisse dürfen sichtbar bleiben, damit Cache-Nutzer den Rückzug erkennen. Fehlt das ganze Feld, folgt daraus weder bestanden noch nicht bewertet.

Die eigentliche Entscheidungseinheit ist ein Tupel aus gebundenem Subjekt, Schema, Aussteller, publizierendem Endpunkt, Ergebnis-ID, Datum, Gültigkeit, Status und gesichertem Beleg.

Auch die Subjektbindung ist noch ungleich. Domains sind über ldhName abfragbar. Bei Registraren nutzt der Bewertungsdienst einen lokalen Handle; die IANA Registrar ID erscheint erst nach der Abfrage in publicIds. Wer nur diese ID kennt, kann die Anfrage nicht innerhalb des Protokolls konstruieren. RFC 8521 wird als offene Möglichkeit erwähnt, und für ccTLD-Registrare bleibt die Zuordnung ungelöst.

Verfahrensschutz ohne angemaßte Richterrolle

Ein zur RDAP-Veröffentlichung bestimmtes Schema muss ein Offenlegungs-Bedrohungsmodell dokumentieren, die bewertete Partei vorab informieren, eine Frist für Behebung oder Einspruch gewähren, Daten minimieren und eine Veröffentlichung auf Domainebene eigens rechtfertigen. Eine schlechte Bewertung kann sonst zur Aufklärungsliste für Angreifer werden.

Dauer, Spruchkörper, Governance und Folgen eines erfolgreichen Einspruchs legt der Entwurf nicht fest. Diese Entscheidungen gehören zum jeweiligen Verfahren. Ein gemeinsames Transportformat darf einen Streit sichtbar machen, erhält dadurch aber keine Entscheidungsgewalt.

Revision 02 verdient Anerkennung für diese Selbstbegrenzung. Ergebnisse sind Informationen, keine Zertifikate oder Vollstreckungsinstrumente. Hohe Werte garantieren keine Fehlerfreiheit, und eine evidenceUri kann sich ändern oder verschwinden. Das Feld wird nützlich, wenn es Anspruch und Beweis trennt.

Quellen

  1. IETF-Datatracker-Eintrag
  2. RDAP-Entwurf, Revision 02
  3. RDAP-Entwurf, Revision 01
  4. RFC 7480
  5. RFC 7481
  6. RFC 8521
  7. RFC 9082
  8. RFC 9083
  9. RFC 9224
  10. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  11. On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile
  12. Running-Code Primacy