Zusammenfassung

  • draft-wei-aic-jwt-01 erschien am 8. September 2026 als aktiver individueller Internet-Draft. Er ist weder angenommene IETF-Arbeit noch freigegebener Standard oder Einsatznachweis; Experimental ist lediglich der vom Autor angestrebte Status.
  • Im vollständigen Profil liegt ein vom Principal signiertes DelegationAuthorization-JWT in einem vom Aussteller signierten AIC-JWT. Innen sind Autorisierung und agent_id geschützt, außen der exakte DA-String und der cnf-Claim.
  • Revision 01 bindet die Delegation im DA an die Agentenidentität. Eine DA-interne Bindung des öffentlichen Agentenschlüssels bleibt einer künftigen Claim-Set-Version vorbehalten; derzeit trägt cnf die Proof-of-Possession-Schlüsselbindung.
  • Ein Agentenschlüssel-Beleg sollte deshalb festhalten, welche Aussage welcher Signierer verantwortet. Das ist Daniel Kades Governance-Vorschlag, keine Forderung des Drafts.

Eine neue Fassung ist noch kein IETF-Beschluss

Die I-D-Mitteilung datiert Revision 01 auf den 8. September um 14:48 UTC. Im Datatracker steht sie unter Individual Submissions mit I-D Exists, ohne RFC-Stream, zuständigen Area Director oder Telechat-Termin. Einen Internet-Draft darf jeder einreichen. „Intended status: Experimental“ bezeichnet das Ziel des Autors, nicht Annahme, Konsens, Genehmigung oder Produktionseinsatz.

Die Änderung verdient dennoch Aufmerksamkeit. AIC-JWT soll das Datenmodell eines gesonderten X.509-AIC-Drafts auf die Anwendungsschicht abbilden. JWT und JWS sind Träger für HTTP-, Web- und OAuth-Umgebungen; sie bestimmen nicht von selbst Fähigkeiten, Delegationsrechte oder lokale Ausführungspolitik.

Der offizielle Vergleich zeigt einen großen Umbau. Das DA-Claim-Set wechselt von Version 1 zu 2, erhält RFC-7523-Felder und muss von 01-Implementierungen bei altem Format geschlossen abgewiesen werden. Zusätzlich benennt der Text eine bisher leicht übersehene Zuständigkeitsgrenze: Der Principal signiert die benannte Agentenidentität, nicht bereits einen im DA enthaltenen Fingerabdruck des Präsentationsschlüssels.

Innen ist die Autorisierung unveränderbar

Im beschriebenen PKI-Ablauf erzeugt der Agent ein Schlüsselpaar und baut einen Antrag mit Fähigkeiten, Delegationsmodus, Bedingungen und Nonce. Der Principal prüft ihn, signiert das DA-JWT und gibt es zurück. Der Agent legt es der CA vor. Im OAuth-AS-Modus wird dasselbe DA als JWT-Bearer-Grant nach RFC 7523 am Token-Endpunkt eingereicht.

Der signierte Inhalt umfasst iss, sub, aud, exp, jti, agent_id, Principal-Bindung, Grund, Fähigkeiten, Modus, Bedingungen, gewünschte Laufzeit, Zeit und Nonce. Der Prüfschlüssel muss zur Principal-Bindung passen; jti muss dem Nonce entsprechen. Die Typen aic+da+jwt und aic+jwt verhindern, dass die innere Delegation als äußerer Token akzeptiert wird.

Der äußere da-Claim enthält exakt die kompakte empfangene Serialisierung. Vor der Prüfung darf sie nicht neu aufgebaut werden. Ändert der Aussteller Fähigkeit, Zielgruppe, Modus oder agent_id, scheitert die Principal-Signatur. Nur mit dem Principal-Schlüssel lässt sich umgekehrt kein gültiger äußerer Token prägen, weil dessen Signatur dem Aussteller gehört.

Damit beweist die innere Prüfung etwas Wichtiges: Dieser Principal hat diese Delegation an die genannte Agentenidentität unter diesen Grenzen signiert. Sie beweist nicht, dass die konkrete Schlüsselkennung aus cnf Bestandteil der vom Principal signierten Bytes war.

