[Proposal]: Optional Bitcoin-anchored proof-of-when for signed Mandates (extension, outside signed bytes)

[MarkovianProtocol]

AP2 mandates (Intent / Cart / Payment) are verifiable credentials: the signature proves who authorized and what was authorized. The embedded timestamp, though, is asserted by the signer. For chargeback and audit, the contested question is often when: did this mandate exist before the disputed charge, before a price change, before a revocation? A self-asserted clock is weak evidence against a motivated counterparty.

This is distinct from the post-checkout action record in #290 and the settlement-side bindings in #255 / #224. Those record what happened after authorization. The proposal here anchors the authorization artifact itself, and is orthogonal to all of them.

Proposal: attach an optional markovian-provenance/v1 commitment to a mandate as an extension, carried outside the signed bytes so it never affects VC verification. The issuer hashes the canonical mandate, POSTs the hash to an external service, and stores the returned record (a Merkle inclusion in an append-only transparency log whose checkpoints are cosigned by independent witnesses and anchored to Bitcoin). Later, any verifier re-hashes the mandate and checks the anchor with no account. The VC proves who, the anchor adds an independent proof of when.

Honest boundary: this is provenance, not truth. It proves a mandate existed at a point in time, it does not validate the payment, the authority, or the agent's behavior. It is additive, not a replacement for the signature or any settlement attestation, and it requires no change to the mandate schema (an extension field only).

Shape — canonicalization pinned to one frozen profile:

anchored = "sha256:" + hex(SHA-256(JCS(mandate)))

where JCS is RFC 8785, so any stock JCS library re-derives the same digest from the same mandate, this year or in ten. Where a mandate exists as a signed token, the anchor hashes exactly the issuer-signed JWT bytes — the byte string the issuer's signature covers, not a re-canonicalization of the decoded payload, and not the presented token (presentations vary by disclosed subset; the issuer JWT is frozen). The extension states which form was hashed — one input byte form, named, never two. Store {merkle_root, block_height, verify_url} as a mandate extension. Verification is a plain GET https://markovianprotocol.com/anchor/<sha256-hex> returning a JSON verdict — anchored digest, merkle root, block height, pass/fail — no account, no payment.

Repo (Apache-2.0): https://github.com/MarkovianProtocol/markovian-protocol
Site: https://markovianprotocol.com

---

Edited 2026-07-19: pinned the canonicalization profile to RFC 8785 and the signed-token byte rule (issuer-signed JWT, not the presented token — per the discussion below), replaced the legacy quantsynth endpoints with the current markovianprotocol.com witnessed log, and specified the machine-readable JSON verify response.

[AmitabhainArunachala]

Operational datapoint from a live mandate-verification endpoint — this proposal closes a real gap we hit in production.

