Summary

  • draft-saha-aadp-bound-permit-00, posted on 29 September, proposes a short-lived permit that carries one stateful AADP decision across a trust boundary and binds it to one recipient, one presenter key, one HTTP request and one concrete action instance.
  • The permit is only one part of a conjunction. The referenced mandate must independently permit the request where present, the recipient's local policy must permit it, and currentness must be established. No layer can enlarge another.
  • The recipient consumes (iss, jti) atomically only after every other verification succeeds. This collapses safe retries but does not guarantee exactly-once external effect; unknown outcomes must be reconciled rather than retried under a newly minted permit.

The extra cent

Imagine that an agent asks its policy decision point to approve a transfer of EUR 40.00 to a named supplier. The decision depends on facts held inside the sender's domain: cumulative spend, a live reservation against the budget, an approval that has not expired, earlier executions and the state of a kill switch. The policy engine permits the exact action.

The request crosses into the payment provider's system as EUR 40.01. Perhaps a compromised presenter changed it. Perhaps a proxy re-serialised the body. Perhaps an ordinary retry path rebuilt the request from a different object. The remote provider cannot rerun the original decision because it does not own the budget ledger or approval state. Checking a valid JWT signature is not enough.

That is the narrow gap addressed by Shamik Saha's first action-bound permit draft. It is an active individual Internet-Draft, not an RFC, IETF consensus or proof of deployment. Its claim is precise: a recipient should be able to verify that a stateful decision was made by an issuer it trusts for this class of action, and that the request which arrived is the one that was decided.

This is not a general cross-domain authorization system. It is an envelope for one decision.

Five bindings make the envelope narrow

The proposed object is a compact JWS JWT with the exact type aadp-permit+jwt. Its aud names one recipient; an array of audiences is refused. Its cnf.jkt names the presenter's proof-of-possession key. Across a trust boundary, the request must carry an HTTP Message Signature made with that key. Otherwise the permit is merely a bearer token, and the draft forbids that form across the boundary.

The signature covers at least the method, authority, path, query, Content-Digest, Idempotency-Key and the permit field itself. Content-Digest is recomputed over the exact bytes received before unagreed decompression, parsing or re-serialisation. A semantically identical JSON body with different bytes can therefore fail the wire check.

The semantic check is separate. Each registered action type defines how to derive action object A from the received path, query and body. The recipient canonicalises that JSON object under RFC 8785, adds a domain separator and recomputes action_digest. A byte-for-byte match cannot rescue a request whose derived amount, payee or other instance value does not match the decided action. Conversely, a semantic match does not excuse altered wire bytes.

The fifth binding is time. The permit cannot outlive AADP's execute_within deadline. Without one, its lifetime may not exceed 120 seconds, and an action-type registration may shorten but not lengthen that ceiling. The recipient declares any clock allowance, capped at 60 seconds, and may not use skew to extend the underlying deadline.

These checks turn the permit from a portable statement of approval into a deliberately awkward object: one audience, one key, one request, one action and one short interval. That awkwardness is the security property.

A decision is not a mandate

The draft's most important sentence is architectural rather than cryptographic. A recipient acts only when three conditions are jointly true: the bound decision verifies, the referenced mandate permits where one is present, and the recipient's own policy permits.

The sender's decision point knows whether the action fits its current budgets and approvals. A mandate such as the proposed Agent Authorization Envelope answers a different question: what the agent was delegated to do, under which constraints. The recipient evaluates that mandate for itself against the same transaction. A digest mismatch, DENY, PENDING or an unavailable required mandate causes refusal. A bound permit never turns PENDING into PERMIT.

The recipient then keeps its own veto. A payment provider may recognise the sender's issuer, verify every binding and still reject the transfer under sanctions, account, fraud or service policy. Cryptographic validity is not command authority over the organisation that bears the consequence.

Issuer trust is scoped for the same reason. The proposed table says which keys may decide which action types, within which per-field limits, until when and with what minimum currentness. Trusting an issuer for small transfers does not make it an issuer for account deletion or an unlimited amount. A flat list of trusted signers would move the missing policy into whatever local rule happened not to stop them.

Freshness is a declared compromise

A decision can be authentic and already stale. A policy version may have been replaced or a mandate revoked after the issuer signed but before the request reached the recipient. A short expiry bounds that interval; it does not reveal what changed inside it.

