Dear authors, dear list,
I am writing in reference to draft-liu-oauth-a2a-profile-00, "Agent-to-Agent
(A2A) Profile for OAuth Transaction Tokens." The authorization-intent
propagation mechanism described in that draft maps closely to a design we have
developed at the payment-class layer, and I want to offer a reference
that may be useful if the draft is revised or if the OAuth working group takes
up A2A authorization more broadly.
The core semantic of draft-liu-oauth-a2a-profile is preserving the principal's
authorization context as it propagates through multi-hop agent
chains. This is well-addressed by OAuth Transaction Tokens for the general
authorization case. For payment-class interactions specifically, an
additional requirement arises: the compliance record of what a sub-agent
actually spent must be cryptographically bound to the scope that was
delegated, and that binding must be verifiable without calling back to any
authorization server at verification time. Enterprises in regulated
property for offline audit, for cross-jurisdiction settlement, and for post-hoc
forensics when a chain has already completed.
draft-vauban-x402-stark-receipts-00
(https://datatracker.ietf.org/doc/draft-vauban-x402-stark-receipts/) addresses
this as follows. The Vauban
DelegationGrant is a PaymentClaim expressed in the x402 V2 wire format (Linux
Foundation). It is issued by the principal to the sub-agent and carrie
delegated, and that binding must be verifiable without calling back to any
authorization server at verification time. Enterprises in regulated
environments need this property for offline audit, for cross-jurisdiction
settlement, and for post-hoc forensics when a chain has already completed.
draft-vauban-x402-stark-receipts-00
(https://datatracker.ietf.org/doc/draft-vauban-x402-stark-receipts/) addresses
this as follows. The Vauban
DelegationGrant is a PaymentClaim expressed in the x402 V2 wire format (Linux
Foundation). It is issued by the principal to the sub-agent and
carries an Stwo Circle STARK proof that the delegation scope, the payment
conditions, and the payer attestation are mutually consistent; the proof
is post-quantum sound and verifiable in under 3 ms without any network call.
The SD-JWT-VC ClaimExporter serializes the delegation as a Selective
Disclosure JWT-VC (RFC 9901 / draft-ietf-oauth-selective-disclosure-jwt), which
aligns with OAuth credential infrastructure. The STARK receipt can
therefore be treated as a payment-class evidence claim accompanying the OAuth
Transaction Token: the token carries the authorization chain, and the
receipt carries the cryptographic proof that the payment action stayed within
the authorized scope.
We believe there is a natural layering between draft-liu-oauth-a2a-profile and
draft-vauban-x402-stark-receipts-00. If the authors or the working
group are interested in exploring a joint reference or a normative mention of
payment-class evidence alongside OAuth Transaction Tokens for A2A
payment actions, we would welcome that discussion. We are also prepared to
contribute a use-case section documenting the DelegationGrant binding if
a revision of draft-liu-oauth-a2a-profile is planned.
Best regards,
Fabien Serafini
Vauban Research
[email protected]
https://datatracker.ietf.org/doc/draft-vauban-x402-stark-receipts/
Sent with [Proton Mail](https://proton.me/mail/home) secure email.
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
