Action-Bound Permits for the Agent Action Decision Protocol (AADP): Carrying a Per-Action Decision Across a Trust Boundary

1.1. What Already Exists, and What Does Not

A consequential request from an agent that crosses into another organization's system raises three questions, and existing work answers two of them.¶

The third question is the gap. A mandate evaluation of the kind AAE specifies is stateless by design: AAE lists state carried across presentations and cumulative budgets as future work. An AADP evaluation is stateful by design: a verdict depends on cumulative spend, reservations, approvals that expire, prior executions and a kill switch. A recipient in another domain holds none of that state and cannot recompute the decision. It can only verify that a decision was made, by whom, about what, and that the request it received is the one decided.¶

That is all a bound permit does. It is an envelope for one decision, not a system for cross-domain authorization, and Section 1.3 says what it leaves to others.¶

1.2. The Composition Rule

A recipient that supports this profile acts on a request only when all three of the following hold:¶

1. The decision verifies: a bound permit from an issuer the recipient trusts for this class of action (Section 6) verifies, and binds this request (Section 3 and Section 4).¶
2. The mandate holds, where one is referenced: if the permit carries a mandate reference (Section 5), the recipient evaluates that mandate against the same request, and its verdict permits the action.¶
3. The recipient's own policy permits.¶

This is a conjunction. Each layer can refuse; none can overrule another. The issuer's decision never widens what the mandate allows, and the mandate never substitutes for a decision the issuer did not make.¶

1.3. Not in Scope

• Establishing trust between organizations: discovery, vetting, onboarding and federation. This document assumes a recipient has a configured table of issuers (Section 6) and says nothing about how it was built; [OIDFED] and [SPIFFE] address this.¶
• Mandates and their delegation. This document references a mandate; it does not define one.¶
• A policy language, for the same reason [AADP] declines to define one.¶
• Exactly-once external effect. As in [AADP] Section 7, a protocol cannot guarantee it; the recipient's idempotency store is what collapses retries (Section 12).¶
• Multi-hop chains of per-action decisions. This version refuses them (Section 11).¶
• Prompt injection. A bound permit faithfully carries a decision that policy should not have made. Its claim is narrower: a decided request cannot be altered, redirected, reused or presented by another party without detection.¶

1.4. Requirements Language and Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

Issuer:

the AADP Policy Decision Point (PDP), or a signing service acting for it, that signs the bound permit.¶

Presenter:

the AADP Policy Enforcement Point (PEP) that sends the request and holds the key named in the permit.¶

Recipient:

the party that receives the request and performs the effect. Its enforcement point is the Recipient Enforcement Point (REP).¶

Action object (A):

the JSON object, derived from the request by the rules of its action type, that the decision was taken about (Section 4.3).¶

Bound permit:

the action-bound permit of [AADP] Section 1.2, in the form defined in Section 3.¶

3.1. Envelope

A bound permit is a JSON Web Token [RFC7519] in JWS compact serialization [RFC7515], explicitly typed as [RFC8725] recommends:¶

{ "alg": "EdDSA", "kid": "<issuer key id>",
  "typ": "aadp-permit+jwt" }

EdDSA over Ed25519 is RECOMMENDED. A recipient MUST reject a bound permit whose "typ" is not "aadp-permit+jwt", and MUST reject any header parameter listed in "crit" that it does not implement.¶

3.2. Claims

The "jti" is not the AADP "permit_id". [AADP] Section 7 forbids presenting "permit_id" to a target resource as a credential or as a key carrying meaning there, because "permit_id" is the identity of AADP's decision and report lifecycle inside the governed domain. A bound permit is, by design, presented outside that domain, so it carries an identity of its own. The issuer MUST mint "jti" independently of "permit_id", MUST NOT make one derivable from the other, and MUST record the mapping between them in its AADP evidence entry for the decision.¶

This profile is stricter than [AADP] Section 7, which recommends that a PEP derive a target's idempotency key deterministically from the permit, for example from "permit_id". Where the target is a bound-permit recipient, "jti" is that key (Section 12), and the independent minting required above replaces the derivation Section 7 recommends. Nothing else in [AADP] Section 7 changes.¶

A claim is REQUIRED only if the recipient's verification consumes it. "policy_version", "mandate" and "evidence" are carried so that both sides' records can name them, not because the recipient can dereference them. Making a recipient depend on fields it cannot use would condition adoption on infrastructure it does not have.¶

3.3. Time

