Design Proposal: Standardizing a Pre-Execution Verification Attestation Primitive for v1.0.3

[Avouro]

[UPDATE 2026-07-21]

Updated after reviewer feedback (see my detailed reply below)

• Incorporated issuer, issuer_relationship, and required anchor
• This addresses temporal precedence and §2.8 concerns

Latest schema is available in the reply directly below this post.

[AEP v1.0.3-rc.2 Feedback] Standardizing Pre-Execution Verification Attestations within the Two-Plane Evidence Model (§8.2.1)

Introduction

This Request for Comments (RFC) is submitted in response to the v1.0.3-rc.2 open comment round, focusing directly on the editors' invitation regarding a "compact, network-consumable verification attestation" and the architectural constraints of the Two-Plane Evidence Model (§8.2.1).

We propose exploring an open integration pattern that binds pre-execution verification attestation primitives directly into the AEP framework to establish an immutable "Proof of Intent" before operational data is processed through the post-execution evidence chain.

1. Summary & Core Alignment

The A-Comm Evidence Protocol (AEP) provides an excellent framework for logging post-execution transaction telemetry. However, capturing historical logs post-event leaves an execution blind spot where a hijacked or compromised agent can commit an unauthorized financial transaction before the evidence chain can commit it to a secure ledger.

By layering a generic pre-execution authorization gateway, implementations can inject a compact, runtime cryptographic authorization payload directly into the AEP sequence. This addresses the editors' open prompt regarding a compact, network-consumable verification attestation by providing an early gate that a payment rail can evaluate without parsing heavy post-execution payload layers.

2. Proposed Architectural Flow

We propose binding a standardized execution_authorization_token layer directly into the First Plane (the tamper-evident hash chain) as an input parameter, tightly locking user-approved boundaries to the final payment record.

[ AI Agent Intent Proposed ] 
               │
               ▼
┌─────────────────────────────────────────┐
│ 1. Runtime Authorization Gateway        │
│    - Evaluates intent policy bounds     │
│    - Verifies operational constraints   │
│    - Generates Signed Auth Payload      │
└────────────────┬────────────────────────┘
                 │
                 ▼ (Verified Payload Passed)
┌─────────────────────────────────────────┐
│ 2. A-Comm Evidence Protocol (AEP)       │
│    - Triggers financial settlement      │
│    - Anchors Auth Token + Telemetry     │
│    - Outputs Immutable Evidence Chain   │
└─────────────────────────────────────────┘

Proposed Technical Flow

1. Intent Validation: The AI agent proposes an e-commerce transaction state.
2. Boundary Check: The runtime gateway layer evaluates the execution environment against deterministic rules (e.g., value caps, merchant whitelists).
3. Payload Signing: The gateway generates a signed validation token containing the agent’s cryptographic signature, the target payload hash, and the operational runtime context.
4. AEP Anchoring: The AEP schema ingests this token as a metadata attribute under the §4.3 verification classes.

3. Proposed Schema Extension Layout

Below is a generic structural blueprint of how a standardized pre-execution token maps to existing AEP schema concepts:

{
  "\$schema": "https://json-schema.org",
  "title": "execution_authorization_token",
  "type": "object",
  "required": [
    "token_id",
    "agent_did",
    "policy_bounds",
    "payload_hash",
    "signature"
  ],
  "properties": {
    "token_id": {
      "type": "string",
      "format": "uuid",
      "description": "Unique cryptographic identifier for the pre-execution gateway pass."
    },
    "agent_did": {
      "type": "string",
      "pattern": "^did:[a-z0-9]+:.*",
      "description": "Decentralized Identifier (DID) of the executing AI agent."
    },
    "policy_bounds": {
      "type": "object",
      "required": ["max_amount", "currency", "merchant_whitelist"],
      "properties": {
        "max_amount": {
          "type": "number",
          "minimum": 0,
          "description": "Hard deterministic transaction limit checked at runtime."
        },
        "currency": {
          "type": "string",
          "pattern": "^[A-Z]{3}\$",
          "description": "ISO 4217 currency code constraint."
        },
        "merchant_whitelist": {
          "type": "array",
          "items": { "type": "string" },
          "description": "Array of approved merchant identifiers or contract addresses."
        }
      }
    },
    "payload_hash": {
      "type": "string",
      "description": "SHA-256 hash of the proposed transaction intent state to prevent tampering."
    },
    "signature": {
      "type": "string",
      "description": "Cryptographic signature from the gateway verifying execution safety boundaries."
    }
  }
}

