specs/extensions: add attestseal-trust-attestation#136
Open
bonedoc911 wants to merge 1 commit intocoinbase:mainfrom
Open
specs/extensions: add attestseal-trust-attestation#136bonedoc911 wants to merge 1 commit intocoinbase:mainfrom
bonedoc911 wants to merge 1 commit intocoinbase:mainfrom
Conversation
🟡 Heimdall Review Status
|
0565b44 to
fe00429
Compare
fe00429 to
c486cf9
Compare
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
c486cf9 to
a53a044
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds
specs/extensions/attestseal-trust-attestation.mddefining how a resource server can attach a cryptographically signed third-party trust attestation (Ed25519, signed by an independent attestation authority's DID) to a402 Payment Requiredresponse.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
extrafield of aPaymentRequirementsentry under the keyattestseal-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 unsignedattestseal-payment-requirements-hashcompanion field that the resource server SHOULD include alongside the attestation. Clients recompute the hash from the receivedPaymentRequirementsand 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)
attestseal-x402(PyPI publish staged)deploy/cloudflare-worker-x402/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:
PaymentRequirements,extraplacement,PAYMENT-REQUIREDheader).attestseal-payment-requirements-hashcompanion-field pattern is consistent with how other extensions handle per-challenge binding.boundOriginshould be required or stay nullable.Checklist
extension-offer-and-receipt.md,http-message-signatures.md).AttestSeal/attestseal).Will move to ready-for-review after the human author's pass.