• "exp" MUST NOT be later than the deadline of the permit's "execute_within" obligation, where the AADP decide response carries one. A bound permit never outlives the permit it carries.¶
• Absent "execute_within", "exp" minus "iat" MUST NOT exceed 120 seconds. Registrations for particular action types MAY set a lower ceiling; none may set a higher one.¶
• Recipients MUST apply a declared clock-skew allowance not exceeding 60 seconds, and MUST record the allowance applied.¶

3.4. authorization_details

Each entry has a "type" naming a registered action type (Section 18) and the fields that type defines. The type's registration states, for each field, its meaning, its units and its comparison rule against an issuer's scope (Section 6). For example:¶

"authorization_details": [{
  "type": "payments.transfer/1",
  "payee": "acme-gmbh",
  "amount": { "currency": "EUR", "max": "40.00" },
  "reference": "invoice-8841"
}]

A recipient MUST reject a permit carrying an "authorization_details" entry whose "type" it does not implement. Unknown types fail closed, as unknown obligations do in [AADP] Section 6.¶

3.5. Example

{
  "iss": "https://pdp.payer.example",
  "sub": "spiffe://payer.example/pep/accounts-payable",
  "aud": "https://payments.example.net",
  "jti": "bp-4f0c2a91d7e3",
  "iat": 1790152800, "nbf": 1790152800, "exp": 1790152860,
  "cnf": { "jkt": "0ZcOCORZNYy-DWpqq30jZyJGHTN0d2HglBV3uiguA4I" },
  "authorization_details": [{
    "type": "payments.transfer/1",
    "payee": "acme-gmbh",
    "amount": { "currency": "EUR", "max": "40.00" },
    "reference": "invoice-8841"
  }],
  "action_digest": "sha-256=:9Bh7a3W0...=:",
  "verdict": "permit",
  "tier": { "nominal": 1, "effective": 1 },
  "policy_version": "sha-256=:3f775k...=:",
  "mandate": { "type": "aae", "id": "urn:uuid:7c1e...",
               "digest": "sha256:ab41..." },
  "currentness": "time-bounded",
  "evidence": { "evidence_id": "aud-88213" }
}

4.1. Body: Content-Digest

The presenter MUST send a Content-Digest field [RFC9530] computed over the exact content bytes sent, using sha-256 or a stronger registered algorithm. The recipient MUST recompute it over the bytes it received, before any parsing, decompression it did not negotiate, or re-serialization. The parsed object is not necessarily the object that was sent; [STAGE-RECEIPTS] applies the same boundary rule to external calls.¶

4.2. Request and Presenter: HTTP Message Signatures

The presenter MUST sign the request with HTTP Message Signatures [RFC9421], using the private key whose thumbprint is the permit's "cnf.jkt". The signature MUST cover, at minimum, the components "@method", "@authority", "@path", "@query", "content-digest", "idempotency-key" and "aadp-permit", where "aadp-permit" is the field carrying the bound permit (Section 18). Covering the permit field binds the signature to this permit; covering "content-digest" binds it to the body; the derived components bind it to the target. Action types MAY require further components in their registration. Volatile, hop-by-hop or intermediary-rewritten fields MUST NOT be covered.¶

The recipient MUST verify the signature under the key identified by "cnf.jkt", and MUST reject a request whose signature verifies under any other key. Without this binding a bound permit is a bearer token: whoever holds it can present it until it expires. Bearer permits MAY be used inside one governed domain, where the channel assumptions of [AADP] Section 1.2 hold, and MUST be declared as bearer in that deployment's documentation. They MUST NOT be accepted across a trust boundary.¶

4.3. Semantics: the Action Object and action_digest

Wire bytes and meaning are different things, and the permit binds both.¶

• Each registered action type defines how the action object A is derived from a request: which fields of the parsed body, path or query form A, with what types. A MUST be a JSON object.¶
• action_digest = "sha-256=:" || BASE64( SHA-256( "aadp:action:v1" || 0x00 || JCS(A) ) ) || ":", where JCS is the JSON Canonicalization Scheme [RFC8785]. The domain tag separates this digest from every other digest over the same object.¶
• The recipient derives A from the request it received, by the type's rules, and MUST reject the request if the recomputed digest differs from the permit's "action_digest".¶

This digest is an instance binding. [I-D.kroehl-agentic-trust-aae] Section 2.2.2 binds a grant to an action type: the values that distinguish one instance from another (amounts, recipients, sequence numbers) are kept out of its action object and travel beside it, bounded by the grant's constraints, and a binding that commits to an action instance is outside that specification, which neither defines nor forbids it. The "action_digest" here is such an instance binding: its A carries the concrete values the decision was taken about. A recipient that also evaluates an AAE therefore derives two objects from the one request it received, each bound by its own digest under its own domain tag: the mandate says the kind of action is allowed within per-action bounds; the permit says this action was decided. Neither digest can stand in for the other. An action-type registration SHOULD state both derivations, so that they are taken from the same request fields.¶

