Re: The growing number of "x402" documents

Hi Chris,

Please review https://www.rfc-editor.org/about/independent to have your 
drafts considered.  I've not looked at any of these drafts.

Eliot (ISE)

On 25.05.2026 20:32, Chris wrote:
> Dear John (and ISE) —
>
> Thank you for the careful process guidance — it's exactly the 
> clarification scaffolding we needed before responding more fully.
>
> Brief alignment on the four points you raised, and one framing note on 
> the wider landscape.
>
> (1) "Status of this Document" section. Yes — we will add the Status 
> section to the next revision of each draft-hopley-x402-* 
> Internet-Draft in our next filing cycle, making the Independent 
> Submission intent explicit in each document.
>
> (2) Volume on the Independent Submission stream. The six 
> draft-hopley-x402-* documents describe components of a single 
> canonicalisation discipline (one document registering the URN in 
> §10.1) plus five base receipt-format extensions of it (compliance, 
> settlement, cancellation, refund, composite-trust-query). The 
> granularity is intentional separation of concerns at the substrate 
> layer rather than supplements to a single core protocol — each receipt 
> format is independently citable and re-verifiable. We will engage the 
> ISE proactively before our next filing cycle to confirm the structure 
> is appropriate for the stream.
>
> (3) DISPATCH. We don't currently see active community interest in 
> pursuing IETF standardisation of the canonicalisation discipline. The 
> door is not closed; if community interest emerges, we are open to a 
> DISPATCH discussion at the right time. Our current preference is 
> Independent Submission for change-control preservation.
>
> (4) Standards Track and change control. Confirming current intent: no 
> pursuit of IETF Standards Track. Change control via Independent 
> Submission preserves AlgoVoi's authorship of the canonicalisation 
> discipline registered in §10.1 of 
> draft-hopley-x402-canonicalisation-jcs-v1.
>
> On the wider landscape. AlgoVoi is the original author of the 
> canonicalisation discipline identified by 
> urn:x402:canonicalisation:jcs-rfc8785-v1 and the five base 
> receipt-format extensions that anchor to it. We are actively 
> monitoring the growing number of x402-related Internet-Drafts and 
> downstream specifications, and pursuing reconciliation with 
> third-party documents that depend on the discipline — both within the 
> IETF stream and on the x402-foundation/x402 coordination layer — so 
> that the citation landscape stabilises around the registered URN 
> rather than fragmenting.
>
> Going forward, AlgoVoi is also open to collaborative design with 
> third-party implementers on substrate extensions, downstream 
> receipt-format variants, and application-layer composition patterns 
> above the canonicalisation discipline — while maintaining sole 
> authorship of the canonicalisation discipline itself. The substrate is 
> the citation anchor; the extensions on top are open to multi-author 
> design and coordination through whatever venue most serves the wider 
> x402 community.
>
> Happy to engage the ISE proactively on whichever subset of this work 
> merits the most coordination, per your suggestion.
>
> Happy to take any further coordination off-list per your guidance.
>
> Best regards,
> Christopher Hopley
> AlgoVoi
>
>
> On Mon, 25 May 2026 at 18:52, John C Klensin <[email protected]> wrote:
>
>     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
>     <http://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]
>     >
>
>