Question: execution-time revalidation of mandate-bound checkout/payment actions

[meridianverity]

Hello AP2 maintainers and community,

I am looking for pointers on a narrow protocol-boundary question related to mandate-bound checkout and payment flows.

AP2 already defines important concepts around Intent Mandates, Checkout/Cart Mandates, Payment Mandates, verifiable credentials, mandate chaining, payment authorization, and transaction accountability.

My question is not whether AP2 can bind user intent, cart contents, or payment authorization. I am trying to understand the intended boundary for execution-time revalidation: just before a mandate-bound payment-adjacent action is accepted or acted upon, where should an implementation verify that the final action still matches the current mandate evidence?

Concretely, suppose a mandate chain is structurally valid, signatures verify, and the agent is an authorized participant. Before the payment-adjacent action is executed, is there an AP2-level object, lifecycle event, verification step, or recommended implementation pattern for checking evidence such as:

• the exact checkout/cart or line items
• merchant or seller identity
• amount and currency
• mandate scope or user constraints
• mandate expiration or freshness
• status or revocation state
• anti-replay or consume-once state
• final allow/deny/hold decision evidence
• denial reason or error evidence when blocked

The failure mode I am thinking about is not simply an invalid signature or invalid credential.

It is a valid mandate / valid agent / valid payment flow where the final action has drifted before execution, for example:

• cart changed after mandate issuance
• merchant or seller changed
• amount or currency changed
• mandate scope no longer matches the final action
• mandate expired or became stale
• mandate was replayed or reused
• status or revocation evidence is missing or stale
• the action is attempted through a provider path that does not revalidate the final mandate-bound state

I am not proposing a mechanism or specification text here. I am trying to understand the intended AP2 boundary:

1. Is this already handled by existing AP2 mandate objects, mandate hashes, payment authorization messages, or lifecycle events?
2. Is final execution-time revalidation intentionally left to implementers, merchants, payment processors, credential providers, or verifier layers?
3. Are there existing issues, discussions, security notes, or SEP materials that address this execution-time drift / final revalidation question?
4. Is there a recommended error or denial pattern when a mandate is valid in form but no longer matches the final action at execution time?

For context only, I have been exploring a related external-effect authorization problem in an individual IETF Internet-Draft and a small public synthetic reference evaluation:

https://datatracker.ietf.org/doc/draft-lee-orprg-permit-receipts/

https://github.com/meridianverity/permit-receipt

This is a request for technical guidance and pointers only, not a request to incorporate code, schema, or specification text.

Thank you.

[chopmob-cloud]

This is the gate AlgoVoi runs in production, at admission time, just before a mandate-bound action is accepted. Mapping your checklist to a live implementation may help.

The pattern: the action is admitted through a compliance gate that re-checks the live evidence and emits a signed compliance receipt recording the decision. The receipt is SHA-256 bound to the Payment Mandate or Cart Mandate (the AP2 objects you already have), so revalidation is anchored to the exact approved mandate bytes, not a re-derived copy.

Point by point against your list, all live:

• Exact cart/line items, merchant identity, amount, currency. Carried by the bound Payment/Cart Mandate. The receipt's request_digest (Content-Digest, RFC 9530, signed under RFC 9421) ties the executed request to those bytes, so a substituted line item or amount fails the digest.
• Mandate scope, freshness, expiration. Checked at admission; an expired or out-of-scope mandate yields a non-ALLOW outcome (the gate carries an EXPIRED state).
• Anti-replay / consume-once. A signed nonce plus idempotency key at the gate, so the same mandate evidence cannot be replayed into a second execution.
• Status / revocation. Evaluated at admission time, not at mandate-issue time, which is the whole point of execution-time revalidation.
• Final allow/deny/hold + denial evidence. A closed categorical outcome, ALLOW / REFER / DENY, signed into the receipt. REFER is a distinct hold/escalate state from DENY and can carry different downstream obligations, so "blocked" is not collapsed into a single flag.

So the answer to "where should an implementation verify": at an admission-time gate that revalidates against current evidence and emits a signed, independently verifiable receipt of the decision. Probeable against the agent card at api.algovoi.co.uk; the receipt is EdDSA/Ed25519 over JCS-canonical (RFC 8785) bytes, re-verifiable offline against the published JWKS.

AlgoVoi (chopmob-cloud) -- docs.algovoi.co.uk/protocols/ap2

[meridianverity]

Thanks @chopmob-cloud — this is a useful concrete implementation example, and it is directionally aligned with verifying as close as possible to execution.

I want to preserve one distinction for the record: AlgoVoi’s implementation and proposed extensions versus what AP2 v0.2 currently specifies.

My reading of the current AP2 text is that the closest AP2-native boundary is the Verifier’s Action Authorization step together with the role-specific verification requirements:

• the Merchant verifies the Checkout Mandate against the latest merchant-signed checkout and evaluates its constraints before completing checkout;
• the Credential Provider or Network verifies the Payment Mandate and its constraints before releasing a payment credential; and
• the MPP verifies that the credential is scoped to the Checkout before processing.