4. Feedback for Editors

To the engineering team and specification editors:

• Are there existing metadata hooks or extensible payload attributes within the current §8.2.1 Two-plane evidence model or §4.3 anchoring classes where a generic execution-time authorization token of this type can be cleanly bound?
• Would the editors prefer this design direction to be introduced as a first-class sub-wrapper in v1.0.3, or deferred to the v1.1.0 independently versioned extension registry referenced in the open questions?

---

Signed-off-by: Odoemelam Favour odoemelamfavour19@gmail.com

[Avouro]

Thanks editors. One small suggestion to make this actionable for v1.0.3:

Proposed Compliance Requirement:
Payment rail implementations consuming the AEP payload MUST verify the execution_authorization_token signature and validate policy_bounds prior to initiating downstream settlement. If this validation fails, the transaction MUST NOT proceed and an explicit verification failure class MUST be appended to the Second Plane hash chain.
This explicitly binds user-approved intent to execution and programmatically closes the pre-execution blind spot.

[sftimeless]

Strong agreement on the diagnosis. Post-hoc telemetry cannot establish that boundaries existed before the action, and closing that gap is worth doing in the spec rather than leaving it to implementations. One structural issue in the current design that I think needs resolving before the primitive is worth standardizing.

The token inherits §4.3.

§4.3 is explicit that "the chain and its signature are produced by the implementing party; they attest to integrity, not to existence at a point in time as against that party." An execution_authorization_token that is signed by the gateway and anchored only into that same chain has exactly this property. It proves internal consistency. It does not prove the token existed before the action, as against whoever issued it.

That limitation is tolerable for post-execution telemetry, where the settled transaction independently corroborates much of the record. It is not tolerable for a pre-execution token, because temporal precedence is the token's entire evidentiary claim. A party able to regenerate and re-sign the chain is equally able to mint a token after the fact whose policy_bounds happen to match what occurred. Against an adversary inside the issuing party, the token adds no information the settlement record does not already imply.

This creates an internal inconsistency with §2.8.

§2.8 defines Asserted as an unsigned or uncorroborated claim by a single party and states it MUST NOT be relied on alone, and §6.2 assigns the Asserted class to a self-verified bundle that carries no external anchor. A gateway-signed, unanchored token is that case. So the compliance requirement proposed above, that rails MUST verify the signature and validate policy_bounds before settlement, would have payment rails gating settlement on an artifact the specification itself classifies as not independently relyable. Either the token needs to clear a higher class, or the MUST needs qualifying. I would prefer the former.

Two ways to close it, and they are complementary.

Issuer independence. The schema currently identifies the agent (agent_did) but not the issuer. The signature is described only as "from the gateway," with no requirement that the gateway be distinct from the party that executes or settles the transaction. Since the token's value depends entirely on who attests to it, the issuer should be a first-class, declared field, and its relationship to the settling party should be explicit rather than inferred.

Anchoring as MUST for this artifact specifically. External anchoring is currently RECOMMENDED (§4.3). I would argue it should be REQUIRED for the pre-execution token even if it remains RECOMMENDED for the broader chain, precisely because existence-before-the-action is the only thing this artifact asserts. An RFC 3161 timestamp token, a transparency-log inclusion proof (RFC 6962 style), or an independent counter-signature would each suffice.

Suggested schema delta, additive and compatible with the layout above:

