Zusammenfassung

  • draft-vandemeent-ains-discovery-02 nimmt trust_score und min_trust aus dem normativen Pfad. Föderierte Register übertragen typisierte Belege und Routenlage; jedes Ziel bewertet sie mit eigener, benannter Politik.
  • Signaturen, Sequenzen und Merkle-Nachweise belegen Herkunft, Reihenfolge und Unverändertheit. Sie beweisen weder rechtmäßige Namensinhaberschaft noch tatsächliche Fähigkeit, aktuelle Eignung, Zulassung oder Befugnis.

Ein Agentenverzeichnis wird gefährlich, sobald seine Suchantwort wie eine Erlaubnis aussieht. AINS schlägt logische Namen, HTTPS-Auflösung, Endpunkte, Fähigkeiten, Identitätsverweise und Belege vor. Die am 24. September 2026 veröffentlichte Fassung -02 ist vor allem deshalb relevant, weil sie ein transportierbares Vertrauensurteil aus dem gemeinsamen Protokoll entfernt.

Das Dokument ist ein individueller Internet-Draft mit informativem Ziel. Es ist kein RFC, nicht von einer Arbeitsgruppe angenommen und kein IETF-Konsens. Die geprüften Quellen belegen keinen produktiven Einsatz. Gegenstand ist daher eine überprüfbare Entwurfsgrenze, nicht die Bilanz eines bestehenden Systems.

Der neue Text trennt Beleg, Routenlage und lokale Bewertung. Ein Beleg ist ein prüfbares Objekt oder ein Verweis zu Identität, Prozess, Verhalten oder Empfang. Routenlage beschreibt Reichweite, Frische, Providerrolle und Beobachtungsumfang. Lokale Bewertung ist das Ergebnis einer bestimmten Richtlinie für eine bestimmte Interaktion. Zulassung und Wirkung folgen später.

Diese Dinge dürfen nicht beim Replizieren ihre Bedeutung wechseln. Ein Nonce in einem fremden Konto belegt momentane Kontokontrolle, nicht dauerhaftes Subjekt oder Mandat. Erreichbarkeit ist keine Zustimmung. Eine gültige Signatur macht eine Fähigkeitsangabe nicht wahr. Die positive Meinung eines Registers ist keine allgemeine Handlungsbefugnis.

Im Föderationsmodell führt jedes Ursprungsregister ein signiertes, nur ergänzbares Änderungsprotokoll. Peers prüfen Signaturen, monotone Sequenzen und Herkunft. Optionale Merkle-Inklusionsnachweise können zeigen, dass eine Mutation in einem zugesagten Verlauf enthalten ist und die Vergangenheit nicht still verändert wurde.

Das ist belastbare Verwahrung, aber keine Wahrheitsmaschine. RFC 9162 zeigt bei Transparenzprotokollen, dass Inklusion und Konsistenz Fehlverhalten sichtbar machen können, ohne jede eingereichte Behauptung zu legitimieren. RFC 9421 verlangt auch bei HTTP-Signaturen eine eigenständige Entscheidung über Schlüssel, Algorithmus, abgedeckte Komponenten, Frische und Replay-Schutz.

Die Kollisionsregel ist dafür ein guter Test. Beanspruchen zwei Ursprünge denselben Namen, behält AINS den Datensatz mit dem frühesten registered_at, protokolliert ein Sicherheitsereignis und verbietet stilles Überschreiben. Das lässt Repliken konvergieren. Es entscheidet kein Eigentum. Auch ein Squatter kann zuerst registriert haben; registerübergreifende Reservierung bleibt Zukunftsarbeit.

Eine ehrliche Oberfläche muss deshalb beide Ansprüche und den Auswahlgrund zeigen. Wenn „frühester Zeitstempel“ als grünes Verifikationszeichen erscheint, wird eine mechanische Konfliktregel zu institutioneller Stellung umgedeutet.

Auch „Multi-Channel Verification“ ist enger als der Name. Der Entwurf verlangt einen frischen Code auf mindestens einem externen Kanal. Ein Kanal ist nicht mehrere. Kontrolle über Social-Media-Konto, Repository oder DNS-Eintrag ist kein Organisationsmandat. Weitere unabhängige Kanäle können lokale Sicherheit erhöhen, erteilen aber keine spätere Erlaubnis.

Identische Belege dürfen daher zu verschiedenen Entscheidungen führen. Eine Bank und ein soziales Netzwerk tragen unterschiedliche Schäden. Verantwortlich wird die Abweichung, wenn beide Richtlinien-ID, Version, Eingaben, Frische, Geltungsbereich und Ablehnungsgrund festhalten. Ein portabler Score würde diese Verantwortung verdecken.

Auch der informative Vergleich im Draft ist nur eine Autorenbehauptung. Er schreibt A2A fehlende kryptografische Verifikation zu. Die aktuelle offizielle A2A-Spezifikation erlaubt jedoch JWS-signierte Agent Cards, definiert Kanonisierung und empfiehlt die Prüfung mindestens einer Signatur vor Vertrauen. AINS kann ein anderes Föderationsmodell anbieten, aber keine Notwendigkeit mit einem veralteten Nachbarbild beweisen.

Macht kann über andere Felder zurückkehren. core, verified, sandbox und reserved wirken in einer Benutzeroberfläche schnell wie Statusklassen. Ursprungsregister und Protokolle derselben Entwurfsfamilie können zu faktischen Zugangsschranken werden. Eine treue Implementierung lässt Nutzer solche Labels ignorieren, Originalbelege selbst prüfen und den Bewerter austauschen.

Datenschutz wird nach der Replikation schwer rückholbar. Öffentliche Datensätze können Endpunkt, Fähigkeiten, Route und Verlaufsverweise offenlegen. Ein Tombstone dokumentiert den Löschwunsch, löscht aber keine exportierte Kopie. Referenz statt Kopie, Aufbewahrung, Cache-Ablauf, Offenlegung der Replikate und selektive Ausgabe müssen vor der Registrierung geklärt sein.

Lu Hengs dünne Koordinationsschicht setzt die Grenze passend: gemeinsame Syntax, deterministische Gültigkeit, Ursprungssignatur, portables Format und sichtbarer Konflikt; Eignung, Risiko, Geschäftserlaubnis und Adoption bleiben lokal. Das Register beschreibt einen Zustand. Es erzeugt durch Eintragung keine Autorität.

Ein Betreiber sollte sechs getrennte Belege bewahren: exakte Discovery-Antwort, Logposition und Frische, unabhängige Einzelprüfungen, Routenbeobachtung, lokale Richtlinie samt Urteil sowie spätere Zulassung, Ausführung und Ergebnis. Wer daraus wieder eine Zahl macht, hebt die wichtigste Korrektur von -02 auf.

Quellen