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

Introduction

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. Three Questions at a Trust Boundary

Question	Answered by
Who is acting, and what may it reach?	Workload identity and access tokens (for example SPIFFE, mutual TLS, OAuth 2.0)
What has the agent been mandated to do, within what constraints, until when?	Mandate formats such as , which the relying party evaluates itself
Was this exact request decided, under the sender's current authorization state, and is what arrived the request that was decided?	Inside one domain, . Across a boundary, nothing.

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 says what it leaves to others.

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

The decision verifies: a bound permit from an issuer the recipient trusts for this class of action () verifies, and binds this request ( and ).
The mandate holds, where one is referenced: if the permit carries a mandate reference (), the recipient evaluates that mandate against the same request, and its verdict permits the action.
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.

Not in Scope

Establishing trust between organizations: discovery, vetting, onboarding and federation. This document assumes a recipient has a configured table of issuers () and says nothing about how it was built; and address this.
Mandates and their delegation. This document references a mandate; it does not define one.
A policy language, for the same reason declines to define one.
Exactly-once external effect. As in Section 7, a protocol cannot guarantee it; the recipient's idempotency store is what collapses retries ().
Multi-hop chains of per-action decisions. This version refuses them ().
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.

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 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 ().
Bound permit:: the action-bound permit of Section 1.2, in the form defined in .

Roles and Flow

Bound Permit Flow PEP --decide--> PDP (issuer) | <--permit + bound permit--+ | | request + Content-Digest + Signature | (key in cnf) + bound permit | + Idempotency-Key v +--------- trust boundary ----------+ v REP -- verify permit, binding, scope, | currentness | -- evaluate referenced mandate (if any) | -- apply local policy | -- consume (iss, jti) atomically v Recipient system -- effect | v signed recipient confirmation --> PEP --report--> PDP ]]> The PEP never signs the decision and the PDP never signs the request. Each signature says one thing: the issuer's says this was decided; the presenter's says this is the request, and I am the party the decision named. A compromised PEP can still substitute a request, but not silently: the substituted request will not match the decided action, and the mismatch lands in the recipient's signed record as evidence ().

The Bound Permit

Envelope A bound permit is a JSON Web Token in JWS compact serialization , explicitly typed as recommends: ", "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.

Claims Bound Permit Claims

Claim	Presence	Meaning
iss	REQUIRED	The issuer. Looked up in the recipient's issuer table ().
sub	REQUIRED	The presenter, as an identifier the recipient can associate with the key in "cnf" (for example, a SPIFFE ID). Informational: the binding is "cnf", not "sub".
aud	REQUIRED	The recipient, as a single value. A permit with more than one audience MUST be rejected. It equals the value of the permit's "present_bound" obligation.
jti	REQUIRED	An identifier for this bound permit, unique per issuer, minted by the issuer (see below). Also the idempotency key ().
iat, nbf, exp	REQUIRED	Issue time, not-before and expiry ().
cnf	REQUIRED across a trust boundary	The presenter's key , as "jkt", a JWK thumbprint as used by ().
authorization_details	REQUIRED	What was decided, as typed entries ().
action_digest	REQUIRED	The digest of the action object A ().
verdict	REQUIRED	Always "permit". Present so that the object states its own meaning; no other AADP verdict produces a bound permit.
tier	OPTIONAL	The nominal and effective autonomy tiers from the AADP decide response.
policy_version	RECOMMENDED	The content digest of the policy in force at the decision, as recorded in the issuer's AADP evidence.
mandate	OPTIONAL	A mandate reference ().
currentness	REQUIRED	"time-bounded" or "status-checked" ().
status	REQUIRED if "currentness" is "status-checked"	Where the recipient checks status ().
evidence	OPTIONAL	References into the issuer's AADP evidence record, to the presenter's preceding evidence record (for example a stage receipt ), and to earlier hops ("upstream", ). Carried and echoed; never required for verification and never a source of authority.

The "jti" is not the AADP "permit_id". 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 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 (), and the independent minting required above replaces the derivation Section 7 recommends. Nothing else in 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.

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.

authorization_details Each entry has a "type" naming a registered action type () 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 (). For example: 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 Section 6.

Example

Binding the Permit to the Request A bound permit is useless if the request it accompanies can be altered. Three bindings close that: the body to its bytes, the request to the presenter's key, and the bytes to the decided action.