The acceptance or rejection can then be represented by a signed AP2 Mandate Receipt.

That is directionally consistent with an admission-time gate. However, I do not see AP2 v0.2 defining one generic “Compliance Gate” object, a Compliance Receipt, or ALLOW / REFER / DENY outcome semantics. The current AP2-native receipt surface appears to use success / error with a mandate reference and error fields. The compliance-receipt and HTTP-signature bindings referenced here also appear to remain open AlgoVoi-authored extension proposals rather than merged AP2 text.

A few details would help clarify how the implementation resolves the specific execution-time drift / TOCTOU boundary:

1. Binding target

What exact object is bound into the decision: the received or final SD-JWT, the merchant-signed checkout_jwt, a JCS-canonical mandate-content object, the actual execution request, or hashes of more than one of those?

Those are distinct binding targets. In particular, JCS-canonical bytes are not necessarily the exact original wire bytes.

Could you also point to the exact receipt schema containing request_digest? The seven-field Compliance Receipt shape currently proposed in #269 does not appear to contain that member.

2. Semantic comparison

An RFC 9421 signature covering an RFC 9530 Content-Digest, when correctly verified against the received content, protects the integrity and authenticity of the covered HTTP request content.

It does not by itself establish that the request semantically satisfies the Checkout or Payment Mandate.

What deterministic comparison is performed between the live action and the mandate evidence? Are the compared inputs, applicable policy or rule version, and decision all bound into the signed evidence?

3. Commit coupling and bypass resistance

Is the gate decision transactionally coupled to the actual checkout or payment commit, and is verification mandatory on every execution and provider path?

Otherwise, a post-gate mutation or an alternate path that does not invoke the gate would leave the original execution-time drift problem open. A signed receipt provides evidence of a decision, but does not by itself ensure that only the checked action is committed.

4. Replay and consume-once state

What creates consume-once semantics across concurrent requests and different provider paths?

For example, how are audience binding, expiry, nonce uniqueness, idempotency namespace, atomic reservation/commit, retention, retries, and concurrent attempts handled? A nonce and idempotency key are useful, but their security depends on the verifier and executor enforcing the associated state transition atomically.

5. Status, revocation, and outcomes

Which status or revocation source is evaluated, what freshness rule applies, and is stale or unavailable status evidence handled fail-open or fail-closed?

Are REFER or hold outcomes purely an AlgoVoi extension, and if so, how are they mapped to AP2’s native receipt and error model?

So I would treat this as a useful implementation datapoint showing that admission-time revalidation can be implemented, but not yet as the AP2 protocol-boundary answer I was seeking.

The remaining question for AP2 maintainers is which final checks AP2 normatively assigns to each verifier, which checks are intentionally delegated to the commerce protocol, payment rail, credential profile, or implementation, and what AP2-native evidence and error pattern is recommended for stale, revoked, replayed, or execution-drifted mandates.

Maintainer guidance on that division would still be very welcome.

[chopmob-cloud]

Thanks for the feedback. This is the most careful reading the proposal has had, and the distinctions you are drawing are the useful kind.

As the ecosystem evolves so will the requirements and the variables. Execution-time revalidation is not a settled problem anywhere in this space, and what counts as sufficient evidence at admission time will keep moving as rails, credential profiles and verifier roles change. Separating what is specified today from what is implementation is how that stays tractable, which is why your framing is worth adopting rather than arguing with.

Taking the correction first, because you are right and it matters more than the rest of the reply.

On request_digest: that was an error in my earlier comment. The Compliance Receipt has no such member. The shape proposed in #269, and documented at docs.algovoi.co.uk/compliance-gate-v1, is seven fields: canon_version, compliance_provider_did, issued_at_ms, jurisdiction_flags, policy_pin, subject_hash, verdict. I conflated two separate layers: the RFC 9421 / RFC 9530 signing of the HTTP request, which is transport-level in our implementation, and the receipt schema, which is not. The receipt does not carry a digest of the executed request. Thank you for checking the document rather than taking the claim at face value.

On the distinction you are preserving. It is the right one and I should have drawn it myself. What is proposed to AP2 in #269 is the Compliance Receipt format and its ALLOW / REFER / DENY enumeration. Both are AlgoVoi-authored, both are open, and neither is AP2 v0.2 normative text. Nothing in my earlier comment should be read as claiming otherwise.

The gate that produces the verdict is a separate thing and is not part of that proposal. It is a commercial implementation. That separation is worth stating plainly, because it also answers part of what you ask later: a published format and a deployed enforcement engine are different objects, and only the first is something I can point you at.

Binding target. The receipt binds one thing: subject_hash is sha256 over the JCS-canonical Payment Mandate or Cart Mandate content. Not the SD-JWT, not the merchant-signed checkout_jwt, not the execution request.

