Summary

  • Femi Allas individueller Internet-Draft, Fassung 02 vom 31. Oktober, lässt den Hostnamen eines gesperrten Agenten vergeben. Sein öffentliches Dokument enthält dann nur Version, Sperrstatus und Hostname.
  • Die neue Fassung empfiehlt für das gehostete Verzeichnis der Signaturschlüssel eine erfolgreiche Antwort mit leerer Schlüsselmenge. Ein erneut abfragender Prüfer kann damit seine alten Schlüssel ersetzen.
  • Die Sperre erreicht den Prüfer erst bei seiner neuen Abfrage. Die im Text genannten 60 Sekunden sind die Dokument-Cachezeit einer Referenzimplementierung, keine globale Frist für sämtliche Schlüsselkopien.

Das Schild ist rot. Der Schlüssel liegt noch beim Gast

Ein Anbieter hält für den Betreiber eines Agenten einen öffentlichen Namen vor. Wird die Identität gesperrt, entfernt er aus dem Identitätsdokument die Dienste, Beschreibung, Kontaktangaben und Prüfungen zum Kontoinhaber. Der Name und seine DNS-Einträge bleiben bestehen. So kann ihn niemand anders übernehmen. Wer das Dokument frisch liest, sieht die Sperre. Wer nur einen früher gespeicherten Schlüssel prüft, hat eine andere Akte auf dem Tisch.

Allas The Agent Identity Document: A Hosted, Accountable Public Record for AI Agents trennt zunächst Verwaltungszustand und Erreichbarkeit. Der Status sagt, was Betreiber oder Anbieter mit der Identität entschieden haben. Er sagt nicht, ob der Agent gerade online ist. Ein schlafender Dienst behält seine aktive Identität. Ein gesperrter Name darf weiter auf den Anbieter zeigen. Das öffentliche Register und die tatsächliche Verbindung sind zwei verschiedene Beobachtungen.

Für signierte Anfragen kommt ein zweites Register hinzu: das vom Anbieter bereitgestellte Schlüsselverzeichnis. Das Feld public_key im Identitätsdokument darf der Betreiber selbst setzen; allein hat es keine festgelegte Bedeutung für die Signaturprüfung. Die Fassung 02 empfiehlt nun, nach einer Sperre eine Anfrage an das Schlüsselverzeichnis mit Erfolg und einer leeren Menge zu beantworten. Bei einem Verbindungsfehler könnte der Prüfer die alten Schlüssel aus seinem Cache behalten. Eine gültige leere Antwort gibt ihm dagegen einen neuen Zustand, sobald er erneut fragt.

Anhang B führt diese Regel als Änderung gegenüber Fassung 01 auf. Der Entwurf beschreibt, dass seine Referenzimplementierung so handelt. Er misst nicht, wann fremde Prüfer ihre Caches tatsächlich erneuern. Auch eine Kontosperre soll laut Text alle Zugangsdaten des Kontos stoppen und dessen Identitäten sperren. Der Anbieter kann diese Schritte ausführen; die Uhr eines Empfängers gehört ihm nicht.

Im IETF Datatracker steht Fassung 02 als aktiver individueller Internet-Draft, nicht als angenommener RFC. Für einen konkreten Einsatz braucht man drei Belege: den Zeitpunkt der Sperre, die erfolgreiche leere Antwort des Schlüsselverzeichnisses und die Entscheidung des Prüfers nach seiner neuen Abfrage. Ohne den dritten Beleg weiß das rote Statusschild nur, was der Anbieter wollte.

Amtliche Originale