We run a paid /mandate/verify endpoint (Base mainnet, USDC, x402-gated at $0.25) that checks 7 mandate properties: authority, scope/resource binding, spend cap, recipient binding, expiry, nonce/replay protection, and receipt obligation. The expiry check (#5) is exactly the "when" question this proposal addresses: we verify the mandate's self-asserted timestamp against the current block time and reject if expired. But we can only reject late mandates — we cannot prove a mandate existed before a revocation or price change, because the timestamp is self-asserted and the signer controls it.

That is the precise boundary the markovian-provenance/v1 extension fills. The 7-check matrix answers "is this mandate valid right now?" The Bitcoin-anchored commitment answers "did this mandate exist at the claimed time?" — and the two are orthogonal by design, which is the right decomposition. A mandate that passes all 7 checks but was backdated after a price change would slip through our verifier; the anchor commitment is what stops that.

One integration question: the proposal says the hash is posted to an external service and stored as a mandate extension. For an AP2 verifier consuming this, the question is whether verify_url should be resolvable by an agent programmatically (machine-readable JSON) vs. a human-facing page. Our /mandate/verify returns a structured JSON verdict with a tier (REJECT/REVIEW/ACCEPT) and per-check pass/fail — if the provenance anchor were checkable the same way (programmatic JSON, no account), we could wire it as check #8 in the matrix without changing the mandate schema.

If you have a sample anchored mandate (canonical hash + the {merkle_root, block_height, verify_url} record), send it — we'll run it through the matrix and confirm the integration path. The endpoint is https://x402.167-172-95-184.nip.io/mandate/verify (POST, $0.25 on Base/USDC).

[chopmob-cloud]

This is a useful decomposition, and the orthogonality (the VC proves who and what, the anchor proves when) is the right boundary. One capability point on the part everything else rests on: the canonical hash.

The proposal anchors sha256(canonical mandate) and has any verifier re-hash the mandate later to check the anchor. That only holds if "canonical" is one frozen profile, and it is a sharper requirement here than in an ephemeral check. The Bitcoin anchor is immutable and the re-hash happens later, on a different stack than the issuer. If that verifier's serializer escapes a non-ASCII field differently, normalizes a number differently, or orders non-BMP keys differently, it derives a different digest, misses the anchored commitment, and the proof-of-when fails for an honest mandate that was in fact anchored. And it cannot be re-anchored to fix it.

RFC 8785 (JCS) pins escaping, number form, and key ordering, so:

anchored = "sha256:" + hex(SHA-256(JCS(mandate)))

recomputes byte-identically from any stock JCS library, this year or in three years. And if AP2 defines a canonical form for the mandate elsewhere (for the VC signature, or a mandate hash), the anchor should reuse exactly that one rather than introduce a second, so a single canonical form covers both the signature and the anchor.

On @AmitabhainArunachala's check-8 question: agree the anchor verify should return machine-readable JSON with no account, the same shape a verifier already consumes for the other checks, so the proof-of-when slots into the matrix instead of sitting as a human-facing page.

We maintain an open RFC 8785 conformance corpus, cross-validated byte-identical across independent implementations in ten languages: https://github.com/chopmob-cloud/algovoi-jcs-conformance-vectors . Happy to contribute mandate-canonicalization anchor vectors (a canonical mandate, its anchored digest, and the escaping, number, and non-BMP cases that would make a re-hash miss the anchor), so the anchor path is pinned to something reproducible rather than issuer-specific.

[MarkovianProtocol]

@chopmob-cloud You're right, and the proposal text should say it explicitly. The intended definition is:

anchored = "sha256:" + hex(SHA-256(JCS(mandate)))

where JCS is RFC 8785. That's already how our claim format works under the hood — we serialize with RFC 8785 before hashing — but the text just says "canonical mandate," which leaves the door open to exactly the mismatch you describe. I'll edit the body to pin it.

Good point on not introducing a second canonical form. AP2 mandates are signed as SD-JWTs, and the signed token is already a stable string of bytes — where that's the form the mandate lives in, the anchor should just hash those bytes. RFC 8785 only matters when a mandate gets passed around as raw JSON and re-serialized. I'll defer to the maintainers on which form the spec names, but it should name one.

And yes on the vectors — happy to take those. The escaping, number-form, and non-BMP cases would go into the proposal's test vectors as "re-hashing these must still find the anchor" cases, credited to your corpus.

@AmitabhainArunachala Machine-readable, yes. Verification should be a plain GET that returns JSON — anchored digest, merkle root, block height, pass/fail — no account, no payment required. To be upfront about current state: the verify_url in the proposal points at a human-readable page today, not JSON. The JSON response is what the spec will require, and I'll post a sample mandate in this thread once the RFC 8785 edit is in, so you can run it as check #8.

[chopmob-cloud]

Agreed on both, and the SD-JWT case makes the anchor simpler, not harder, as long as it targets the right layer.

The issuer signature over an SD-JWT covers the issued JWT, the compact JWS signing input, which is an exact frozen byte string. Anchor sha256 of the issuer-signed JWT and JCS does not enter at all: you hash what the issuer signed, not a re-canonicalisation of the decoded payload. Re-canonicalising there would be the bug, because JCS of the decoded object is a different byte string than the one the signature covers, so the anchor would stop binding the signed artifact.

One SD-JWT precision: anchor the issuer-signed JWT, not the presented token. A presentation carries a holder-selected subset of disclosures, so the presented bytes vary while the issuer JWT does not. Proof-of-when should bind the issuer's frozen commitment, which is the JWT the signature covers.

So the boundary is clean, two cases:

• Signed token (SD-JWT / JWS): anchored = "sha256:" + hex(SHA-256(issuer-signed JWT bytes)). The signature already provides the frozen form; a verifier hashes the signed JWT, never a re-encode.
• Bare JSON object (nothing signs it into fixed bytes): anchored = "sha256:" + hex(SHA-256(JCS(mandate))), RFC 8785, because there is no canonical byte form otherwise.

Same rule underneath both: the anchor must bind the exact bytes a later verifier can reproduce. For a signed mandate that is the issuer-signed JWT; for an unsigned object it is its JCS form.

[MarkovianProtocol]

Right — issuer-signed JWT, not the presented token; that's the correct frozen artifact. I've folded the two-case rule into the body as you stated it.