| Newsgroups |
gmane.ietf.general |
| Message-ID |
<U8rS-0zJ6o5zminuui_T0i4hEZdCVXu5iKtmrLOJe_W0QgjJO1WW42lPxeEdzeAkTqcJckHAfIZLdr54F51XxibNfp9rye8LHd32lJpOk3E=@vauban.tech> |
Dear John, and thank you to the list for surfacing this clearly,
We appreciate the directness, and the underlying concern is entirely legitimate: the IETF's credibility as an endorsement signal matters and should not be diluted. A factual account of our position follows.
Track and intent:
The six drafts from Vauban Research (draft-vauban-x402-*) are submitted on the Independent Submission Editor track with Informational intent, per RFC 4846. No claim of Working Group endorsement is made or implied in any document, commit, or external communication. If any artifact contains language inconsistent with ISE conventions, we would welcome specific citations so we can correct them promptly.
Who we are :
Vauban Research is a French legal entity with 18 months of documented development history across nine products (payments, finance, governance, ML security auditing, Starknet infrastructure).
Governance decisions are tracked through a council-quorum framework with public ADR records.
We are not a filing exercise in search of legitimacy; we are a multi-product engineering operation with pre-existing institutional relationships that preceded our IETF participation.
Relationship to x402 Foundation:
We are coalition participants, not a competing standards body. Our drafts address layers the V2 wire protocol does not yet specify: a cryptographic receipt format for on-chain ZK-proof settlement (STARK M31, Circle IOP), a payment lifecycle state machine, a delegation-binding extension, a post-quantum signature discipline (FIPS 204 ML-DSA-65), and a claim-algebraic composition grammar.
None of these redefine the PAYMENT-REQUIRED / PAYMENT-SIGNATURE / PAYMENT-RESPONSE exchange; they specify what a verifiable receipt looks like above that exchange.
The settlement asset, whether STRK20, USDC, or any other, is a configuration parameter; the receipt format is asset-neutral by design.
Artifacts available for review: We maintain a public conformance repository (github.com/vauban-org/x402-stark-receipts-conformance, Apache 2.0) with CI-validated interoperability vectors.
The ADOPTERS.md is currently empty, which we prefer over a list inflated with pre-arranged entries. A
live on-chain demo contract on Starknet Sepolia (`0x044dd87a94a801cf775d4c5e4b6703102d4e97e1cd1d0a8879341219ae4f19ff`) provides a chain-verifiable anchor beyond the JSON layer.
An IACR ePrint companion paper targeting FC27 is in preparation
On DISPATCH :
We do not oppose a DISPATCH discussion. If the community judges a Working Group the appropriate home for payment receipt and lifecycle standardisation, we would participate and are open to discussing a liaison arrangement with the x402 Foundation TSC should they consider it useful.
We would be glad to initiate contact via the appropriate DISPATCH process if that is the preferred path.
Regards,
Vauban Research / Vauban Pay (pay.vauban.tech)
[email protected]