5.1. Why a Reference, and Not a Mandate

Two requests can be identical in every respect AADP evaluates -- identity, arguments, budget, approval state -- and differ only in the authority under which they are caused: an account suspension under a fraud-response mandate, and the same suspension under an employee-support mandate. The decision may be right in both cases; what fails without a reference is re-derivability, because a reader of the record cannot say under which mandate the action was authorized. This document does not define a mandate. It defines a reference to one:¶

"mandate": { "type": "aae", "id": "<credential id>",
             "digest": "<mandate digest>" }

• "type" names the mandate format. "aae" is the only value defined here; others are registered (Section 18).¶
• "id" identifies the mandate object.¶
• "digest" is the mandate's own content digest as its format defines it. For "aae", it is the mandate digest of [I-D.kroehl-agentic-trust-aae] Section 2.5.3.¶

5.2. Rules at the Issuer

• The mandate reference MUST be established the way [AADP] Section 5.1 requires authorization-relevant provenance to be established: through an authenticated channel or credential, represented as context the policy evaluates. A caller MUST NOT be able to name its own mandate in request parameters.¶
• The issuer SHOULD record, in its AADP evidence, the mandate reference and the mandate's status as observed at decision time (for AAE, the result of its revocation check where present). Without that, a later reader can say which mandate was named but not that it was valid when the decision was taken.¶
• Where the issuer consumes a mandate-layer verdict, the correspondence of [AADP] Section 8.1 applies: no bound permit is issued while that verdict denies or defers the action.¶

5.3. At the Recipient

Where "mandate.type" is "aae" and the AAE is presented or retrievable:¶

1. The recipient evaluates the AAE under [I-D.kroehl-agentic-trust-aae] Section 5, including subject binding, validity, single use, revocation and delegation, against the transaction it derives from the same request.¶
2. The recipient MUST compare the evaluated AAE's mandate digest with the permit's "mandate.digest" and reject on mismatch ("mandate-mismatch").¶
3. The AAE verdict governs as follows: PERMIT, continue; DENY, refuse ("mandate-denied"); PENDING, refuse ("mandate-pending"). The request MAY be resubmitted once ratification under that document's Section 6.3 has occurred. A bound permit never converts PENDING into PERMIT.¶

Where the permit names a mandate the recipient cannot obtain or evaluate, the recipient MUST refuse ("mandate-unavailable") unless its local policy explicitly treats that action type as mandate-optional, and it MUST record which it did.¶

7.1. The Problem

A bound permit proves that a decision was taken under a policy version and, where named, a mandate. It does not by itself prove that either was still in force when the request arrived. A policy superseded, or a mandate revoked, between decision and execution is invisible to the recipient. Short lifetimes bound that window in time; they do not close it. Inside one domain the PEP can ask again; across a boundary the recipient cannot.¶

This profile does not claim to close the window by default. It requires every permit to declare which of two modes it is in, and every recipient record to state which mode applied, so that the limitation is visible in each record instead of hidden in each deployment.¶

7.2. Modes

time-bounded:

The permit is current until "exp" and no further check is made. Declared limitation: a change of policy version or a revocation of the mandate before "exp" is not detected. A recipient MAY accept "time-bounded" only for action types and issuers whose table entry allows it.¶

status-checked:

The permit carries "status", and the recipient MUST establish, at the moment of verification, that neither the permit, its "policy_version", nor its "mandate" has been revoked or superseded. Two mechanisms are defined. Status list: "status" identifies an entry in a status list published by the issuer, following [I-D.ietf-oauth-status-list]. Stapled freshness: the presenter includes an issuer-signed freshness statement in the "AADP-Permit-Status" field, of the form { "jti", "policy_version", "mandate_digest", "status": "current", "iat" }, whose "iat" is within the table's freshness window (RECOMMENDED: no more than 30 seconds).¶

If a "status-checked" permit's status cannot be determined -- endpoint unreachable, response unparseable, statement stale -- the recipient MUST refuse ("status-unavailable"). A recipient MAY apply an explicit, locally configured, audited fail-open policy for action types whose risk classification permits it, and MUST record that it did.¶

8.1. Order