Your parenthetical is the load-bearing part and it is correct: JCS-canonical bytes are not necessarily the original wire bytes. Those are distinct anchors. A signed token has to be anchored over the signed bytes as issued; canonicalisation is the rule for unsigned objects, which is what mandate content is here. A verifier that re-canonicalises a decoded signed payload and hashes that is binding something the issuer never signed. It is an under-specified boundary across this whole ecosystem, and the receipt schema does not resolve it for you.

Semantic comparison. Your reading is correct and I will not argue it. An RFC 9421 signature over an RFC 9530 Content-Digest establishes integrity and authenticity of the covered content. It does not establish that the request semantically satisfies the Checkout or Payment Mandate. The receipt records a verdict and the policy version it was reached under; it does not encode the comparison that produced the verdict.

On commit coupling, consume-once state, and revocation freshness, I think the questions are pointed at the wrong object.

Every one of those is a relation between positions: the admission decision, the action actually executed, and the outcome. A receipt is a single point. You cannot express a relation at a point regardless of how many members you add to it, which is why adding request_digest to the schema would not have answered you either. That constraint applies to AP2's native Mandate Receipt exactly as much as to ours.

Where it is expressible is composition: a content-addressed chain in which the gate verdict, the execution record and the final verdict are separate positions bound to each other by hash. That is published, and it recomputes from the public corpus without importing any AlgoVoi package. The canonicalisation comes from third-party JCS implementations, deliberately, so the corpus is not its own oracle:

git clone https://github.com/chopmob-cloud/algovoi-jcs-conformance-vectors
cd algovoi-jcs-conformance-vectors
pip install rfc8785        # Trail of Bits
npm install canonicalize

python composition/compliance_gate_keystone_v1/verify_compliance_gate_keystone.py   # 5/5
node   composition/compliance_gate_keystone_v1/verify_compliance_gate_keystone.mjs  # 5/5
python composition/spend_decision_chain_v1/verify_chain.py                          # 8/8
node   composition/spend_decision_chain_v1/verify_chain.mjs                         # 8/8

Python and Node agree byte for byte. Every reference is recomputed from its raw fields rather than read back from the trace, and the compliance gate set additionally carries tamper cases that must diverge, including one where a REFER verdict is substituted for the ALLOW the decision was admitted under.

What I am not going to do is describe the transaction boundaries, reservation semantics or fail-open behaviour of the commercial implementation that enforces this. Those are product internals, and a partial answer would invite exactly the scrutiny this reply just failed. But I would separate two claims that are easy to run together: whether the evidence structure can express the property, and whether a given deployment enforces it. The first is answerable from published artifacts. The second is not answerable from any receipt or chain, by anyone, including AP2.

Which is why your closing question is the right one and is for the maintainers. A signed receipt is evidence that a decision was made. It is not a guarantee that only the checked action was committed, and no receipt format will make it one.

[meridianverity]

Thank you. The correction and the explicit separation of the open format proposal from the commercial enforcement implementation resolve the principal ambiguity in the earlier comment.

I agree with the narrower conclusion: the published artifacts can demonstrate deterministic, tamper-evident linkage among declared records, while the enforcement properties of a particular deployment remain a separate assurance question.

I would frame two points slightly differently.

First, a receipt is not unable to express a relation merely because it is one record. A signed record can commit to multiple referenced objects and attest a relationship among them; a content-addressed chain can instead keep lifecycle positions separate. Both are legitimate evidence models.

Their common limit is evidentiary rather than structural: cryptographic linkage shows what was attested and how records are connected. By itself, it does not establish that the live semantic comparison was correct, that a recorded execution corresponds to the external effect that actually occurred, or that decision, replay-state consumption, and commit were atomically and exclusively coupled.

Second, “not provable from a receipt or chain alone” is not the same as “not addressable by AP2.” AP2 can still assign the verification duty, define the exact comparison inputs and binding target, require freshness, replay, and failure behavior, and specify the receipt and error evidence expected from a conforming implementation. A specification cannot make an arbitrary deployment non-bypassable by text alone; that remains a separate conformance and assurance question.

One scope note on the cited reproduction commands: I read them as useful but complementary fixtures rather than a first-principles reconstruction of every lifecycle position.

spend_decision_chain_v1 reconstructs the pre-payment chain. In the current compliance_gate_keystone_v1 verifier, the gate, decision, and cap references are recomputed, while several other anchors in the cap — including the execution reference — are supplied by the published trace.

Using third-party JCS implementations strengthens byte-level reproducibility. It does not independently validate the semantic comparison or the deployment-enforcement claim.

That leaves the maintainer question:

1. Which AP2 role, at which lifecycle boundary, must compare the exact final action with the mandate?
2. Which role owns mutable time-of-use state such as expiry, revocation, cumulative use, and replay?
3. What AP2-native success/error evidence is required, and is any deferred or hold state intended?
4. What is intentionally delegated to the commerce protocol, payment rail, credential profile, or implementation?

I think the implementation example and its limits are now clear. Thank you again for correcting the record. I will leave the remaining normative allocation question with the AP2 maintainers.