Identität, Registry und Sitzungen

6. Identität, Agent Registry und Sitzungen

6.1 Agent Karten

Die Organization MUST stellen jedes Agent Card aus, überprüfen, versionieren und signieren es. Einem Agent MUST NOT kann nur deshalb vertraut werden, weil es eine Fähigkeit selbst deklariert. Die Agent Card MUST trennen:

stabile Identität, Besitz, Endpunkt, öffentliche Schlüssel und unterstütztes Protokoll Versionen;
Versionierte Organization-gesteuerte Funktionen mit deklarierter Ein-/Ausgabe Schemata, Einschränkungen und Überprüfung Evidence; und
Maximal unterstützte Parallelität.

Fähigkeit ist keine Autorisierung. Ein Agent Card MUST NOT enthält wiederverwendbare Anmeldeinformationen oder gewährt Zugriff auf Tools oder Geschäftsdaten. Die Berechtigung zur Autorisierung und die aktuelle Richtlinie bleiben Organization Entscheidungen.

Zuweisungen MUST die Agent-Card-Version und jede erforderliche Capability-Version fixieren. Ein kompatibles In-Place-Upgrade MAY gemäß Organization-Richtlinie fortgesetzt werden. Ein inkompatibles Upgrade MUST die aktive Arbeit checkpointen und vor der Fortsetzung der Ausführung eine erneute Akzeptanz einholen. Jeder Artifact MUST die erzeugende Agent-Card- und Capability-Version aufzeichnen.

Die Registry SHOULD verwalten funktionsspezifische, kontextbezogene Leistungsdatensätze getrennt von den Agent-Karten. Zu den Datensätzen MAY gehören Abschluss, Fehler, Neuzuweisung, menschliche Änderungsanforderung, Frist, Budget und Ergebnisse des Mietvertragsablaufs. Eine Implementierung SHOULD NOT reduziert die Leistung auf einen undurchsichtigen globalen Reputationswert.

6.2 Anwesenheitsaufzeichnungen

Die Präsenz ist kurzlebig und MUST muss vom stabilen Agent Card getrennt sein. Ein Anwesenheitsdatensatz MAY meldet den Online-Status, die aktuell verfügbaren Ausführungsslots, die Verfügbarkeit von Funktionen, die geschätzte Antwortlatenz und den letzten Herzschlag. Ein veralteter Anwesenheitsdatensatz MUST NOT wird als Auftragsannahme oder Mietvertragsverlängerung behandelt.

Präsenzaktualisierungen MAY werden in authentifizierten PING Frames übertragen und erfordern keine individuelle dauerhafte Signatur. Präsenz MUST NOT legt die Identität, den Inhalt, die WorkItems oder die genaue Warteschlangenposition eines anderen Group offen.

6.3 Authentifizierung und Session Epoch Fencing

Jeder Agent MUST verfügt über mindestens einen Organization-registrierten öffentlichen Ed25519-Schlüssel. Der Handshake v0.1 WebSocket verwendet eine neue Server-Challenge:

Der Agent sendet HELLO/client_init mit seiner Agent-ID, Schlüssel-ID, Nonce und unterstützte Protokollversionen;
Der Server antwortet HELLO/server_challenge mit einer unvorhersehbaren Herausforderung und ausgewählte Version;
Der Agent antwortet HELLO/client_response mit einer Ed25519-Signatur über den kanonisches Challenge-Transkript; und
Der Server antwortet HELLO/server_accept mit einem kurzlebigen Sitzungstoken und ein neu ausgegebenes Session Epoch.

Die Ausgabe von Epoch n + 1 macht jede Session mit Epoch n oder niedriger für diese Agent ID ungültig. Die Group Authority MUST die Session Epoch bei jedem zustandsändernden Agent Command validieren. Menschliche Command und Command von Organization-Diensten tragen keine Agent Session Epoch und MUST NOT eine erfinden. Ein neu gestarteter Runtime MAY seine stabile Agent ID wiederverwenden; zwei Runtime MUST NOT diese Identität gleichzeitig betreiben.

Dauerhafte Befehle und Artifact Manifeste MUST müssen einzeln signiert werden. Heartbeats und Presence Records basieren auf der authentifizierten Sitzung. Langlebige gemeinsame API-Schlüssel sind NOT RECOMMENDED. Eine Implementierung MAY fügt mTLS oder Workload-Identity-Authentifizierung hinzu, vorausgesetzt, sie behält die Agent-ID und die Fencing-Semantik bei.