Summary

  • draft-saha-aadp-bound-permit-00 vom 29. September schlägt einen kurzlebigen Permit vor, der eine zustandsabhängige AADP-Entscheidung über eine Vertrauensgrenze trägt und an einen Empfänger, einen Presenter-Schlüssel, eine HTTP-Anfrage und eine konkrete Aktionsinstanz bindet.
  • Der Permit ist kein übergeordneter Befehl. Ein referenziertes Mandat muss dieselbe Transaktion selbständig erlauben, die lokale Policy behält ihr Veto, und die Aktualität der Entscheidung muss feststehen. Keine Ebene darf eine andere erweitern.
  • (iss, jti) wird erst nach allen anderen Prüfungen atomar verbraucht. Gleiche Wiederholungen können das gespeicherte Ergebnis erhalten; einen externen exactly-once-Effekt garantiert das Profil nicht.

Der fehlende Zustand liegt beim Absender

Ein Agent beantragt eine Zahlung über 40 Euro. Der PDP des Absenders kennt kumulierte Ausgaben, laufende Reservierungen, auslaufende Freigaben, frühere Ausführungen und den Kill Switch. Aus diesem Zustand folgt permit. Der entfernte Zahlungsdienst besitzt dieses Buch nicht und kann die Entscheidung bei Eingang nicht wiederholen.

Workload-Identität beantwortet, wer anruft. Ein Mandat beschreibt, wozu der Agent delegiert wurde. Beides sagt nicht, ob genau diese 40 Euro im Moment der Entscheidung noch im Budget lagen. Kommt die Anfrage mit 40,01 Euro an, reicht eine gültige JWT-Signatur nicht.

Diese schmale Lücke behandelt Shamik Sahas erster Action-Bound-Permit-Entwurf. Es ist ein aktiver individueller Internet-Draft, dessen Kopf Standards Track als beabsichtigten Status nennt. Er ist kein RFC, kein IETF-Konsens, kein Working-Group-Produkt und kein Einsatznachweis.

Das Objekt ist ein Umschlag für eine nicht fern rekonstruierbare Entscheidung, kein allgemeines Autorisierungssystem zwischen Unternehmen.

Eine Entscheidung mit fünf Grenzen

Der Permit ist ein kompakter JWS-JWT mit exakt typ: aadp-permit+jwt. aud nennt nur einen Empfänger; mehrere Audiences führen zur Ablehnung. cnf.jkt legt den Proof-of-Possession-Schlüssel des Presenters fest. Die HTTP Message Signature muss unter genau diesem Schlüssel verifizieren. Ohne diese Prüfung wäre der Permit ein Bearer-Token, was der Entwurf über Vertrauensgrenzen hinweg verbietet.

Die Signatur umfasst mindestens Methode, Authority, Pfad, Query, Content-Digest, Idempotency-Key und das Permit-Feld. Der Empfänger berechnet Content-Digest über die tatsächlich empfangenen Bytes, bevor Parser oder erneute Serialisierung eingreifen. Zwei semantisch gleiche JSON-Dokumente können dadurch auf der Leitung verschieden sein und abgelehnt werden.

Die Semantik wird getrennt gebunden. Für jeden registrierten Aktionstyp ist festgelegt, wie Objekt A aus Pfad, Query und Body entsteht. Der Empfänger kanonisiert A nach RFC 8785, verwendet den Domain Separator und vergleicht action_digest. Gleiche Bytes retten keine abweichende Ableitung von Betrag, Empfänger oder Sequenz; gleiche Bedeutung entschuldigt keine veränderten Bytes.

Zeit ist die fünfte Grenze. exp darf execute_within nicht überleben. Fehlt diese AADP-Obligation, beträgt die maximale Spanne 120 Sekunden. Die dokumentierte Uhrtoleranz ist auf 60 Sekunden begrenzt und verlängert die sachliche Deadline nicht.

Ein Empfänger, ein Schlüssel, eine Anfrage, eine Aktion, ein kurzes Intervall: Der Permit soll gerade nicht komfortabel weiterverwendbar sein.

