Spec section
§3.9.11 rule 2, §2.2, §4.1 (filed as one given most are single line editorial fixes)
Your perspective
Independent agent-identity and attestation service, prospective issuer under §3.9.N.
Kind of feedback
Editorial / clarity
Comment
- §3.9.11 rule 2 (24-hour skew) conflicts with pre-issued open mandates.
The rule requires sub-wrapper timestamps within 24 hours of the delegation artifact's captured_at, with per-protocol rules applying "where the protocol specifies one". An AP2 autonomous-mode Open Checkout Mandate is by definition signed in advance of the transaction it authorises, potentially by weeks, and §3.9.7 carries it as ap2_open_checkout_mandate_sdjwt. Read strictly, rule 2 fails a conformant AP2-Autonomous chain whose open mandate was issued more than a day before use, which would also make the A-tier path in §3.9.12 unreachable in the common case.
We read the intent as applying the 24-hour bound to per-request envelopes (TAP, Web Bot Auth, request_binding) and deferring to the credential's own exp for pre-issued mandates. Worth stating explicitly, since the current phrasing puts the general rule first and the carve-out second. The same question will arise for §3.9.N expires_at once that lands.
- No artifact records the dispute or its outcome.
The chain runs discovery through fulfilment, with refund added post-seal in rc.2. For a specification whose stated purpose is dispute defence, the dispute itself is absent: nothing records that a chargeback was raised, under which reason code, what was submitted, or how it resolved.
Operationally, a merchant holding a sealed bundle and a dispute outcome holds them in two systems with no cryptographic link. The structural consequence matters more. This round contains at least three separate arguments that the §3.9.12 tier prior mis-ranks something: #59 on auth-capture settlement timing, #37 proposing a weighted alternative, #16 on what a recipient can evaluate at all. All three are arguments about a prior, and the corpus contains no mechanism by which that prior could ever be tested against observed outcomes.
A post-seal dispute artifact carrying reason code, submission reference and outcome would give the tier ladder an empirical basis it does not have today, and would let the disagreements in this round eventually be settled by data rather than by argument. Suggested for v1.1.0 alongside the §6.5 annotation artifact, whose late-append mechanics it would share.
- §2.2 prose and Appendix B disagree on expectedArtifactCount.
§2.2 states "the reference implementation's expectedArtifactCount function returns 8/7/6/5 as of v1.0.2", while the Appendix B implementation returns 8/7/6/5 only when protocol !== 'GENERIC' and 7/6/5/5 otherwise. The surrounding §2.2 text describes the GENERIC case correctly in prose, so this is a reconciliation of the parenthetical rather than a substantive disagreement, but the two passages read as stating different things about the same function.
- §4.1 hash-input comment omits refund from the artifact_type enum.
The inline comment in the §4.1 formula lists eight artifact types. Appendix B's ArtifactType correctly includes refund, and §2.7 and §3.8 both carry it. Editorial only.
Submitted as review feedback. This comment is not a Contribution under Apache License 2.0 §5.
Impact if unchanged
No response
Spec section
§3.9.11 rule 2, §2.2, §4.1 (filed as one given most are single line editorial fixes)
Your perspective
Independent agent-identity and attestation service, prospective issuer under §3.9.N.
Kind of feedback
Editorial / clarity
Comment
The rule requires sub-wrapper timestamps within 24 hours of the delegation artifact's captured_at, with per-protocol rules applying "where the protocol specifies one". An AP2 autonomous-mode Open Checkout Mandate is by definition signed in advance of the transaction it authorises, potentially by weeks, and §3.9.7 carries it as ap2_open_checkout_mandate_sdjwt. Read strictly, rule 2 fails a conformant AP2-Autonomous chain whose open mandate was issued more than a day before use, which would also make the A-tier path in §3.9.12 unreachable in the common case.
We read the intent as applying the 24-hour bound to per-request envelopes (TAP, Web Bot Auth, request_binding) and deferring to the credential's own exp for pre-issued mandates. Worth stating explicitly, since the current phrasing puts the general rule first and the carve-out second. The same question will arise for §3.9.N expires_at once that lands.
The chain runs discovery through fulfilment, with refund added post-seal in rc.2. For a specification whose stated purpose is dispute defence, the dispute itself is absent: nothing records that a chargeback was raised, under which reason code, what was submitted, or how it resolved.
Operationally, a merchant holding a sealed bundle and a dispute outcome holds them in two systems with no cryptographic link. The structural consequence matters more. This round contains at least three separate arguments that the §3.9.12 tier prior mis-ranks something: #59 on auth-capture settlement timing, #37 proposing a weighted alternative, #16 on what a recipient can evaluate at all. All three are arguments about a prior, and the corpus contains no mechanism by which that prior could ever be tested against observed outcomes.
A post-seal dispute artifact carrying reason code, submission reference and outcome would give the tier ladder an empirical basis it does not have today, and would let the disagreements in this round eventually be settled by data rather than by argument. Suggested for v1.1.0 alongside the §6.5 annotation artifact, whose late-append mechanics it would share.
§2.2 states "the reference implementation's expectedArtifactCount function returns 8/7/6/5 as of v1.0.2", while the Appendix B implementation returns 8/7/6/5 only when protocol !== 'GENERIC' and 7/6/5/5 otherwise. The surrounding §2.2 text describes the GENERIC case correctly in prose, so this is a reconciliation of the parenthetical rather than a substantive disagreement, but the two passages read as stating different things about the same function.
The inline comment in the §4.1 formula lists eight artifact types. Appendix B's ArtifactType correctly includes refund, and §2.7 and §3.8 both carry it. Editorial only.
Submitted as review feedback. This comment is not a Contribution under Apache License 2.0 §5.
Impact if unchanged
No response