"issuer":               identity of the signing authority, distinct from agent_did
"issuer_relationship":  enum { independent, merchant_operated, psp_operated, self_operated }
"anchor": {
    "type":   enum { rfc3161, transparency_log, counter_signature, none },
    "proof":  anchor-specific verification material,
    "time":   asserted anchor time
}

With issuer_relationship: self_operated and anchor.type: none, a verifier can correctly resolve the token to Asserted rather than treating a valid signature as sufficient. That is the outcome the current draft cannot express.

On the evidence tiers. Relatedly, the S/A/B/C/D strength tier presently rewards how completely a bundle composes wrapped signals. Two bundles can compose identically while one is wholly self-issued and self-anchored and the other is externally anchored and issued by a party with no interest in the outcome. Those are not equal evidence, and a tier that cannot separate them will be read as stronger than it is by anyone relying on it downstream. Independence of attestation and anchoring state seem like the natural second axis.

On the v1.0.3 versus v1.1.0 question raised above: the primitive itself can reasonably defer to the extension registry, but the anchoring and issuer-independence requirements should not defer with it. If the token ships first and the trust requirements arrive in a later version, the weaker pattern becomes the de facto baseline and every early implementation encodes it.

[Avouro]

Thank you for this rigorous architectural review. Your critique regarding temporal precedence and the self-issued consistency loops under §4.3 and §2.8 is entirely correct. For a pre-execution token to deliver definitive evidentiary value to downstream payment rails, existence-before-the-action must be mathematically irrefutable — even against the issuing party itself.

The suggested schema delta is an excellent, additive solution. By mandating an explicit issuer declaration and required external anchoring, we can elevate this token above the "Asserted" class and align it with the zero-trust objectives of the design.

Here is the updated, integrated JSON Schema incorporating your recommendations:

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "execution_authorization_token",
  "type": "object",
  "required": [
    "token_id", "agent_did", "issuer", "issuer_relationship",
    "policy_bounds", "payload_hash", "anchor", "signature"
  ],
  "properties": {
    "token_id": {
      "type": "string",
      "format": "uuid",
      "description": "Unique cryptographic identifier for the pre-execution authorization token."
    },
    "agent_did": {
      "type": "string",
      "pattern": "^did:[a-z0-9]+:.*",
      "description": "Decentralized Identifier (DID) of the executing AI agent."
    },
    "issuer": {
      "type": "string",
      "description": "DID or public key identifier of the signing authority."
    },
    "issuer_relationship": {
      "type": "string",
      "enum": ["independent", "merchant_operated", "psp_operated", "self_operated"],
      "description": "Explicit relationship between the issuer and the settling party."
    },
    "policy_bounds": {
      "type": "object",
      "required": ["max_amount", "currency", "merchant_whitelist"],
      "properties": {
        "max_amount": { "type": "number", "minimum": 0 },
        "currency": { "type": "string", "pattern": "^[A-Z]{3}$" },
        "merchant_whitelist": { "type": "array", "items": { "type": "string" } }
      }
    },
    "payload_hash": {
      "type": "string",
      "description": "SHA-256 hash of the proposed transaction intent to bind the policy bounds."
    },
    "anchor": {
      "type": "object",
      "required": ["type", "proof", "time"],
      "properties": {
        "type": {
          "type": "string",
          "enum": ["rfc3161", "transparency_log", "counter_signature", "none"]
        },
        "proof": {
          "type": "string",
          "description": "Anchor-specific cryptographic proof material (e.g. RFC 3161 TST, Merkle inclusion proof, etc.)."
        },
        "time": {
          "type": "string",
          "format": "date-time",
          "description": "Timestamp asserted by the external anchor."
        }
      }
    },
    "signature": {
      "type": "string",
      "description": "Cryptographic signature over the token by the declared issuer."
    }
  }
}

Key resolution: With issuer_relationship: self_operated and anchor.type: none, verifiers can correctly classify the token as Asserted per §2.8/§6.2. When stronger issuer independence or anchoring is present, it qualifies for a higher evidence tier. This eliminates the previous internal inconsistency.

