Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
128 changes: 128 additions & 0 deletions specs/extensions/http-message-signatures.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,128 @@
# Extension: `http-message-signatures`

## Summary

The `http-message-signatures` extension establishes the **identity** of the paying agent through cryptographic signatures (RFC 9421). This extension is used by network implementations that authenticate payment commitments using HTTP Message Signatures.

## Purpose

Establishes the cryptographic identity of the paying agent and provides information on how to associate that identity with the network for billing.

## Extension Definition

```json
{
"http-message-signatures": {
"schema": {
"$schema": "https://json-schema.org/draft/2020-12/schema",
"type": "object",
"properties": {
"registrationUrl": {
"type": "string",
"format": "uri",
"description": "URL to the network's setup endpoint and documentation"
},
"signatureSchemes": {
"type": "array",
"items": {
"type": "string"
},
"description": "Supported cryptographic signature algorithms"
},
"tags": {
"type": "array",
"items": {
"type": "string"
},
"description": "Supported signature tags for validation"
}
},
"required": ["registrationUrl", "signatureSchemes"]
},
"info": {
"registrationUrl": "https://network.example.com/signature-agents",
"signatureSchemes": ["ed25519", "ecdsa-p256-sha256", "rsa-pss-sha512"],
"tags": ["web-bot-auth", "agent-browser-auth"]
}
}
}
```

## Fields

- **`registrationUrl`** (required): URL to the network's documentation and setup endpoint where signature agents can associate their identity with a billing identity
- **`signatureSchemes`** (required): Array of supported cryptographic algorithms (e.g., `["ed25519", "ecdsa-p256-sha256", "rsa-pss-sha512"]`)
- **`tags`** (required): Array of supported signature tags that identify the purpose (e.g., `["web-bot-auth"]`)

**Schema Omission**: The `schema` field is optional and may be omitted from responses to reduce header size. When omitted, clients should reference this specification for field definitions.

## Usage

Networks that use HTTP Message Signatures for authentication include this extension in the `PaymentRequired` response to inform clients:

1. Where to register their signature agent with the network (`registrationUrl`)
2. Which cryptographic algorithms are supported (`signatureSchemes`)
3. Which signature tags are accepted for validation (`tags`)

The client must:

1. Host their public keys at `/.well-known/http-message-signatures-directory` (per draft-meunier-http-message-signatures-directory)
2. Register their signature agent URL with the network via the `registrationUrl`
3. Sign HTTP requests using HTTP Message Signatures (RFC 9421) with the appropriate tag

## Server-Signed Responses

Servers can sign responses per RFC 9421 Section 3.1 to provide integrity for payment data. This enables clients to verify that `PAYMENT-REQUIRED` and `PAYMENT-RESPONSE` headers have not been modified, and to pin a specific version of terms to a transaction.

### Covered Components

Per RFC 9421 Section 2.2.9, responses can include `@status` in the signature. Per Section 2.4, servers can bind response signatures to request components using the `req` flag. For x402, servers signing responses should include:

- `@status`: HTTP status code
- `payment-required` or `payment-response`: The x402 header
- Request binding: `"@authority";req`, `"@path";req`

### Example

```http
HTTP/2 200 OK
Content-Type: text/html
PAYMENT-RESPONSE: eyJhbW91bnQiOiI1IiwiYXNzZXQiOiJVU0QiLCJleHRlbnNpb25zIjp7InRlcm1zIjp7ImluZm8iOnsiZm9ybWF0IjoidXJpIiwidGVybXMiOiJodHRwczovL2V4YW1wbGUuY29tL3Rlcm1zLXYyLjAubWQifX19fQ==
Signature-Input: resp=("@status" "payment-response" "@authority";req "@path";req);created=1700000000;keyid="server-key";tag="x402-response"
Signature: resp=:abc123...==:
```

Servers publishing response signatures should host their public keys at `/.well-known/http-message-signatures-directory`.

## Example Networks

- **Cloudflare** (`cloudflare:402`): Uses this extension with `ed25519` signatures and `web-bot-auth` tag

## Example

```json
{
"extensions": {
"http-message-signatures": {
"schema": {
"$schema": "https://json-schema.org/draft/2020-12/schema",
"type": "object",
"properties": {
"registrationUrl": { "type": "string", "format": "uri" },
"signatureSchemes": {
"type": "array",
"items": { "type": "string" }
},
"tags": { "type": "array", "items": { "type": "string" } }
},
"required": ["registrationUrl", "signatureSchemes"]
},
"info": {
"registrationUrl": "https://developers.cloudflare.com/ai-crawl-control/features/pay-per-crawl/use-pay-per-crawl-as-ai-owner/verify-ai-crawler/",
"signatureSchemes": ["ed25519"],
"tags": ["web-bot-auth"]
}
}
}
}
```
90 changes: 90 additions & 0 deletions specs/extensions/terms.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,90 @@
# Extension: `terms`

## Summary

The `terms` extension can be used by any network or scheme to communicate the terms of the payment commitment.

## Purpose

Describes the usage rights, obligations, and settlement terms of a payment commitment.

## Extension Definition

```json
{
"terms": {
"schema": {
"$schema": "https://json-schema.org/draft/2020-12/schema",
"type": "object",
"properties": {
"format": {
"type": "string",
"enum": ["uri", "markdown", "plaintext", "json"],
"description": "Format identifier describing how to interpret the terms field"
},
"terms": {
"type": "string",
"description": "Terms as a string (URL, markdown, plaintext, or JSON)"
},
"version": {
"type": "string",
"description": "Version identifier for change detection"
}
},
"required": ["format", "terms"]
},
"info": {
"format": "uri",
"terms": "https://example.com/terms.md",
"version": "2026-01-15"
}
}
}
```

