Skip to content

specs/extensions: add attestseal-trust-attestation#136

Open
bonedoc911 wants to merge 1 commit intocoinbase:mainfrom
bonedoc911:add-attestseal-trust-attestation-extension
Open

specs/extensions: add attestseal-trust-attestation#136
bonedoc911 wants to merge 1 commit intocoinbase:mainfrom
bonedoc911:add-attestseal-trust-attestation-extension

Conversation

@bonedoc911
Copy link
Copy Markdown

@bonedoc911 bonedoc911 commented May 2, 2026

Summary

Adds specs/extensions/attestseal-trust-attestation.md defining how a resource server can attach a cryptographically signed third-party trust attestation (Ed25519, signed by an independent attestation authority's DID) to a 402 Payment Required response.

The extension lets a paying agent decide whether to pay before selecting a payment scheme. Verification is local once the issuer DID document is cached (24h); zero additional round-trip on the happy path.

Why an extension and not a scheme

Schemes describe how funds move. This extension describes evidence the resource server attaches to the payment challenge so the client can decide whether to use any scheme at all. Scheme- and network-agnostic.

Wire shape

Primary: embedded inside the extra field of a PaymentRequirements entry under the key attestseal-trust-attestation. This is the x402-idiomatic transport and is RECOMMENDED for both servers and clients.

Secondary, compatibility: sibling X-AttestSeal-* HTTP response headers, for CDN-edge stamping and stateless reverse-proxy use cases. The doc is explicit that servers MAY emit either or both, and clients SHOULD prefer the embedded extension when present.

Per-challenge binding

The signed attestation commits to domain, boundOrigin, and a TTL window. To prevent replay across distinct payment challenges within the same domain, the doc specifies an unsigned attestseal-payment-requirements-hash companion field that the resource server SHOULD include alongside the attestation. Clients recompute the hash from the received PaymentRequirements and reject on mismatch. The issuer does not sign the hash because the issuer has no view of merchant-specific payment requirements; the binding is server-asserted and client-verified.

Reference issuer

did:web:attestseal.com (AttestSeal). The protocol is open to any DID-method-web entity; the doc is explicit that no single trust authority is privileged.

Reference implementations (separate repo)

AI-assisted disclosure

This doc was drafted with AI assistance (Claude). Submitting as draft while the human author (Allen Lu, AttestSeal, Inc.) reviews. Reviewer focus areas:

  • Correctness of x402 references (PaymentRequirements, extra placement, PAYMENT-REQUIRED header).
  • Whether the attestseal-payment-requirements-hash companion-field pattern is consistent with how other extensions handle per-challenge binding.
  • Whether boundOrigin should be required or stay nullable.
  • Anything in the security-considerations section that warrants tightening.

Checklist

  • Doc follows existing extension style (cf. extension-offer-and-receipt.md, http-message-signatures.md).
  • No code changes, docs only.
  • No new dependencies introduced into the x402 repo.
  • Reference impl + SDK live in a separate repo (AttestSeal/attestseal).

Will move to ready-for-review after the human author's pass.

@cb-heimdall
Copy link
Copy Markdown

cb-heimdall commented May 2, 2026

🟡 Heimdall Review Status

Requirement Status More Info
Reviews 🟡 0/1
Denominator calculation
Show calculation
1 if user is bot 0
1 if user is external 0
2 if repo is sensitive 0
From .codeflow.yml 1
Additional review requirements
Show calculation
Max 0
0
From CODEOWNERS 0
Global minimum 0
Max 1
1
1 if commit is unverified 1
Sum 2

@github-actions github-actions Bot added the specs label May 2, 2026
@bonedoc911 bonedoc911 force-pushed the add-attestseal-trust-attestation-extension branch from 0565b44 to fe00429 Compare May 2, 2026 13:27
@bonedoc911 bonedoc911 marked this pull request as ready for review May 2, 2026 13:56
@bonedoc911 bonedoc911 force-pushed the add-attestseal-trust-attestation-extension branch from fe00429 to c486cf9 Compare May 2, 2026 14:03
Adds a new extension document defining how a resource server can attach
a cryptographically signed third-party trust attestation (Ed25519, signed
by an independent attestation authority's DID) to a 402 Payment Required
response.

The extension is wire-shape-agnostic: implementers can embed the
attestation as a JSON object in the existing `extra` field of
PaymentRequirements (the recommended x402-idiomatic shape), or carry it
as sibling X-AttestSeal-* HTTP response headers. Clients MUST handle
either shape.

The reference issuer is AttestSeal (`did:web:attestseal.com`), but the
protocol is open to any DID-method-web entity. Agents authenticate
per-issuer via an allow-list. No single trust authority is privileged.

Why this is an extension rather than a scheme: schemes describe how
funds move; this extension describes evidence the resource server
attaches to the payment challenge so the client can decide whether to
use any scheme at all.

The doc follows the existing extensions style (cf.
extension-offer-and-receipt.md, http-message-signatures.md): summary,
purpose, status, structured payload definition with field-by-field
explanation, two wire-transport options, verification flow, server
flow, security considerations (cross-domain replay, key rotation,
info-leakage, TOFU on issuer DID), reference implementations, and
compatibility matrix.

Reference implementations available at github.com/AttestSeal/attestseal:
- Python middleware + verifier (`attestseal-x402` on PyPI)
- Cloudflare Worker template
- Live demo at demo.attestseal.com
@bonedoc911 bonedoc911 force-pushed the add-attestseal-trust-attestation-extension branch from c486cf9 to a53a044 Compare May 2, 2026 14:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Development

Successfully merging this pull request may close these issues.

2 participants