Conversation
brendanjryan
changed the title
Spec Preview
Download spec artifacts (HTML, TXT, XML, PDF) |
- Fix IPR to noModificationTrust200902 - Remove citations from abstracts (RFC 7322) - Remove TK placeholders - Tighten amount field format (base-10 integer string) - Add authorizationExpires > expires ordering constraint - Add error responses section (402 for expired/exhausted/revoked) - Add Idempotency-Key normative reference - Replace undefined Payment-Authorization header mention - Use definition list markup instead of markdown bold - Normalize org: vs organization: in author blocks - Make recipient conditionality explicit per fulfillment type - Add ABNF appendix to method spec - Add IANA per-method intent registration table - Make chainId default normative - Add did:pkh guidance matching charge spec - Add caching guidance to security considerations - Add EIP-20 informative reference - Add informational caveat to recommended max windows
![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: 235f8c82c7
ℹ️ 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".
| | Authorization expired | 402 Payment Required | Issue new challenge | | ||
| | Spending limit exhausted | 402 Payment Required | Issue new challenge | | ||
| | Authorization revoked | 402 Payment Required | Issue new challenge | | ||
| | Invalid credential | 401 Unauthorized | Reject credential | |
There was a problem hiding this comment.
The authorize intent error table assigns 401 Unauthorized to invalid credentials, but the base Payment auth scheme defines payment-credential validation failures as 402 with a fresh WWW-Authenticate: Payment challenge (and reserves 401 for non-payment auth failures). Implementations following this row will produce non-interoperable behavior where clients cannot properly retry payment challenges.
Useful? React with 👍 / 👎.
1 participant
Context
Adds the authorize intent — a transaction pattern where the payer grants the server permission to charge up to a specified amount within a time window, without immediate payment. This enabled delayed fulfillment, with spending caps.
Changes
Two new specs following the existing charge intent / Tempo charge method split:
draft-payment-intent-authorize-00— Abstract intent semantics: request schema, credential requirements, authorization lifecycle, and error lifecycledraft-tempo-authorize-00— Tempo-specific implementationKey design decisions
approveon-chain) vs key authorization (delegated signing key). ThefeePayerfield determines which path is available — whentrue, key authorization is used; whenfalse, the client must sign a full transaction.authorizationExpiresvsexpires: Challenge expiry and authorization expiry are distinct, in order to allow short lived challenges but long-lived authorizations.authorizationExpiresMUST be strictly later than the challengeexpires.Open questions
Funds availability: With authorization keys on tempo, this method just gives users the "right" to capture funds, but does not guarantee funds can be captured (requires simulation). This makes this not a true auth+capture flow. To address this we could use a similar (same?) contract to what we use for sessions
Long-lived / incremental authorizations: Should we allow authorizations to be long lived and captured multiple times or only once? Should we allow the amount on the key to be increased?
Dual transaction type : Do we strictly need to offer both key authorization and transaction fulfillment flows? Is this unnecessary complexity for now?
feePayeroverloading: CurrentlyfeePayer: trueimplicitly requires key authorization andfeePayer: falserequires transaction fulfillment. Should we decouple fee sponsorship from credential type (e.g., add an explicitfulfillmentTypefield)?Error signaling for limit exhaustion: The spec returns
402with a fresh challenge when the authorization is exhausted. Should we add a structured error body or header (e.g.,Payment-Error) so clients can distinguish "limit exhausted" from "authorization expired" from "authorization revoked" without guessing?