Zusammenfassung

  • Der individuelle Entwurf Capability Language Core vom 27. September führt allow_unresolved als eigenständiges Ergebnis für noch ungeprüfte Bedingungen ein.
  • Die Ausführung darf erst nach Prüfung sämtlicher Restauflagen folgen. Drei Implementierungen desselben Autors belegen noch keine unabhängige Interoperabilität.

Eine Berechtigung kann zugleich präzise und unvollständig geprüft sein. Der Agent erhält beispielsweise eine Operation, die nur aus einem bestimmten Netz und zu einer bestimmten Zeit ausgeführt werden darf. Ein allgemeiner Entscheidungskern erkennt die Angaben, verfügt aber nicht notwendig über die aktuelle Netzwerkbeobachtung oder die lokale Auslegungsregel. Wer aus dieser Lage ein schlichtes Ja macht, erweitert die Berechtigung im Vollzug. Jijie Weis neuer Entwurf will genau diesen Zwischenschritt ausdrücklich sichtbar halten.

draft-wei-capability-language-core-00 trägt das Datum 27. September 2026 und ist ein persönlicher Internet-Draft mit angestrebtem Experimental-Status. Der IETF-Datatracker führt I-D Exists und betont, dass die Einreichung keine formelle Stellung im Standardisierungsprozess besitzt. Weder RFC-Status noch Arbeitsgruppenübernahme, Markteinsatz oder ein konkreter Sicherheitsvorfall lassen sich daraus ableiten. Der Text definiert eine mögliche gemeinsame Semantik für Fähigkeitsnamen, die Abdeckung einer Operation durch eine Erlaubnis, die Schnittmenge mehrerer Erlaubnisse und deterministische Entscheidungsgründe.

Die entscheidende Unterscheidung steht in Abschnitt 8.4. Zeit- und Netzwerkbedingungen, deren Form der v1-Kern kennt, aber nicht selbst beurteilen kann, bleiben als Restauflagen in unresolved erhalten. Das Urteil lautet dann allow_unresolved und ausdrücklich nicht allow. Es ist also keine Freigabe mit Fußnote. Die Stelle, die das Ergebnis verbraucht und die Aktion tatsächlich zulässt, muss jede offene Bedingung auswerten oder bestätigen; gelingt das nicht, muss sie ablehnen. Mehrere Auflagen gelten zusammen. Die erste bestätigte Auflage hebt die übrigen nicht auf.

Mit Resolve beschreibt der folgende Abschnitt eine Rückmeldung je Auflage: erfüllt, verletzt oder unbekannt. Der Kern berechnet damit eine neue Entscheidung. Diese Rückkopplung ersetzt weder ein vertrauenswürdiges Netzsignal noch eine belastbare Zeitregel. Ein Adapter, der alle Ergebnisse außer deny auf einen booleschen Ausführungswert abbildet, würde die gerade definierte Trennung verlieren. Das ist ein aus der Spezifikation abgeleitetes Integrationsrisiko, kein Nachweis einer schon vorhandenen Schwachstelle.

Der Entwurf beansprucht auch nicht, die gesamte Sicherheitskette zu ordnen. Wer eine Erlaubnis ausstellen darf, wie das ursprüngliche Artefakt kryptografisch geprüft wird, ob eine Aktion anschließend wirklich stattfand und wie ein Beleg aussieht, liegt außerhalb seines Kernbereichs. RFC 9396 hat für OAuth bereits das Feld authorization_details festgelegt. CLC nennt es als möglichen Träger, nicht als bestehenden CLC-Standard. Ein passendes Datenformat ist noch keine Prüfung des Ausstellers und erst recht kein Beweis des Ergebnisses.

Für die Autorisierungsseite meldet das Dokument 123 Testvektoren und 1184 Eigenschaftsfälle; Go-, Python- und TypeScript-Programme desselben Autors bestehen sie. Der Entwurf selbst nennt diese Übereinstimmung einen Regressionstest und nicht unabhängige Bestätigung. Seine Reifeschwelle von zwei voneinander unabhängigen Implementierungen ist unerfüllt. Die Basisklasse CLC-A wird beansprucht, die Evidenzklasse CLC-E nicht. Das sollte die Bewertung nüchtern halten: ausgearbeitete Regeln sind ein Fortschritt, aber noch kein gemeinsamer Betriebsnachweis.

Quellen