Body: Content-Digest The presenter MUST send a Content-Digest field 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; applies the same boundary rule to external calls.

Request and Presenter: HTTP Message Signatures The presenter MUST sign the request with HTTP Message Signatures , 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 (). 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 Section 1.2 hold, and MUST be declared as bearer in that deployment's documentation. They MUST NOT be accepted across a trust boundary.

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 . 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. 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.

The Mandate Reference

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: ", "digest": "" } ]]>

"type" names the mandate format. "aae" is the only value defined here; others are registered ().
"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 Section 2.5.3.

Rules at the Issuer

The mandate reference MUST be established the way 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 Section 8.1 applies: no bound permit is issued while that verdict denies or defers the action.

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

The recipient evaluates the AAE under Section 5, including subject binding, validity, single use, revocation and delegation, against the transaction it derives from the same request.
The recipient MUST compare the evaluated AAE's mandate digest with the permit's "mandate.digest" and reject on mismatch ("mandate-mismatch").
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.

Issuer Scope A trust store that merely lists issuers lets any trusted issuer authorize anything the recipient's local policy fails to stop. This profile replaces the list with a table of scopes. Each entry states:

Every "authorization_details" entry in a permit MUST fall inside the issuer's scope: its "type" listed, and every limited field within its limit by the type's comparison rule. Otherwise the recipient refuses ("issuer-out-of-scope"), naming the entry and field, not the limit.
An issuer MAY publish the action types it decides in a metadata document modeled on , under "aadp_action_types_supported". Publication informs a recipient's table; it never grants scope. The recipient's table is authoritative and is changed only by the recipient.
Changes to a recipient's issuer table SHOULD be recorded with who made them, when, and what changed. A scope that widens without a record is a permission granted by nobody.

Currentness

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.

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 . 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.

Recipient Verification

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. Verification Order

#	Step	Refusal reason
1	Permit present, parses, "typ" is "aadp-permit+jwt", "crit" understood	malformed
2	"iss" in the issuer table; signature verifies under a current key for that issuer	issuer-unknown, signature-invalid
3	"aud" identifies this recipient, as a single value	audience-mismatch
4	nbf <= now <= exp within the declared skew; the rules of hold	expired, not-yet-valid, lifetime-invalid
5	Every "authorization_details" type implemented	unknown-authorization-type
6	Every entry within the issuer's scope	issuer-out-of-scope
7	Content-Digest recomputed over the received bytes matches	content-mismatch
8	An HTTP message signature is present, made with the key "cnf.jkt" names, verifies, and covers the required components	request-signature-missing, presenter-key-mismatch, request-signature-invalid, binding-incomplete
9	A derived from the request; its digest equals "action_digest"	action-mismatch
10	Currentness per "currentness" ()	stale-policy, mandate-revoked, status-unavailable
11	Referenced mandate evaluated ()	mandate-mismatch, mandate-denied, mandate-pending, mandate-unavailable
12	Recipient-local policy permits	local-policy
13	(iss, jti) consumed atomically ()	replayed, idempotency-conflict

Only after step 13 does the recipient perform the effect.

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 Section 5.1 distinguishes a PDP defect from a policy outcome.

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".

The Recipient Confirmation Each side of a cross-domain action keeps its own record; without more, a dispute is two self-authored accounts. This profile asks for one object the recipient signs and both sides keep. On completing step 13 and attempting the effect, the recipient returns a recipient confirmation, a JWS signed by the recipient, in the "AADP-Recipient-Confirmation" response field: :" }, "request": { "content_digest": "sha-256=:...:", "signature_base_digest": "sha-256=::" }, "action_digest": "sha-256=:...:", "mandate_verdict": { "type": "aae", "core_digest": "sha256:..." }, "outcome": "effected | refused | effect-unknown", "reason": "", "recipient_action_id": "TX-77120", "iat": 1790152803 } ]]>

"mandate_verdict.core_digest", where an AAE was evaluated, is the digest of the recipient's AAE verdict core ( Section 2.5.3), so that the mandate layer's record and this confirmation reference each other.
The presenter MUST include the confirmation's digest in its AADP report for the permit; this is the discharge evidence of the "present_bound" obligation ( Section 6). A presenter that keeps per-stage evidence -- for example stage receipts -- SHOULD also include it in the record of the sending stage. This profile does not require stage receipts: the chain holds with the AADP report alone.
Direction of reference, so that nothing is circular: the permit MAY reference the presenter's preceding evidence record; the sending stage's record references the permit and the confirmation; the confirmation references the permit and the request. Nothing references a record that is written after it.