## Fields

- **`format`** (required): Format identifier describing how to interpret the `terms` field
- `"uri"`: Terms field contains a URL or data URI to the terms document
- `"markdown"`: Terms field contains Markdown formatted text
- `"plaintext"`: Terms field contains plain text
- `"json"`: Terms field contains JSON-stringified structured data

- **`terms`** (required): Terms as a string
- If `format` is `"uri"`: An HTTPS URL or data URI pointing to the terms document
- If `format` is `"markdown"` or `"plaintext"`: The actual terms text
- If `format` is `"json"`: JSON string containing structured terms data

- **`version`** (optional): Identifier for change detection. Allows clients to detect when terms have changed without fetching the full document. Can be a date, semantic version, hash, or any string that changes when terms are updated.

**Schema Omission**: The `schema` field is optional and may be omitted from responses to reduce header size. When omitted, clients should reference this specification for field definitions.

## Examples

```json
// URI format with version for change detection
{ "format": "uri", "terms": "https://example.com/terms.md", "version": "2026-01-15" }

// Markdown format
{ "format": "markdown", "terms": "# Terms of Use\n\nThis content is provided under the following terms..." }

// Plaintext format
{ "format": "plaintext", "terms": "Licensed for non-commercial use only. Attribution required." }
```

## Usage

This extension can be used across different payment schemes and networks to communicate:

- **Content licensing**: Rights for LLM training, inference, or redistribution
- **Subscription agreements**: Terms of service for ongoing access
- **Usage restrictions**: Limitations on how the resource can be used
- **Legal obligations**: Compliance requirements or liability terms

When used with authentication extensions (like `http-message-signatures`), it creates a complete framework where the network knows both who is paying and what terms govern the usage of the accessed resource.

## Example Use Cases

- **Deferred scheme**: Communicating usage rights for content accessed through deferred payment
- **Exact scheme**: Specifying terms for blockchain-settled payments
- **Any scheme**: Describing legal terms for resource access
61 changes: 61 additions & 0 deletions specs/schemes/deferred/scheme_deferred.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,61 @@
# Scheme: `deferred`

## Summary

`deferred` is a payment scheme designed for agentic payments that do not require immediate settlement. Its primary purpose is to enable instant access to resources through cryptographically secure payment commitments that are authenticated by the network. These payments are settled later through trusted network infrastructure.

`deferred` payments eliminate transaction delays and gas fees while maintaining strong security through network-verified authentication and account association with network providers, making them ideal for high-frequency, low-value transactions.

**Authentication**: The specific authentication mechanism (e.g., HTTP Message Signatures, bearer tokens, API keys) is determined by the network implementation, not the scheme itself.

## Example Use Cases

### High-Volume, Asynchronous Micro-payments (Consolidated Settlement)

This scheme facilitates systems requiring continuous access for AI agents or automated crawlers. The individual, low-cost requests are granted instantly via cryptographic payment commitment. The server may later aggregate commitments and execute the financial settlement (which can use fiat, stablecoins, or traditional rails) is batched and consolidated to occur periodically (daily or weekly), eliminating per-request overhead and transaction fees.

### Subscription and Licensing Agreements (Pre-negotiated Access)

Agents can access resources immediately under pre-negotiated licensing or subscription terms. The scheme provides programmatic access verification through network-authenticated identities, while the financial settlement and any usage-specific legal terms (like LLM inference/training access) are managed separately through the trusted network's infrastructure.

### Zero-Friction, Pay-Per-Use Access for Verified Identities

By binding the cryptographic payment commitment to a verified identity, the scheme enables instant delivery of premium content or API services. Similar to the exact scheme, this scheme supports simple access models like pay-per-article or per-API-call without forcing the user into a traditional API Key, subscription, or manual billing cycle.

## Appendix

### Network Requirements

The `deferred` scheme is network-dependent and requires:

1. **Authentication Mechanism**: Networks must specify how clients authenticate payment commitments (e.g., HTTP Message Signatures, bearer tokens, API keys)
2. **Identity Association**: Networks must maintain associations between authenticated identities and billing accounts
3. **Settlement Infrastructure**: Networks act as Merchant of Record, handling deferred settlement and billing

### Common Extensions

Network implementations may use extensions to communicate authentication requirements and usage terms:

#### HTTP Message Signatures Extension

The [`http-message-signatures`](../../extensions/http-message-signatures.md) extension can be used by networks that authenticate using HTTP Message Signatures (RFC 9421).

See the [full extension specification](../../extensions/http-message-signatures.md) for details on:

- Extension definition and JSON schema
- Required fields (`registrationUrl`, `signatureSchemes`, `tags`)
- Usage instructions and examples

**Example networks**: Cloudflare (`cloudflare:402`)

#### Terms Extension

The [`terms`](../../extensions/terms.md) extension can be used by any network to communicate legal terms and usage rights.

See the [full extension specification](../../extensions/terms.md) for details on:

- Extension definition and JSON schema
- Format options (`uri`, `markdown`, `plaintext`, `json`)
- Usage examples

**Example usage**: Communicating LLM training/inference rights, content licensing terms, or subscription agreements
Loading