Summary

  • The IETF archive announced revision 02 of the individual VCAP Internet-Draft on 4 September. It has no IETF endorsement, formal standards standing, RFC stream or responsible Area Director.
  • The revision adds a verifier-accountability section that acknowledges marketplace power over settlement, requires registration and dispute records, and recommends mutually selected third-party verifiers.
  • A provider nevertheless submits service_delivery with an optional auto_approve hint defined as skipping automated verification because the provider self-attests.
  • The draft does not say who may accept that waiver, what agreement authorizes it, who produces the required callback, what criteria remain active or how the choice is retained with settlement.
  • Operators need a verification-waiver receipt joining proposer, accepting authority, contractual basis, limits, expiry, callback signer, conflicts, dispute path and final fund state—not an assumption hidden behind a signed result.

Accountability arrived for the ordinary path

The IETF announcement records a narrow event: a 30-page Internet-Draft by Ben Stone became available on 4 September. The Datatracker entry sets the authority boundary. This is an active individual submission. Anyone may submit an Internet-Draft; this one is not endorsed by the IETF and has no formal standing in its standards process, RFC stream or responsible Area Director. “Informational” is an intended destination in the draft header, not a status it has achieved.

Inside that boundary, revision 02 proposes a consequential machine. A requester and provider agree on work and price. A marketplace holds funds. The provider delivers. A verifier checks the delivery and sends a callback. A true passed value moves verification to VERIFIED and the escrow toward release; false moves it toward refund. The draft calls the callback its most critical message because it triggers settlement.

The official diff shows the most important governance repair since revision 01: a new section on verifier accountability. It states the conflict directly. When a marketplace selects verifiers, it effectively controls settlement outcomes. Before accepting results, it must register and trust the verifier’s key or method, record claimed capabilities and define an escalation path. Registrations, rotations and removals must be timestamped and retained beside settlement records.

Where the marketplace also controls the verifier, the draft says implementations should support a third party selected by mutual agreement between requester and provider. It also says marketplaces should publish which verifier types serve which categories, how conflicts are managed and how contested results escalate. Those provisions do not eliminate discretion, but they make its location visible.

The modal verbs matter. Key registration, capability recording, a dispute path and registration history are mandatory for the proposed protocol. Mutual third-party selection and publication of selection policy are recommendations. The design therefore leaves room for different local risk arrangements, which is sensible. A small routine transaction and a costly subjective commission need not share one tribunal. What must not vary invisibly is who had the right to relax the agreed evidence.

The provider carries the skip switch

The ordinary flow is not the only flow described. The provider sends service_delivery to claim completion. That message contains artifacts and verification_hints: a URL, a selector, expected content, a request to compare fingerprints—and auto_approve. The field is optional. Its description is terse: if true, skip automated verification; the provider self-attests.

The machine-readable service-delivery schema linked by the draft makes the origin even clearer. It describes the provider as the agent submitting delivery and says the provider’s hints can “override or supplement requester hints.” The flag defaults to false, but a default is not an authorization rule. It says what an absent value means, not who may turn it on or whose consent makes that choice effective.

Across the fixed -00, -01 and -02 documents, auto_approve appears only twice in each version: once in the message example and once in the hint table. The surrounding text does not say whether a marketplace must ignore an unauthorized true value, ask the requester, look for a negotiated clause, impose a value ceiling, retain some objective checks or route the choice to a human. It defines no expiry, revocation, conflict rule or audit entry for the waiver.

That absence should not be inflated into an incident. The documents do not show that any implementation accepts the flag, still less that a provider has used it to compel a payout. A cautious operator may ignore it. Another may allow it only when both parties agreed in advance. A third may translate it into a marketplace policy decision. The problem is exactly that all three behaviours can be imagined from the same field description, while the protocol claims to make settlement evidence portable.

There is also no defined bridge from “skip automated verification” to the mandatory callback. A normal callback carries passed, a proof hash, a proof signature, a verifier key identifier, an action log and completion time. If there was no automated verification, who is the verifier? Does the provider sign its own self-attestation, does the marketplace sign an acceptance decision, or does a human create the callback? What belongs in an action log when the action was deliberately omitted? The current text does not answer.