Scope statt Vertrauensliste

Ein flaches Verzeichnis vertrauenswürdiger Aussteller lässt jeden eingetragenen PDP alles genehmigen, was die lokale Policy versehentlich nicht stoppt. Der Entwurf ersetzt es durch eine Tabelle aus Schlüsseln, Aktionstypen, feldweisen Limits, Ablaufdatum und minimalem Currentness-Modus.

Jeder Eintrag in authorization_details muss in diesen Scope fallen. Ein Aussteller für payments.transfer/1 mit einem Maximum von EUR 1.000,00 ist nicht automatisch für Account-Löschung oder EUR 10.000 zuständig. Die Ablehnung nennt Eintrag und Feld, ohne das interne Limit offenzulegen.

Selbst innerhalb des Scope bleiben drei Vetos. Erstens müssen Permit und Request Binding verifizieren. Zweitens muss ein referenziertes Mandat die gleiche Transaktion erlauben. Drittens muss die Empfänger-Policy zustimmen.

Das vorgeschlagene Agent Authorization Envelope beschreibt Delegation. Der Bound Permit beschreibt eine aktuelle zustandsabhängige Entscheidung. Der Empfänger wertet das AAE selbst aus, vergleicht den Digest und lehnt bei DENY, PENDING, Mismatch oder nicht verfügbarem Pflichtmandat ab. Ein Permit macht aus PENDING niemals PERMIT.

Auch danach kann der Zahlungsdienst wegen Betrug, Kontostatus, Sanktionen oder eigener Betriebsgrenzen ablehnen. Eine fremde Signatur beweist eine fremde Entscheidung; sie kommandiert nicht die Organisation, die die Wirkung trägt.

Aktuell genug ist eine Risikowahl

Zwischen Unterschrift und Empfang können Policy oder Mandat widerrufen werden. Eine kurze Laufzeit begrenzt, aber erkennt dieses Fenster nicht. Deshalb trägt jeder Permit einen Currentness-Modus.

time-bounded nimmt den Permit bis exp als aktuell an. Der Empfänger akzeptiert das nur für konfigurierte Aussteller-/Aktionspaare. status-checked verlangt im Prüfzeitpunkt eine Aussage, dass Permit, policy_version und Mandat nicht widerrufen oder ersetzt sind, über eine Statusliste oder ein frisches signiertes Statement.

Unerreichbarer Endpoint, unlesbare Antwort oder altes Statement ergeben regulär status-unavailable. Ein Fail-open muss lokal, ausdrücklich, auditiert und auf eine zulässige Niedrigrisikoklasse beschränkt sein. Diese Ausnahme gehört in den Datensatz und darf nicht als gewöhnliches „Token gültig“ erscheinen.

Lu Hengs Reality Layers trennen die Behauptungen sauber. Der Permit repräsentiert eine frühere Entscheidung. Die Statusprüfung ist eine spätere Beobachtung. Der externe Effekt ist nochmals eine andere Wirklichkeit. Der Betrieb muss sie verbinden, darf sie aber nicht gleichsetzen.

Erst prüfen, dann atomar verbrauchen

Der Entwurf schreibt dreizehn Stufen vor: Struktur, Aussteller und Signatur, Audience, Zeit, Aktionstyp, Aussteller-Scope, Body-Digest, Presenter-Signatur, semantische Aktion, Currentness, Mandat, lokale Policy und erst zuletzt der atomare Verbrauch von (iss, jti). Danach beginnt der Effekt.

So kann eine kaputte oder falsch adressierte Anfrage keinen gültigen Einmal-Permit verbrennen. Auch ein lokales Veto verbraucht ihn nicht. Fällt der Consume Store aus, lautet der Zustand could-not-check; eine Infrastrukturstörung ist keine Freigabe. Ohne dauerhaften, atomaren und über alle Serving Nodes geteilten Store darf ein Empfänger das Profil nicht akzeptieren.

