[intent] authorize intent (auth and capture)#226
Conversation
brendanjryan
changed the title
Spec Preview
|
- 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 👍 / 👎.
Simulation is not a complete guarantee of funds availability. Escrow contract is needed to enable the 'without immediate payment' feature, else it must be capture-first-deliver-after, but that forces per-charge onchain settlement. It also negates the delayed fulfillment use case (server should not start provisioning unless payment is guaranteed).
|
Correct -- this is one tradeoff with this design and something we do not like either. We are going to do another rev of this which uses an escrow, which also allows for partial + multi-capture flows -- an ask we have seen from users in the last few weeks. We expect to have a new update to this in ~2 weeks! |
brendanjryan
changed the title
brendanjryan
changed the title
| ins: J. Moxey | ||
| email: jake@tempo.xyz | ||
| org: Tempo Labs | ||
| - name: Brendan Ryan |
| ~~~ | ||
|
|
||
| The core intent deliberately does not expose payment method capture | ||
| capabilities, such as whether the method performs one capture or multiple |
There was a problem hiding this comment.
important note!
|
|
||
| ## Refund Requests | ||
|
|
||
| Refunds are out of scope for the core authorize lifecycle. Clients MAY |
| ins: J. Moxey | ||
| email: jake@tempo.xyz | ||
| org: Tempo Labs | ||
| - name: Brendan Ryan |
| consensus: true | ||
|
|
||
| author: | ||
| - name: Brendan Ryan |
brendanjryan
changed the title
2 participants
Summary
Adds the
authorizeintent as a full authorization-and-capture lifecycle for HTTP Payment Authentication, with method-specific capture, void, and refund-request semantics.Key design decisions
Notes on implementations
Tempo Implementation
Leverages the same underlying "escrow" contract as the tempo session method, with the server as an authorized signer
Stripe Implementation
Leverages shared payment token, with restrictions on what parameters and shapes of payment methods can be used.
Open questions