Zusammenfassung

  • Der Prinzipal signiert eine kompakte Delegation Authorization. In ver=3 enthält sie mit agent_key_binding den SPKI-Hash des Agentenschlüssels; der Aussteller signiert die äußere Hülle mit genau dieser Zeichenfolge.
  • Der cnf-Schlüssel muss zur signierten Bindung passen. Eine gültige äußere Signatur erlaubt keinen Austausch; Verlängerung und Neuausstellung benötigen eine frische DA und Nonce.

Die Schlüsselrotation war technisch erfolgreich und autoritativ gescheitert. Der Aussteller hatte einen gültigen Token mit neuem cnf erzeugt, der Agent bewies den Besitz, doch die innere Delegation nannte den alten Schlüssel. Der Prüfer verwarf die Kombination.

Revision 02 des AI Agent Identity Certificate (AIC) JSON Web Token Profile erschien am 2. Oktober 2026 als aktiver individueller Internet-Draft, mit Informational als beabsichtigtem Status und Ablauf am 5. April 2027. Er ist weder RFC noch IETF-Konsens oder Einsatznachweis. Relevant ist seine Aufteilung der Aussagebefugnis.

Zwei Ebenen bleiben getrennt

Der Prinzipal erstellt und signiert die DA als kompakten JWT. Agent oder Aussteller übernehmen die vollständige Zeichenfolge in den äußeren da-Claim. Die Ausstellersignatur deckt damit die exakte innere Darstellung ab. Der Prüfer darf sie nicht parsen und semantisch gleich neu serialisieren: Geänderte JSON-Reihenfolge oder Kodierung bedeutet andere signierte Bytes. Auditdaten brauchen Original und Digest.

Die innere Signatur belegt die Delegation des Prinzipals; die äußere belegt die Verantwortung des Ausstellers für den Träger. Keine Rolle übernimmt die andere. Beide Schlüssel müssen nach konfigurierter Policy im selben akzeptierten Vertrauensbereich verankert sein. typ trennt außerdem DA, AIC-JWT und Zugriffstoken, damit eine signierte Eingabe nicht als ausgestelltes Ergebnis wiederverwendet wird.

Der entscheidende Schlüsselvergleich

agent_key_binding ist in Version 3 der Hash der DER SubjectPublicKeyInfo des Agentenschlüssels unter dem angegebenen Algorithmus. Weil er in der DA steht, signiert ihn der Prinzipal. Das äußere cnf bindet den Token an den Proof-of-Possession-Schlüssel. Der Prüfer muss Gleichheit verlangen.

Äußere Signatur, innere Signatur und Besitznachweis können einzeln stimmen, obwohl die Gesamtheit unzulässig ist. Genau so werden Fehlzuordnung und Schlüsselsubstitution sichtbar. Version 2 bindet nur agent_id und ist nur mit den beschriebenen Gegenmaßnahmen zulässig; Version 1 ist abzulehnen, neue DAs verwenden Version 3.

kid wählt lediglich aus einem bereits vertrauenswürdigen, richtig abgegrenzten Schlüsselsatz. Auch x5c oder x5t begründen durch bloße Anwesenheit kein Vertrauen. Header sind Wegweiser, keine Vertrauensanker.

Verlängerung braucht neue Zustimmung

Der äußere Zeitraum darf die in der DA verlangte Dauer und deren Ablauf nicht überschreiten. Der Aussteller darf kürzen, nicht verlängern. Die DA-Nonce ist zugleich ihr jti, wird bei Erstausstellung verbraucht und darf keinen zweiten äußeren Token tragen. Dafür ist eine neu signierte DA mit frischer Nonce erforderlich.

Das ist nicht mit Request-Replay zu verwechseln. Ein Zugriffstoken kann während seiner Laufzeit mehrfach verwendet werden; pro Anfrage schützt etwa das jti eines DPoP-Proofs. DA-Digest, Nonce-Verbrauch, ausgegebener Token und Request-Proof benötigen getrennte Belege.

Das vollständige Profil vergleicht außerdem Prinzipal, Fähigkeiten, Delegationsmodus, Einschränkungen sowie subject/actor-Zuordnung. Widersprüche führen zur Ablehnung, nicht zum stillen Umschreiben. Erst danach begrenzt lokale Gateway-Policy die Handlung. Gültige Identität und Autorisierung beweisen weder Ausführung noch externes Ergebnis. Ein leichtes Consumer-Profil darf im genehmigten Niedrigrisikomodus die DA weglassen, besitzt dann aber nicht dieselbe Prinzipalattestierung.