Re: The growing number of "x402" documents

Hi.
Thanks for your response.  I find it immensely useful and hope others
do too.  It is just the sort of clarification I was hoping for.  If
your efforts and Christopher's are independent of each other, I hope
for a similar clarification from him.

A few additional thoughts, after which this should probably be taken
off-list.  I would have replied privately to your note except that I
think others should have visibility into what I'm about to say.
Although based on some years of experience, these are just personal
opinions; others might disagree on the best way to proceed.

(1) If you intend these documents to be handled as Independent
Submissions, you would probably save some pain and confusion by
including a "Status of this Document" section (normally just below
the Abstract) that says that.  It could be as brief as a sentence
saying that the document is intended as an Independent Submission or
could be longer and contain much of your explanation below --
entirely up to you.

(2) I can't speak for the Independent Submissions Editor (copied) but
I don't believe that process has ever been used to publish a
half-dozen (or, with the draft-hopley-* documents, closer to a dozen)
separate documents describing components of, or supplements to, one
core protocol or set of protocols.  You should discuss it with him
when you both consider it appropriate, but finding out early what he
would consider would likely save both of you time.  Discussions about
language artifacts should also occur with the ISE, not on this list.
(Disclaimer: I'm a member of the Independent Submissions Editorial
Board.  That doesn't give anything I say here any authority, but
probably predicts what I would have to say when (or if) I'm asked in
that context.)

(3) If you want to leave the door open to a DISPATCH discussion if
there is active community interest, say so (and probably include that
in the Status note as suggested above).  If rather than trying to
propose a DISPATCH presentation at this point, you want to see if
others are sufficiently interested, say that explicitly and,
presumably, pursue the Independent Submission process unless that
interest turns up.  

(4) Do note that, if you (perhaps prompted by others) try to pursue
IETF standardization, via DISPATCH or otherwise), that the IETF has
always (or at least almost always) made change control by the IETF a
condition for standardization.  In this case, that would have at
least two implications: Details of the specifications would be the
IETF's to determine, not those of Vauban Research, although you'd
certainly be expected to participate in forming that consensus.  And,
especially if your "layers the V2 wire protocol does not yet specify"
comment implies that x402 might eventually try to standardize similar
work, some sort of formal liaison, possibly a formal agreement,
between the two SDOs would almost certainly be a necessity.

Again, just my opinion... and a hope that Christopher's position
aligns with yours.

thanks,
   john



--On Monday, May 25, 2026 15:10 +0000 "[email protected]"
<[email protected]> wrote:

> 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
> (`0x044dd87a94a801cf775d4c5e4b6703102d4e97e1cd1d0a8879341219ae4f19f
> f`) 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]
>