A recipient that refuses at any step SHOULD still return a confirmation with "outcome": "refused" and the reason. A refusal the recipient signs is evidence; a refusal it merely returns is an assertion.

More Than One Hop A bound permit authorizes one request, to one audience, by one presenter. This version of the profile is single-hop:

A permit MUST NOT carry a "parent" claim. A recipient receiving one MUST refuse with "chained-permit-unsupported".
A recipient that is itself about to perform a consequential action in a further domain takes its own decision in its own domain and presents its own bound permit there. A decision is not forwarded; it is taken again where the state is.
Delegation of mandate across hops belongs to the mandate format: a downstream permit may reference a delegated mandate whose chain leads back to the original principal. That carries the authority across hops without carrying the decision.

A capability declared unsupported must be refused by the code, not merely left out of the text. Chained permits, in which an intermediary derives a permit from one it received, are out of scope for this version; any future design would be expected to build on existing delegation mechanisms such as . Two patterns cover most multi-party cases without a chain. Both are informative: they use only what this document already defines.

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 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.

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 ().

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.

Idempotency and Single Use

The presenter MUST send an Idempotency-Key field (as described in ) equal to the permit's "jti". No secret is involved: the key is already bound by the issuer's signature and the presenter's. This profile states the semantics below in full and does not depend on that document.
The recipient keeps a consume store keyed by (iss, jti), durable and atomic, shared across every node that can serve the endpoint. A recipient that cannot keep such a store MUST NOT accept bound permits.
First presentation: consume, perform, store the result.
Same (iss, jti) and same Content-Digest, after completion: return the stored result and record the presentation as a repeat, not a second effect.
Same (iss, jti), different Content-Digest: refuse ("idempotency-conflict").
Same (iss, jti) while the first is still in progress: refuse with a retryable status.
Unknown outcome: a presenter that sent a request and cannot establish whether the effect occurred MUST NOT obtain a new permit and resend. It reports "timeout" under , reconciles with the recipient using "jti" or "recipient_action_id", and escalates if reconciliation fails.

Relationship to AADP

A bound permit is issued only from a decide response whose verdict is "permit" and which carries a "present_bound" obligation ( Section 6); its "aud" is that obligation's value. "propose", "dry_run", "observe" and "replay" produce no bound permit.
Report outcomes. Effect confirmed: "success", with the confirmation digest. Recipient refused, with a signed confirmation whose outcome is "refused": "failure" with "no_effect": true, because the recipient established, and signed, that it acted on nothing. Presenter declined, for example because the permit expired before sending: "not_attempted". Outcome unknown, including a confirmation whose outcome is "effect-unknown" or no confirmation at all: "timeout". Exactly one report per permit, as requires.
Budgets follow Section 4.1 unchanged: the reservation is committed on "success" and "timeout", and released on "not_attempted" and on "failure" with "no_effect": true. A refusal the recipient did not sign does not establish that no effect occurred, and the presenter MUST NOT set "no_effect" on its strength. Rate budgets are never released. This stateful accounting is the part a stateless mandate layer leaves as future work, and the reason the two compose rather than overlap.