Außen wird der präsentierte Schlüssel festgelegt

Der verpflichtende cnf-Claim bindet den Token an einen Proof-of-Possession-Schlüssel. RFC 7800 liefert die Semantik, empfohlen wird ein RFC-7638-JWK-Fingerabdruck in jkt. Bei DPoP muss er zum Proof-Schlüssel passen; bei mTLS kann zusätzlich der Clientzertifikatschlüssel abgeglichen werden.

Revision 01 wiederholt die Abgrenzung in beiden Ausgabewegen. Eine Agentenschlüsselbindung direkt im DA ist für eine spätere Claim-Set-Version vorgesehen. Aktuell wird der präsentierte Schlüssel bei der Nutzung durch cnf gebunden. Da cnf im äußeren Payload liegt, deckt die Signatur des Ausstellers diese Bindung gemeinsam mit dem unveränderten DA ab.

Daraus folgt keine freie Schlüsselwahl des Ausstellers. Im PKI-Ablauf erzeugt der Agent den Schlüssel, der Principal prüft den Antrag. CA oder AS müssen DA-Signatur, Principal-Schlüssel, Audience, Ablauf, Nonce-Einmaligkeit und Grenzen prüfen. Der äußere Token darf den signierten Grant nicht überleben.

Die Differenz betrifft die spätere Rekonstruktion. Zwei gültige Signaturen zeigen, dass der Principal agent_id autorisiert und der Aussteller ein bestimmtes cnf signiert hat. Sie erlauben nicht, die zweite Aussage rückwirkend der ersten Signatur zuzuschreiben. Wurde der Schlüssel dem Principal sichtbar vorgelegt, braucht dieses Ereignis einen eigenen Nachweis.

Auch das Vorhandensein von cnf genügt nicht. Der Sicherheitsabschnitt nennt AIC-JWT nicht inhärent sender-constrained. Ohne tatsächliche Besitzprüfung kann ein gestohlener Token bis zum Ablauf als Bearer Credential funktionieren. cnf nennt den erwarteten Schlüssel; erst eine bestandene DPoP- oder gleichwertige Prüfung dokumentiert seinen Besitz bei der Anfrage.

Ein Beleg trennt Ausgabe, Bindung und Nutzung

Ein belastbarer Agentenschlüssel-Beleg sollte exakten DA-Hash und Version, Principal-Schlüsselkennung, agent_id, Aussteller, äußeren Token-Hash, cnf-Verfahren und Fingerabdruck, Ausgaberichtlinie, Nonce-Verbrauch, effektive Ablaufgrenze, Besitznachweisverfahren und Verifier-Entscheidung enthalten. Eine Schlüsselbestätigung durch den Principal gehört als separates Ereignis hinein.

Zwei Replay-Uhren dürfen nicht verschmelzen. Der DA-Nonce wird bei der ersten Ausgabe verbraucht und darf keinen zweiten äußeren Token erzeugen. Ein bereits ausgegebener Access Token kann innerhalb seiner Laufzeit mehrfach präsentiert werden. Schutz pro Request entsteht durch DPoP-jti oder Vergleichbares. „Nonce verbraucht“ ist kein Nachweis für Einmaligkeit jeder Präsentation.

Der Beleg muss nicht öffentlich sein. Dauerhafte Fingerabdrücke können Beziehungen korrelierbar machen. Geschützte Commitments, Richtlinienergebnisse und Audit-Verweise können die Zuständigkeit bewahren, ohne ein offenes Schlüsselverzeichnis zu schaffen.

Heng Lus Policy Mirror zeigt die Verteilung: Der Principal entscheidet über Identität und Fähigkeiten; der Aussteller akzeptiert den DA und signiert die aktuelle Schlüsselbindung; der Verifier erzwingt Besitz und lokale Regeln; der Resource Owner trägt die Wirkung. Wer alles zu einem Vertrauenssymbol komprimiert, entfernt genau diese Verantwortungsordnung.

Quellen