Path to Implementation (v1.0.3)

I agree completely — deferring these trust primitives to v1.1.0 would risk locking in a weak de facto baseline. If the editors are open to it, I propose pulling this updated token definition into the v1.0.3 additive release. This gives early implementers a solid, secure foundation without bloating the core spec.

[krystal-gracier]

Hi both, @sftimeless @Avouro . Thank you for this discussion. I really appreciate the depth and dialogue. @sftimeless eless's structural critique is correct on every point it makes, and @Avouro ro's amended schema adopts it faithfully.

Here is my response:

Disposition: accept-with-modification (primitive), decline (settlement-gating requirement)
Thank you both — this thread is exactly what the comment round is for. This response records the editors' disposition, corrects two section-reference issues, and proposes the concrete landing spot for v1.0.3-final. It will be recorded in the COMMENT-ROUND.md disposition log.

1. Corrections to the framing
   §8.2.1 is not the right hook. The Two-Plane Evidence Model concerns PII custody — the pseudonymized chain plane versus the encrypted raw plane held by an Evidence Custodian. It has no slot for authorization semantics. The correct home for this primitive is §3.9 (Delegation & Protocol Metadata), which is where every handshake that "authorizes the transaction" is already witnessed. Adding a new optional §3.9.N sub-wrapper is additive MINOR scope under §0.2, so it can land in v1.0.3-final without deferral.

The "v1.1.0 extension registry" does not yet exist. It is open question #3 of this comment round. Deferring to it would mean deferring to a mechanism that is itself undecided which reinforces @sftimeless ss's argument against deferral.

2. What the spec already covers and the genuine gap
   Much of the proposed token duplicates existing machinery: user-approved bounds are carried by AP2 mandates (§3.9.7), Mastercard Verifiable Intent constraint families (§3.9.15), and KYA Pay constrained spend authorizations (§3.9.17); agent identity by TAP/KYA/Web Bot Auth (§3.9.6/.16/.18); and the pre-authorization bounds check by the mandatory §3.4 Policy artifact ("implementors MUST never authorize a transaction without a preceding policy artifact").

What none of these provide and what this thread correctly identifies as the gap is proof of temporal precedence: independent evidence that the authorization material existed before execution. §4.3's external anchoring applies to the sealed chain and exported bundles, i.e. after the fact. A pre-execution anchor is genuinely new, and we agree it belongs in the core spec rather than a later revision, precisely because a self-issued, unanchored variant would otherwise become the de facto baseline.

3. Proposed landing: §3.9.N pre_execution_attestation (optional sub-wrapper)
   Adopting the amended schema, with additions the thread has not yet covered (replay, expiry, binding mode):

"pre_execution_attestation": {
  "token_id":            "string — UUID (required)",
  "agent_did":           "string (required)",
  "issuer":              "string — key-discovery URL or DID (required)",
  "issuer_relationship": "'independent' | 'merchant_operated' | 'psp_operated' | 'agent_platform_operated' | 'self_operated' (required)",
  "policy_bounds": {
    "max_amount":         "integer, minor units (required)",
    "currency":           "ISO 4217 (required)",
    "merchant_allowlist": "array of §2.7 merchant_id values — exact match, not domains (optional)"
  },
  "binding": {
    "mode":      "'closed' | 'open' (required)",
    "chain_id":  "string — §2.7 chain_id (required)",
    "cart_hash": "string — §3.5 cart current_hash (required when mode = 'closed')"
  },
  "issued_at":  "ISO 8601 UTC (required)",
  "expires_at": "ISO 8601 UTC (required)",
  "signature":  "issuer signature over the canonicalized token (required)",
  "anchor": {                                     // required — no anchor, no wrapper
    "type":  "'rfc3161' | 'transparency_log' | 'counter_signature'",
    "proof": "TSA token | inclusion proof | counter-signature",
    "time":  "ISO 8601 UTC — time attested by the anchor"
  }
}