jti ist nicht die interne AADP-permit_id. Beide werden unabhängig und nicht voneinander ableitbar geprägt. Der Absender bewahrt die Zuordnung, aber nur jti überschreitet die Grenze und wird zum Idempotency-Key. Eine interne Lifecycle-ID soll nicht nebenbei Credential-Bedeutung erhalten.

Beim ersten Mal wird verbraucht, ausgeführt und das Ergebnis gespeichert. Dieselbe Kombination mit demselben Content Digest liefert später das gespeicherte Resultat, ohne zweiten Effekt. Derselbe Schlüssel mit anderem Body ist ein idempotency-conflict; während des ersten Laufs folgt eine retryable Antwort.

Das ist trotzdem kein exactly once. Geht die Antwort verloren, darf der Presenter keinen neuen Permit anfordern und nochmals senden. Er meldet Timeout, gleicht über jti oder recipient_action_id ab und eskaliert bei ungeklärtem Ausgang. Idempotenz kontrolliert Wiederholungen, sie beseitigt keine reale Unsicherheit.

Drei Signaturen, drei Aussagen

Nach Verbrauch und Effektversuch signiert der Empfänger eine Confirmation. Sie referenziert Permit, Request-Digest, Digest der Signature Base, Action Digest, gegebenenfalls Mandatsurteil, Outcome und lokale Action-ID. Der Presenter schreibt ihren Digest als Nachweis für present_bound in den AADP-Report.

Der PDP signiert: Diese Entscheidung wurde getroffen. Der Presenter signiert: Dies ist die gesendete Anfrage. Der Empfänger signiert: So habe ich sie behandelt. Eine signierte Ablehnung kann failure mit no_effect: true tragen. Eine unsignierte Fehlermeldung beweist nicht, dass nichts geschah; ohne Confirmation bleibt das Ergebnis Timeout.

Das Profil endet nach einem Hop. Ein parent-Claim muss als chained-permit-unsupported zurückgewiesen werden. Muss B anschließend C anrufen, trifft B eine neue Entscheidung unter seinem Zustand. Eine Upstream-Referenz ist Herkunftsnachweis, niemals Autorität oder Grund, C-Prüfungen wegzulassen.

Minimum Initial Specification heißt hier: Nur die Bindungen und Refusal-Semantik gemeinsam festlegen, die beide Seiten für denselben Versuch brauchen. Auswahl der Aussteller, Risiko und lokale Wirkung bleiben bei den Beteiligten. Interoperabilität soll Differenzen sichtbar machen, nicht einen Domain-Souverän einsetzen.

Zwei Lücken im Referenzstand

Der Draft nennt einen unveränderlichen Commit im öffentlichen onedoor-Repository. Das Manifest enthält 24 Vektoren, die Traceability Map markiert 22 als implementiert. V17 — eine ersetzte Policy im Modus status-checked — und V22 — eine Confirmation mit falschem Request Digest — sind als Gaps deklariert. Der Text berichtet außerdem 92 bestandene Permit-Tests.

Das ist reproduzierbare, aber autorennahe Evidenz. Die Commit-Nachricht beschreibt andere Repository-Pflege und keine Permit-Veröffentlichung; unabhängige Interoperabilität oder Produktionsergebnisse fehlen. Running-Code Primacy verlangt, die Vektoren einschließlich der zwei Lücken unabhängig auszuführen und Abweichungen zu veröffentlichen. Ein Snapshot ist keine Normungsabstimmung.

Quellen und Grenzen

Die Quellen belegen einen aktiven individuellen Vorschlag, seine Abhängigkeiten und einen autorennahen Implementierungsstand. Sie belegen keinen IETF-Konsens, RFC, unabhängige Interoperabilität, sicheren Betrieb, richtige Policy, ehrlichen Empfänger oder exactly-once-Effekt. Dieser Artikel besitzt nur die These von Revision 00: eine zustandsabhängige AADP-Entscheidung als einmaligen, an Empfänger, Presenter, Anfrage und Aktion gebundenen Versuch zu transportieren und mit einer signierten Antwort des Empfängers zu schließen.