Zusammenfassung

  • Die IESG-Tagesordnung vom 24. September führt IANA-Vorgang #1451183 weiter: Für drei OAuth-Register sollen benannte Experten gefunden werden. Laut dem am 17. September aktualisierten Aufgabenstand besteht der Punkt seit dem 30. April und seit zehn Telekonferenzen.
  • Das Protokoll vom 30. April spricht ausdrücklich von zusätzlichen Experten. Die aktuellen IANA-Tabellen nennen jeweils Justin Richer. Aus der offenen Aufgabe folgt weder eine leere Stelle noch ein Stillstand der Register.
  • Eine spätere Ernennung muss mit ihrem Geltungsbereich, der veröffentlichten IANA-Expertenliste und einzelnen Prüf- und Registrierungsvorgängen getrennt nachvollziehbar sein.

Ein Register kann einen amtierenden Prüfer nennen und zugleich mehr Prüfer benötigen. Gerade dieser einfache Satz geht verloren, wenn aus der Rubrik „Designated experts needed“ eine Meldung über einen Ausfall gemacht wird. Der IESG-Vorgang wurde am 30. April als Suche nach zusätzlichen Experten besprochen und Deb Cooley zugewiesen. Im OAuth-Parameters-Verzeichnis von IANA steht noch derselbe Name bei Dynamic Client Registration Metadata, Token Endpoint Authentication Methods und Token Introspection Response. Die offene Aufgabe betrifft also die Verstärkung eines bestehenden Verfahrens, soweit die vorliegenden Quellen reichen.

Der Unterschied zwischen den drei Tabellen ist sachlich wichtig. In der ersten werden Metadatenbezeichnungen für die dynamische Anmeldung von Clients geführt. Die zweite enthält Namen von Authentifizierungsmethoden am Token-Endpunkt. Die dritte ordnet Namen für Antworten auf Token-Introspektion, die über einzelne Dienste hinaus verständlich sein sollen. Eine Änderung in einer Tabelle ersetzt weder die anderen noch belegt sie, dass neue Experten für alle drei zuständig sind. Eine spätere IESG-Entscheidung braucht deshalb einen prüfbaren Umfang.

RFC 7591 und RFC 7662 beschreiben für diese Registrierungen eine zweiwöchige Begutachtung über die öffentliche OAuth-Erweiterungsliste und die Rolle der benannten Experten bei IANA-Änderungen. Antrag, Diskussion, Entscheidung und neuer Registereintrag sind unterschiedliche Schritte. Die Dauer der IESG-Personalsuche ist kein Messwert für die Bearbeitungszeit eines Antrags. Auch lässt sich aus dem veröffentlichten Namen weder ein Rückstau noch eine individuelle Versäumnis ableiten. Wer konkrete Verzögerungen behaupten will, braucht die dazugehörigen öffentlichen Vorgänge.

Ein geeigneter Nachweis wäre deshalb kein pauschales „Expertenproblem“, sondern eine Versionskette: IESG-Beschluss mit Datum und betroffenen Registern, Stand der drei IANA-Expertenfelder, gegebenenfalls Antragsfaden, Gutachterentscheidung und veröffentlichte Zeile. Diese Kette ist Daniel Kades redaktioneller Vorschlag, keine neue IETF-Vorschrift. Sie macht sichtbar, ob zusätzliche Kapazität tatsächlich in der öffentlichen Zuständigkeitskarte angekommen ist.

Die Karte hat eine begrenzte Aufgabe. Gemeinsame Bezeichnungen helfen unabhängigen OAuth-Implementierungen, nicht aneinander vorbeizureden. Ein registrierter Name zwingt niemanden, eine Methode einzusetzen, und ein benannter Experte entscheidet nicht über sämtliche Anwendungen. Gerade weil die Einführung lokal bleibt, sollte die zentrale Namensprüfung eng, transparent und überprüfbar bleiben.

Sources