The REP performs these steps in order, stopping at the first failure. Cheap structural checks come before cryptography, cryptography before state, and state is consumed last, so that a request refused for any other reason does not consume its permit.¶

Only after step 13 does the recipient perform the effect.¶

8.2. Fail Closed

• A recipient that requires bound permits for an endpoint MUST NOT fall back to other authorization when a permit is absent or fails. Absence is "malformed", not a reason to accept another credential.¶
• If any verification dependency is unavailable -- key discovery, status, mandate retrieval, the consume store -- the recipient MUST refuse, with the reason naming the dependency, and MUST distinguish that refusal from a policy denial in its record, as [AADP] Section 5.1 distinguishes a PDP defect from a policy outcome.¶

8.3. Verification States in the Record

A recipient's record states, per request, one of: "verified" (every step passed); "refused", with its reason code and the step at which it stopped; or "could-not-check", with the dependency that was unavailable. There is no partial verification: a verification in which a required check was not performed is "could-not-check".¶

11.1. Issuer Fan-Out

When one piece of work is carried out as several requests -- an orchestrating agent that hands sub-tasks to sub-agents, or a batch of payments executed by several workers -- each request is decided by the issuer on its own, and the issuer issues one bound permit per request. Each permit names its own audience, its own presenter key in "cnf" (the sub-agent's or worker's key, not the orchestrator's), its own "authorization_details" and "action_digest", and its own "jti".¶

Budgets are then enforced where they live. Each sub-request reserves against the issuer's cumulative budgets under [AADP] Section 4, so the total across all sub-requests is bounded by the same budgets that bound any other set of actions, and each reservation is resolved by its own report. No party other than the issuer derives or narrows a permit, and no recipient has to verify more than one issuer signature.¶

11.2. Upstream Reference

When a recipient in one domain acts, in turn, towards a further domain -- A's request causes B to call C -- B takes its own decision and presents its own bound permit to C, as above. C may still want to know what caused B's request. B's issuer MAY include, in the permit's "evidence" claim, an "upstream" member: an array of references to earlier hops, each of the form { "iss", "jti", "digest" }, where "digest" is the digest of that hop's bound permit or of the recipient confirmation B returned for it (Section 10).¶

• An upstream reference is evidence, not authority. A recipient MUST NOT treat it as authorizing anything, and MUST NOT relax any verification step because of it.¶
• A recipient MAY record upstream references, and MAY refuse under local policy a request that lacks one where its policy requires provenance ("local-policy").¶
• Because each hop's confirmation names the permit it answered, and each later permit names the earlier confirmation, the hops form a sequence of records that each side signed, readable after the fact, without any hop deriving its authority from another.¶

15.1. Bearer Versus Bound

Without "cnf" and the request signature, a bound permit is a bearer token. Section 4.2 forbids bearer permits across a trust boundary. The single most likely deployment mistake is accepting the permit without verifying the request signature; conformance vectors for it are mandatory (Section 17).¶

15.2. Key Compromise

A compromised issuer key forges permits until the recipient's table stops trusting it. Lifetimes are bounded (Section 3.3), and "status-checked" permits can be revoked at the status list. A compromised presenter key lets an attacker present permits already issued to that presenter, within their lifetimes, to their audiences, for their decided actions only.¶

15.3. A Compromised Presenter

A presenter that holds direct capability to the recipient can bypass this profile entirely; [AADP] Section 1.2 already disclaims that case. What this profile changes is the case in which the presenter uses the profile and substitutes a request: the substituted request fails "action-mismatch" or "content-mismatch", and the recipient's signed refusal records a decided action and a presented action that differ. That is not prevention. It turns a silent substitution into evidence that names both sides.¶

15.4. Upstream References

An upstream reference is written by the issuer of the permit that carries it and is not verified by this profile. A recipient that granted it authority would accept, from a compromised or careless issuer, a claim about another domain's decision that no one checked. Section 11.2 therefore makes it evidence only.¶

15.5. Time

Clock skew is bounded and recorded (Section 3.3). A recipient MUST NOT extend "exp" by its skew allowance beyond the "execute_within" deadline.¶

15.6. Intermediaries

A proxy that re-encodes the body, rewrites the path or strips unknown fields will cause refusals by design. Deployments with such intermediaries either terminate the profile at the intermediary, which then becomes the recipient with its own record, or configure it to pass covered components untouched.¶

15.7. What the Profile Does Not Protect

A request that policy should not have permitted; a recipient that lies in its confirmation; issuer and recipient in collusion; a mandate that was wrongly granted. Each needs controls outside this document.¶