[bug] §2.2 / §3.9.2: a storefront checkout by an agent cannot carry the agent's identity — `direct_web` forbids the Delegation artifact that §3.9.2 requires

[jyothi-acomm-ai]

Affected section(s)

§2.2, §3.9.2, Appendix B (expectedArtifactCount); §3.1 (secondary)

Severity

Major — implementations will diverge or carry real risk

Description

An AI agent acting for a consumer can buy through a merchant's standard storefront checkout without an AI referral. The consumer's own agent navigates to the store and checks out. No transaction type accommodates that purchase, and the two rules that apply to it contradict each other.

1. The rules conflict. §3.9.2: "Delegation MUST be present when ANY of the following protocols is in play: TAP, AP2, ACP, UCP, MCP, x402, A2A, MASTERCARD_VI." The §2.2 row for direct_web (Direct arrival, Standard storefront checkout) reads "No discovery, referral, or delegation artifacts", and Appendix B returns 5 for direct_web regardless of protocol ("delegation never present"). An agent presenting any listed credential at a direct storefront checkout is subject to both rules, and no chain can satisfy both.

2. The agent's identity has no place to go. Delegation is the only artifact that carries agent identity: the §3.9 sub-wrappers, the identity-transport slot that §3.9.16 vs §3.9.N: identity-transport slot is vendor-shaped where the newer attestation primitive is issuer-neutral #69 asks to make multi-issuer, and the verified_identity sub-wrapper accepted in I26. If a producer omits Delegation to satisfy direct_web, the chain loses the most verifiable evidence of who transacted. The only remaining trace of the agent is actor_type: agent on the artifacts it produced, which is unverified.

3. Completeness breaks whichever rule the producer follows. Verification requires total_artifacts == expectedArtifactCount(transaction_type). A direct_web chain that includes Delegation to satisfy §3.9.2 has six artifacts against an expected five, and is reported chain_complete: false even though it is fully evidenced. (The §2.2 prose calls the counts "minimums"; the verification rule is an equality. That is a separate inconsistency, noted here because it decides the outcome.)

4. "Agent present, no credential" has no representation. When an agent transacts without presenting any listed protocol, §3.9.2 requires Delegation to be omitted (protocol = GENERIC, no sub-wrapper). That is correct, but the chain then cannot distinguish "no agent was involved" from "an agent was involved and identified itself with nothing verifiable". Both produce the same five-artifact direct_web chain.

5. Secondary, §3.1: platform admits only 'chatgpt' | 'gemini' | 'perplexity' | 'copilot' | 'meta', and Discovery "can be populated only by the AI platform itself", so an AI platform not on the list cannot emit a conformant Discovery artifact. The informative note says the enum "is expected to move to a registry process", but no registry exists and the normative text offers no interim value. discovery_source.protocol already carries 'other', and apd.platform is string | null.

Found while building a conformant chain for an agent-mediated purchase. We recorded it as agent_session_only, which requires no Discovery or Referral artifact. That type describes a merchant-operated agent session, so the choice was a workaround rather than an accurate classification.

Proposed resolution

1. Resolve the contradiction in §3.9.2's favour. §2.2 and Appendix B apply the existing §3.9.2 rule to every transaction type: Delegation is present whenever a covered protocol is in play or a sub-wrapper is populated, including in direct_web and ai_referral_standard_checkout. Appendix B then computes direct_web as hasDelegation ? 6 : 5, as it already does for the other three types. This is the same move I26 made for GENERIC chains, applied to the remaining transaction types, and it gives the identity slot proposed in §3.9.16 vs §3.9.N: identity-transport slot is vendor-shaped where the newer attestation primitive is issuer-neutral #69 a place to attach on storefront checkouts.
2. Name the uncredentialed case. Either add a transaction type for a consumer-side agent at a storefront checkout, or define a chain-level or Intent-level marker recording that an agent actor was present with no verifiable credential, classified Asserted under §2.8. The editors may prefer to defer this part to v1.1.0. It is raised so that the absence can be recorded explicitly rather than left indistinguishable from "no agent".
3. §3.1: add 'other' to the platform enum, matching discovery_source.protocol, with an optional platform_label (Inferred) as a migration path to the anticipated registry. Under the I33 disposition, a Discovery artifact without a platform co-signature is Asserted, so 'other' confers no additional weight.

Change class and sequencing. (1) and (3) are additive (MINOR): no hash-input semantics change, and existing chains remain valid. (1) changes Appendix B's counts. It therefore has to land in the same edit as #70 item (c) and the I26 count change, or the §2.2 / Appendix B mismatch those items resolve comes back.

Security

No security implications.

Filing notes

Filed after the 14 August window. It reports a contradiction between normative rules in text v1.0.3-final is still editing, rather than proposing a new capability, and is offered for an in-scope ruling on that basis. Item (2) of the proposed resolution is the exception and may be deferred.

Filed by an editor-affiliated implementer. Per CONTRIBUTING.md, the disposition should be recorded by a second editor.

Related: #26, #69, #70 (item c), #33.