[WIP] proposal: Payment Session Extensions for JSON-RPC 2.0 over WebSocket#212
[WIP] proposal: Payment Session Extensions for JSON-RPC 2.0 over WebSocket#212brendanjryan wants to merge 1 commit intomainfrom
Conversation
Defines how the session payment intent operates over WebSocket connections using JSON-RPC 2.0 frames. Extends draft-payment-transport-mcp-00 with session lifecycle messages (voucher, needVoucher, topUp, close). Key design decisions: - One session per connection, channelId-scoped - payment.voucher as request with seq for correlation - Control messages never metered, always processed while paused - Challenge expires gates only open action - Pre-upgrade 402 for connection-level payment - Reconnect via highest-known voucher exchange - Bidirectional metering deferred to future work
brendanjryan
changed the title
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: d49753ebb7
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| TopUp requires a valid challenge. If the original challenge has | ||
| expired, the client MUST obtain a fresh challenge by sending a | ||
| request that triggers a `-32042` error, then use that challenge | ||
| for the top-up credential. |
There was a problem hiding this comment.
payment.topUp
Section 4.5 makes payment.topUp depend on a valid challenge and even says clients must fetch a fresh challenge when expired, but the payment.topUp request shape in this spec only defines params fields and never defines where the required org.paymentauth/credential is sent. In WebSocket implementations this leaves a normative MUST that cannot be satisfied consistently, so different servers will either reject all top-ups or accept them without the intended challenge validation.
Useful? React with 👍 / 👎.
| remainder of the session. Voucher updates reference the original | ||
| `challengeId` for audit correlation but do not depend on |
There was a problem hiding this comment.
challengeId requirement for vouchers
This text says voucher updates reference the original challengeId, but the payment.voucher schema later only includes channelId, cumulativeAmount, signature, and seq (no challengeId). That makes the stated correlation requirement unimplementable as written, and servers cannot rely on deterministic challenge-to-voucher attribution from voucher messages alone.
Useful? React with 👍 / 👎.
| | `payment.close` | C→S | Request | No | Yes | | ||
| | `payment.needVoucher` | S→C | Notification | No | N/A (triggers pause) | | ||
| | `payment.receipt` | S→C | Notification | No | Yes | | ||
| | `payment.error` | S→C | Notification | No | Yes | |
There was a problem hiding this comment.
payment.error before listing it as supported
The message summary declares payment.error as a supported server notification, but the document never defines its payload, triggering conditions, or client handling rules. Leaving a listed control message undefined creates interoperability gaps because clients and servers cannot implement compatible behavior for this method.
Useful? React with 👍 / 👎.
1 participant
Summary
[WIP]
Defines how the
sessionpayment intent operates over WebSocket connections using JSON-RPC 2.0 frames. Extendsdraft-payment-transport-mcp-00with session lifecycle messages.