Related Work specifies signed mandates, action-type binding, delegation by strict subordination, single-use presentation, revocation checking and verdict records. This document references those rather than re-specifying them, and adds only what that document places outside its scope: action-instance binding, state across presentations, HTTP request binding, issuer scope, currentness and a recipient-signed confirmation. binds a named human approver's signature to one canonical action, for offline verification and single use. A bound permit instead carries a policy decision point's decision, which may depend on budgets and approval state, and binds it to one presenter key and one HTTP request. The two can meet: an AADP approval ( Section 8) could be evidenced by such a receipt, and the resulting decision carried as a bound permit. defines a signed, recomputable record of a decision about an autonomous action and its execution. It records a decision after the fact; a bound permit is the form in which a decision is presented to the party that performs the action, and the recipient confirmation is that party's signed account of what it did with it. Several documents already carry parts of this profile, and this document claims only their combination. states requirements and an abstract data model for authorizing an effect before it is committed at an effect boundary, with binding to an action digest, replay protection by durable state, reason codes for refusal and conformance vectors; it defines no wire format and no presenter binding. defines a domain-separated digest over the canonical form of an approved action, verified in a fixed order with distinct failures; this document's "action_digest" () is a construction of the same kind, and a later revision may align the two rather than keep both. has the performing organization countersign a record of the request it acted on, which is the role of the recipient confirmation (). and record a decision point's pre-execution decision over the request bytes, as evidence for transparency and audit; the permit here is instead presented to, and consumed once by, the party that performs the action. issues a single-use, short-lived credential bound to a digest of the operation's parameters after human approval. combines holder proof, an action snapshot and single use per operation with durable spend control. What this document adds to those is the combination: a decision that depends on the issuer's state (budgets, reservations, approvals) carried to one audience, bound to a presenter key and to one HTTP request by message signature, consumed once by the recipient after a fixed verification order, and answered by a confirmation the recipient signs. propagate identity and authorization context along a call chain within a trusted domain. A bound permit is for the case that document excludes: one decided request presented across a trust boundary.

Security Considerations

Bearer Versus Bound Without "cnf" and the request signature, a bound permit is a bearer token. 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 ().

Key Compromise A compromised issuer key forges permits until the recipient's table stops trusting it. Lifetimes are bounded (), 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.

A Compromised Presenter A presenter that holds direct capability to the recipient can bypass this profile entirely; 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.

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. therefore makes it evidence only.

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

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.

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.

Conformance Vectors Each vector is a refusal with a named reason, and each is paired with the valid case beside it, so that a verifier that refuses everything does not pass. Where a rule has an absent case and an empty case, both are vectors. Conformance Vectors

#	Mutation	Expected
V01	Body changed after signing	content-mismatch
V02	Path changed after signing	request-signature-invalid
V03	Presented to a different recipient	audience-mismatch
V04	"aud" carries two values	audience-mismatch
V05	Presented after "exp"	expired
V06	"exp" later than "execute_within"	lifetime-invalid
V07	Same permit presented twice, same body	stored result returned; recorded as a repeat
V08	Same "jti", different body	idempotency-conflict
V09	Request signed by a key other than "cnf.jkt"	presenter-key-mismatch
V10	Request not signed at all (bearer presentation)	request-signature-missing
V11	Signature omits "content-digest" from the covered components	binding-incomplete
V12	Body re-serialized with the same meaning, different bytes	content-mismatch
V13	Same bytes, A derived differently from what was decided	action-mismatch
V14	"authorization_details" type unknown to the recipient	unknown-authorization-type
V15	Issuer trusted, action type outside its scope	issuer-out-of-scope
V16	Issuer trusted for the type, amount above its limit	issuer-out-of-scope
V17	"status-checked", policy version since superseded	stale-policy
V18	"status-checked", status endpoint unreachable	status-unavailable (could-not-check)
V19	Mandate digest differs from the evaluated AAE	mandate-mismatch
V20	Referenced AAE evaluates to PENDING	mandate-pending
V21	Permit carries "parent"	chained-permit-unsupported
V22	Recipient confirmation names a different request digest	detected by the presenter; the report records the discrepancy
V23	Consume store unavailable	could-not-check, not a policy denial
V24	Permit valid, local policy denies	local-policy, and the permit is not consumed

IANA Considerations This document requests the following registrations. Registration procedures and templates will be completed in a later revision.

Media types: "application/aadp-permit+jwt" and "application/aadp-confirmation+jwt".
HTTP fields: "AADP-Permit" (request; the bound permit), "AADP-Permit-Status" (request; stapled freshness) and "AADP-Recipient-Confirmation" (response).
An AADP Action Types registry: name and version, fields, units, the derivation of A, the comparison rule per field for scope checks, and any further covered components the type requires.
An AADP Mandate Reference Types registry, with the initial value "aae", referencing .
An AADP Bound Permit Refusal Reasons registry: the codes of , each with a Problem Details type URI.
JSON Web Token claims: "action_digest", "verdict", "tier", "policy_version", "mandate", "currentness", "status" and "evidence", where not already registered.
OAuth authorization server metadata: "aadp_action_types_supported".