Revision 00 makes the limitation explicit through two modes. In time-bounded, the recipient treats the permit as current until exp, but only for issuer and action combinations configured to accept that risk. In status-checked, it establishes at verification time that the permit, policy version and mandate remain current, using a status list or a recent issuer-signed freshness statement.

If a required status endpoint is unreachable, the response is malformed or the freshness statement is stale, the normal result is status-unavailable. The draft allows an explicit, audited local fail-open only for action classes whose risk policy permits it. That exception belongs in the recipient's record. It must not disappear behind a generic “token valid” event.

Lu Heng's reality-layer distinction is useful here. The permit records what the decision point concluded at one moment. The currentness observation says what could still be established later. Neither record is the external effect. Joining them is necessary; collapsing them produces symbolic certainty where operating facts are missing.

Consume state last

The recipient's thirteen-step order is part of the control, not presentation advice. Cheap structural checks precede signature work. Issuer scope, body digest, presenter signature, semantic action, currentness, mandate and local policy all precede the final state transition. Only at step 13 does the recipient consume (iss, jti) atomically; only after that does it attempt the effect.

This prevents an attacker from burning a valid single-use permit by submitting it with a wrong audience, damaged body or missing signature. It also preserves the recipient's local-policy veto without spending the permit. If the consume store is unavailable, the request is could-not-check, not a policy denial and not a reason to proceed.

The jti is deliberately distinct from AADP's internal permit_id. The former crosses the boundary and serves as Idempotency-Key; the latter belongs to the sender's decision and report lifecycle. The issuer records their mapping but must not derive one from the other. Internal governance identifiers should not acquire external credential meaning by convenience.

On first presentation, the shared durable store consumes the (iss, jti) pair, performs the effect and stores the result. A later presentation with the same content digest returns that stored result and records a repeat. The same key with a different body is an idempotency-conflict. A repeat while the first attempt is still running receives a retryable response.

None of this guarantees exactly-once effect in the outside world. If the sender loses the response and cannot tell whether the transfer occurred, it must not request a fresh permit and send again. It reports timeout, reconciles with the recipient using jti or the recipient's action identifier, and escalates if the two records cannot be joined. Idempotency contains retries; it does not abolish uncertainty.

The recipient signs what happened next

Cross-domain disputes otherwise end with two self-authored logs. The draft therefore asks the recipient to return a signed confirmation after consumption and the attempt to perform the effect. It references the permit, received request, signature base, action digest, mandate verdict where applicable, outcome and recipient action identifier.

The presenter places the confirmation digest in its AADP report as discharge evidence for the present_bound obligation. That direction matters. The issuer signed the decision; the presenter signed the request; the recipient signed what it did with the request. No signature silently substitutes for another.

A signed refusal is especially valuable. It can support an AADP failure report with no_effect: true, allowing the relevant reservation to be released. An unsigned error cannot establish that nothing happened. No confirmation, or an effect-unknown confirmation, remains a timeout and preserves the possibility that the effect occurred.

The profile stops after one hop. A permit carrying a parent claim must be refused. If recipient B must call domain C, B takes a new decision under B's state and presents a new permit. It may include a reference to the earlier hop for provenance, but C must treat that reference as evidence only. Authority is decided again where the state and consequence live.

This is Minimum Initial Specification in an unusually concrete form: standardise the smallest bindings and refusal meanings needed for two parties to verify the same attempt, while leaving issuer selection, risk tolerance and local consequences with the participants. The common record should make disagreement visible, not appoint one domain as sovereign over the next.

Running code has two visible holes

The draft reports a reference implementation in the public onedoor repository. At the immutable commit named by the text, the vector manifest lists 24 cases and the traceability test labels 22 implemented. The two declared gaps are V17, detecting a superseded policy in status-checked mode, and V22, checking a recipient confirmation that names a different request digest. The draft also reports 92 passing permit tests.

That is useful, bounded evidence. The implementation is linked to the document's author, the named commit's own message concerns other repository maintenance, and no independent implementation or production result is established. Running-Code Primacy means reproducing the vectors, especially the gaps, and publishing mismatches. It does not mean treating a repository snapshot as a standards vote.

Sources and limits

These sources establish an active individual proposal, its dependencies and its author-linked implementation snapshot. They do not establish IETF consensus, an RFC, independent interoperability, secure deployment, honest policy decisions, honest recipients or exactly-once effects. This Article owns only revision 00's carriage of one stateful AADP decision as one scoped, presenter-bound, request-bound, action-bound, single-use attempt with a recipient-signed answer.