coinbase
[Feature Proposal] Optimistic Client Identification
Optimistic Client Identification
Problem Statement
The current x402 spec currently does not provide any native mechanism to signal to a server who they are.
There are a few areas that providing identification would be useful.
Server-side failures and retries
If a client has already paid for something, the client should receive a response. However, software is not perfect and sometimes errors arise. If the facilitator processes the payment but something breaks between that point and the user receiving a full response, having the client able to retry with something that identifies them to the server would let the server see the client has already paid and not charge them a second time.
Long term / permanent purchases
If a server wants to sell long term access to a resource, it would be useful to have an opinionated way of letting clients identify themselves on future requests to avoid unnecessary payment requests. There's an example in the x402 repo that provides back a session ID, but these are ephemeral and need to be stored somewhere both client-side / server-side to work, which adds friction.
Tiered access to resources
In the x402 FAQ, pricing schemes that have /basic or /pro differentiated pricing are provided. If there was a native client identification mechanism, you could offer this in one endpoint. (no identification = higher price, identification = lower price, etc)
Implementation requirements
- An identification functionality built into x402 should be optional in the sense that not all servers may care about client-side identification.
- An identification functionality should be flexible and allow for multiple ways of identification, such as:
- Sign in with a crypto wallet (providing something signed by a wallet's private key, which identifies it)
- Standard Bearer Token
- It would be up to the server to decide what kind of identification to accept (None, or many)
Open questions
Optimistic Identification Hints
For servers accepting optimistic identification, there's the question of: "How does the client know how to identify itself?". This could take a few different forms, community discussion here would be appreciated.
One idea is that servers wishing to accept identification could provide information to the client when returning a 402 response on what types of identification the server accepts (either via headers or via the json response). A client could choose to ignore this hint, or it could choose to provide authentication if it was capable.
Servers could also potentially return this in a response when delivering a successful response. This may be more useful for session-based or content-specific identification, such as the server creating a unique access token for a specific piece of content.
Identification Opinions
While keeping x402 flexible is important, it may be useful to designate officially "supported" methods of optimistic identification for the x402 spec so that if a server signifies that it supports a specific auth method, then a client knows "this is how I identify with this server".
Agree with this, markings as consider for next version as it'd be a breaking change
Curious how this has progressed. Happy to chat about how we're thinking about AstraSync and Know Your Agent in the context of x402 (and others)
I think the simplest way to identify is to sign an EIP-3009 payment with zero value.