A signed result can omit the waiver

The cryptographic machinery is useful. The proof hash is SHA-256 over a canonical proof bundle. The Ed25519 signature covers the verification, negotiation and escrow references, the passed value, proof hash, verifier key identifier and completion time. RFC 8032 supplies the underlying signature specification. Anyone with the correct public key can test whether those bytes were signed under the corresponding private key.

That is not the same as testing who authorized a waiver. VCAP’s own security text says the hash shows that proof content was not altered and the signature shows that it came from an authorized verifier. Neither field names the provider as waiver proposer, identifies requester consent or preserves the contract clause that permitted self-attestation. A perfectly valid signature can therefore sit after an institutionally ambiguous choice.

Atomic settlement does not fill the gap. Compare-and-swap prevents two processes from releasing and refunding the same hold. Idempotency prevents a retry from settling twice. These are strong state-machine properties. They guarantee one terminal transition, not the legitimacy of the path that selected it.

The timeout rule demonstrates what a complete exception path looks like. If verification does not finish, funds remain HELD. The marketplace should create a manual-review item, and a human must make the final settlement decision. That reviewer issues an ordinary callback with a true or false result, a single action-log entry documenting the decision, and the usual hash and signature. The system can later answer who decided, through which message and against which evidence.

auto_approve deserves at least that clarity. Self-attestation may be a legitimate commercial choice. A requester may prefer lower fees and instant settlement for a trusted provider, or accept it below a small value. But “allowed by the agreement” and “requested by the beneficiary at delivery” are not equivalent states.

The linked schemas show why executable custody matters

The public artifacts are not synchronized at the cutoff. The linked verification-callback schema still requires an HMAC-SHA256 hexadecimal value, admits only version 1.0 and lacks verifier_key_id. Revision 02 instead mandates an Ed25519 Base64 signature and the key identifier, while telling implementations to inspect vcap_version to choose the algorithm. The repository’s commit history shows that the linked schema set was not updated with the September submission.

This is not proof of a production failure. It is a warning about what implementers can actually execute. A prose reader following the newest draft and a validator following the linked schema receive different callback contracts. The same discipline applies to the waiver: unless its authorization is machine-readable, local implementations will invent incompatible answers.

The current draft also corrects an earlier description of AP2. AP2 defines mandate and payment-evidence roles; VCAP-02 no longer assumes AP2 supplies escrow, capture, refund or settlement transitions. That makes ownership inside VCAP more important, not less. The bypass cannot be assigned to an upstream protocol by implication.

Write a waiver receipt before moving funds

A small receipt can close the gap without mandating one global verifier. It should name the transaction, negotiation and escrow; the exact VCAP text and schema hashes; the provider proposing self-attestation; the agreement clause that allows it; the requester and marketplace actors accepting it; the verifier-selection rule it displaces; every criterion waived and every check retained; the reason, value and risk ceiling; effective time, expiry and revocation; the callback mode and signer; any conflicting evidence; the dispute path; and the final fund state.

The receipt should exist before settlement. If a marketplace cannot resolve the clause or accepting authority, it should reject the flag or keep funds held. It should not guess that a provider-controlled hint inherited requester consent from an unrelated acceptance earlier in the negotiation.

This preserves local choice. Parties can allow self-attestation for some services, require independent verification for others and use a human for subjective work. What travels across systems is only the minimum fact needed for accountability: who was empowered to choose the exception, what limits applied and what consequence followed.

Sources

  1. IETF announcement of VCAP revision 02
  2. IETF Datatracker status
  3. VCAP revision 02
  4. VCAP revision 01
  5. Official revision 01–02 diff
  6. VCAP service-delivery JSON Schema
  7. VCAP verification-callback JSON Schema
  8. VCAP specification repository history
  9. RFC 8032 — EdDSA
  10. Google Agent Payments Protocol specification
  11. Heng Lu on running-code primacy
  12. Heng Lu on minimum shared rules and local choice