The closed/open binding modes mirror the AP2 closed/open mandate distinction the spec already tier-distinguishes: closed binds the approval to the exact cart; open records standing bounds approved before cart composition.

Verification rules (new §3.9.11 entries):

1. signature verifies against the issuer's published key via the issuer's canonical key-discovery path.
2. anchor.proof verifies independently, and anchor.time MUST precede the §3.6 authorized_at. Verifiers SHOULD apply a documented clock-skew tolerance and MUST record the delta in the verification result.
3. binding.chain_id MUST equal the chain's chain_id; in closed mode, cart_hash MUST equal the §3.5 cart artifact's current_hash. This makes the token single-transaction by construction — replay across chains fails binding.
4. authorized_at MUST NOT exceed expires_at.
5. Bounds conformance (amount within max_amount, merchant in allowlist) is computed and recorded as a deterministic boolean in the verification result — with an explicit carve-out noting that incremental authorizations and partial captures can legitimately move the final settled amount after approval; the boolean attests conformance at authorization time only.

Signal classification and tiers (§2.8, §3.9.12): issuer_relationship = 'self_operated' with only a self-controlled anchor classifies Asserted, exactly as @sftimeless argued. A verified independent anchor upgrades the temporal-precedence claim to Attested even when the issuer is self-operated — the anchor is the independent party. An independent or psp_operated issuer plus a verified anchor is fully Attested. For tier placement we propose the request_binding precedent: a verified attestation raises confidence within a tier, and in combination with a user-authorized commerce-delegation wrapper is eligible for explicit tier uplift; exact placement is open for comment. We expect early

4. Declined: the settlement-gating requirement
   The proposed clause — payment rails MUST verify the token and validate bounds before settlement — is declined, for scope rather than security reasons. AEP's normative posture is that it is parallel to the transaction and never gates it (§9.2/§9.3: not a payment processor, not a fraud-decisioning platform), and §3.9.12 carries an explicit no-network-consequence, no-adverse-inference disclaimer. A MUST that blocks settlement on an AEP artifact would relocate AEP into the payment path, contradict those clauses, and jeopardize the §9.4 regulatory classification that the two-plane model and the rest of rc.2 are built on. It would also gate money movement on an artifact that, in the common self-operated case, is Asserted — the very inconsistency this thread identified.

Enforcement is real and valuable — it just belongs to the rails and the payment protocols (AP2 and Mastercard VI already perform it). AEP's role is to witness enforcement: where a rail, PSP, or gateway does verify the attestation, the verification outcome is recorded as a deterministic field on the chain, the same way avs_result and three_ds_result witness rail-side checks today. Commenters who want a rail-consumable artifact should look at open question #4 of this round (a compact, network-consumable verification attestation) — that is the right vehicle for the settlement-side half of this proposal, and this thread is a strong argument for prioritizing it.

5. Open questions for this thread

6. Issuer key discovery: /.well-known URL, DID document, or both?

7. Anchoring latency at checkout: is batched Merkle anchoring with a later-delivered inclusion proof acceptable if the log checkpoint time still precedes authorized_at?

8. Should expires_at carry a normative maximum lifetime (e.g., relative to issued_at), or is that deployment policy?

9. Is agent_platform_operated a needed fifth issuer_relationship value, or does self_operated cover the agent's own platform?

10. Allowlist semantics for marketplaces: is §2.7 merchant_id exact-match sufficient, or is a seller-of-record distinction needed?

11. Disposition will be logged as: accept-with-modification — pre-execution attestation lands as an optional §3.9.N sub-wrapper in v1.0.3-final with required issuer, issuer-relationship, anchor, binding, and expiry; decline (rationale above) — normative settlement gating, replaced by witnessed-enforcement fields and cross-referenced to open question Design Proposal: Standardizing a Pre-Execution Verification Attestation Primitive for v1.0.3 #4.