attest: Portable, Offline-Verifiable Digital Purchase Receipts

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 7 February 2027.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶

Table of Contents

1. Introduction

A digital purchase today is ordinarily a revocable license living inside one company's platform, not a thing the buyer holds. When the platform shuts down, delists a title, or changes terms, the only record that a purchase ever happened typically lived in the seller's own database and disappears with it. Existing consumer-protection efforts — disclosure requirements that a digital "purchase" is actually a license, and remedies for non-conforming digital content — address access and disclosure, but a legal remedy without evidence that a purchase occurred is difficult to exercise once the seller's records are gone.¶

attest defines an evidence layer for exactly that gap: a signed receipt envelope the store issues once, at the point of purchase, that the buyer keeps like a paper receipt and that anyone — the buyer, a marketplace, a friend, a preservation project — can verify offline, forever, against the issuer's own published key material. attest deliberately does not keep content alive, strip DRM, host or index content, process payment, or define a resale/transfer protocol on its own account (transfer is addressed only by the non-normative pointer in Section 12); it is only the evidence layer that lets whatever rights a buyer has survive the seller's disappearance.¶

Every implementation's conformance to the material this document specifies is exercised by the cross-language conformance vector corpus at docs/spec/vectors/ in the attest source repository — specifically the vector groups covering the v0.1 baseline and the v0.2 hybrid profile (the living specification's own Section 15 and Section 6, respectively). docs/conformance.md in that same repository documents the public, adapter-based process by which any independent implementation, in any language, can run that corpus against its own code and self-certify conformance; that process, not this document, is the operative conformance procedure.¶

2. Conventions and Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

This document uses three actor names, taken unchanged from the living specification:¶

Issuer:

the entity that signs receipts, identified by a DNS domain it controls. A marketplace or merchant-of-record may act as issuer on behalf of a named publisher.¶

Buyer:

the holder of an exported receipt.¶

Verifier:

any software that executes the verification algorithm of Section 7 against a receipt envelope.¶

Two terminology defusals are stated here explicitly, because each collides with a term a reader may already associate with a different IETF architecture:¶

A "receipt" in this document is a signed purchase-evidence statement — the payload-plus-signatures envelope of Section 3 — held and presented by the buyer who purchased it. It is not a SCITT transparency-service receipt in the sense of [RFC9943], which is a proof that a signed statement was registered in an append-only log. This document defines no transparency-log registration mechanism at all; the living specification's optional, non-normative-here transparency layer is pointed to, but not specified, in Section 12.¶

"attest" is this project's name, chosen with no relationship intended to the IETF Remote Attestation Procedures (RATS) architecture [RFC9334]. This document makes no RATS claim of any kind: it defines no Attester, no RATS-sense Verifier, no Relying Party role mapping, no Evidence or Attestation Results semantics, and no claim about the integrity or trustworthiness of any execution environment. A reader arriving from a RATS background should treat the project name as a false cognate.¶

3. Receipt Envelope

A receipt is transmitted as a JSON object with exactly three top-level members: payload (the only signed content, see Section 3.1), signatures (an array; see Section 5 for its required shape under each signature profile), and an OPTIONAL delivery member.¶

delivery is unsigned: it is outside payload and is not covered by any signature. When present, it MAY carry delivery.salt (the base64url, unpadded, encoding of the 16 raw bytes used as the buyer-commitment salt, see Section 3.2) and delivery.issuer_manifest (a key-manifest object, see Section 6, usable directly as a trust-store entry). An envelope carrying delivery.salt is a private artifact: implementations MUST strip it before treating an envelope as generally shareable. Tampering with delivery can neither forge nor invalidate a receipt, because it is not itself signed; the salt it may carry only has meaning insofar as it reproduces the signed buyer.commitment, and any embedded manifest snapshot is independently signature-checked on its own terms.¶

P = UTF8("Attest-buyer-commitment-v1") || 0x00
    || UTF8(identifier_type) || 0x00 || UTF8(normalize(identifier))
commitment = scrypt(P, salt, N=32768, r=8, p=1, dkLen=32)

verifier sends nonce (>= 16 random bytes,
                      freshly generated per challenge)
buyer signs: UTF8("Attest-binding-challenge-v1") || 0x00
             || receipt_id || 0x00 || nonce

4. Canonicalization

The signature input for a receipt is exactly JCS(payload) — the output of the attest-JCS profile below — encoded as UTF-8 bytes. attest-JCS follows [RFC8785] (JSON Canonicalization Scheme) with one deliberate deviation by restriction: full JCS permits any I-JSON number, canonicalized via a rounding algorithm every implementation must reproduce identically to stay interoperable. attest-JCS removes that cross-language interoperability risk entirely by restricting numbers to integers only, with magnitude strictly less than 2⁵³. A conforming canonicalizer MUST accept a JSON number if and only if it is such an integer, and MUST reject any float, any NaN/Infinity/-Infinity construct, and any integer at or beyond that magnitude. This is a restriction of, never an incompatible extension to, [RFC8785]: every attest-JCS output is also a valid JCS output.¶

Additional parse-time requirements, applied before any signature or schema step: the input MUST be valid UTF-8; a JSON object containing a duplicate member name MUST be rejected outright, never silently deduplicated; object keys MUST be serialized in the order produced by sorting their UTF-16BE code-unit sequences; and lone UTF-16 surrogates, whether arriving as literal bytes or as \uXXXX escapes, MUST be rejected. An over-magnitude integer is rejected at this canonicalization stage, before schema validation ever runs: the corresponding verification result reports signature: "invalid" and schema: "not_checked" (Section 7), never a schema-validation failure.¶

Encodings: signatures, commitments, salts, and public keys MUST be base64url without padding ([RFC4648] Section 5); SHA-256 hashes MUST be lowercase hexadecimal; receipt_id and supersedes are ULIDs (Crockford base32, 26 characters). format: "uri" fields in the JSON Schema are annotation-only: a conforming validator is not required to assert URI well-formedness as a failure; integrity of a referenced document is guaranteed by its accompanying SHA-256 hash binding, never by URI syntax.¶

5. Signature Profiles

6. Trust Manifests, Rotation, and Continuity

An issuer's identity is its DNS domain. An issuer SHOULD publish its key manifest at https://<issuer.id>/.well-known/attest.json.¶

Rotation continuity is normative, not best-effort. A manifest at manifest_version N+1 is auto-trusted only if it was signed by a key that was active in the version-N manifest already trusted; version gaps are bridgeable only by validating every intermediate manifest. On a discontinuous rotation, or on conflicting manifests for the same issuer, a verifier MUST report trust: "unverified_rotation" and MUST NOT auto-accept the manifest. For a hybrid signer, this continuity check is enforced through the hybrid manifest signature (Section 5.2): a rotation manifest whose signer key is hybrid but whose manifest signature has been downgraded to Ed25519-only fails the AND-verified check and is therefore not validly signed for continuity purposes, even though the receipt's own hybrid signature may independently verify cleanly against the manifest in use.¶

Key compromise fails closed. A key marked compromised invalidates all signatures ever made with it, regardless of issued_at, because issued_at lives inside the signed payload and is controlled by whoever holds the key. A verifier MUST reject any receipt signature resolving to a compromised key unconditionally. The same fail-closed rule governs revocation records (Section 8): one signed by a key that is not status == "active" in its resolving manifest MUST be ignored, with a warning.¶

Artifact manifests are separate signed side-documents, same signing discipline as key manifests, carrying issuer, series, version, an optional (required on manifests produced after this profile's currency amendment) manifest_version, released_at, the current artifacts array (Section 3.1 shape), and a manifest_signature.¶

Acceptance is conditional on authentication, not on being merely issuer-signed. A verifier MUST treat an artifact manifest as authenticated only if: its resolving key manifest is itself self-consistent; the manifest's signing key resolves, in that key manifest, to a key-entry with status == "active"; released_at falls within that key's validity window; the artifact manifest's own issuer field equals the resolving key manifest's issuer field; and the signature verifies (for a hybrid signer, under the AND-rule of Section 5.2). An unauthenticated artifact manifest contributes nothing to currency and MUST be ignored, with a warning, never treated as the newest-seen state on the strength of being merely issuer-signed. Two distinct, differently-content manifests presented at the same (issuer, artifact_series, manifest_version) tuple are an equivocation and MUST be rejected, not silently accepted as if one superseded the other.¶

Currency is scoped per (issuer, artifact_series) pair: a verifier holding persistent trust state MUST NOT accept, for that pair, a manifest with a lower manifest_version than the newest already accepted; on regression it MUST report trust: "unverified_rotation", the identical value the key- manifest rotation rule above uses. A manifest lacking manifest_version entirely (a legacy manifest) has no currency ordering to violate and is never rejected on these grounds, only warned.¶

Offline verification and trust bootstrapping. Offline verification works from a local trust store of key manifests. A manifest obtained from the issuer's own domain over TLS is the root of trust: a verifier that resolved a manifest this way MUST report trust: "verified" (absent a discontinuous rotation). A manifest that arrived by any other path — for example, embedded in an export bundle, never independently fetched over TLS — is unauthenticated trust-on-first-use and MUST be reported as trust: "unauthenticated_tofu", never silently upgraded.¶

7. Verification Algorithm

A verifier executes verify(envelope, trust_store, revocation_view=None, disclosure=None), returning a layered VerificationResult. Steps are executed in order; a step that rejects the input short-circuits the remaining steps, and the result's revocation and binding components take their safe stub values ("unknown" and "not_checked") whenever not reached.¶

The living specification numbers these steps 0 through 7; that numbering is preserved below as explicit labels rather than by list auto-numbering, since step 0 is not step 1.¶

• Step 0 (preconditions): parse the input once per Section 4 (UTF-8, attest-JCS-conformant, no duplicate keys). Every later step operates on this single parsed object, never on the raw transmitted bytes.¶
• Step 1 (envelope well-formedness): attest_version is a version this verifier supports; the signature block shape matches the selected profile (Section 5).¶
• Step 2 (issuer binding): resolve the signing key only from the trust store's manifest for payload.issuer.id; both the kid's domain prefix and the resolved manifest's own issuer field MUST equal it.¶
• Step 3 (key checks): the key MUST be present in the resolved manifest and MUST NOT be "compromised"; issued_at MUST fall within its validity window. A "retired" key still verifies, with a warning.¶
• Step 4 (signature verification): per the selected profile (Section 5).¶
• Step 5 (schema validation): the parsed payload MUST satisfy the structural constraints of the core receipt schema ([ATTEST-SCHEMA], attest-receipt.schema.json revision-pinned at tag v0.4.0), EXCEPT its Stage 3 (v0.2 §17.8) holder-binding conditional on license.transferable and buyer.pubkey, which belongs to the Stage 3 extension (Section 12) and is OUTSIDE this profile's normative scope — a verifier conforming to this document's core/hybrid profile alone is not required to enforce it. This document's own payload field registry (Section 3.1) is a descriptive summary of that same structure, not a second, independent normative source: the schema, minus that one named conditional, is the precise structural authority this step checks against.¶
• Step 6 (revocation): only if revocation_view is supplied, and only if signature and schema both succeeded; see Section 8.¶
• Step 7 (binding): only if disclosure is supplied, and only if signature and schema both succeeded; see Section 3.2.¶

trust is resolved as early as possible and reported at its best-available value even when a later step rejects the receipt; a verifier MUST NOT silently reset it on later failure. ok is defined as: signature == "valid" and schema == "valid" and revocation != "revoked" and the result carries no errors. invalid_revocation_ignored, unknown, and any not_revoked_as_of:<T> value do not affect ok.¶

An unrecognized top-level payload field is allowed and signed, but MUST be reported as a warning, never an error. A conforming verifier MUST also warn on: a signing key resolved as "retired"; a "drm-bound" license; an end_of_life value outside the seed vocabulary; a revocation record that matched this receipt but failed authentication, or that was ignored because revocability == "none", or that authenticated but fell outside a refund_window. Offline verifiers with no revocation_view report revocation: "unknown" honestly rather than failing the whole receipt closed.¶

Structural ceilings. A verifier MUST bound the resource a hostile envelope or manifest can force it to spend before any cryptographic or schema work runs, and these ceilings bind every attest_version this document defines, including the hybrid envelopes and manifests of Section 5.2. The revocation-view record ceiling (Section 8) is a distinct bound and is NOT one of these structural ceilings: it applies only at Step 6, to the untrusted revocation_view input, never before cryptographic or schema work runs, and is evaluated independently of the table below.¶

8. Revocation

A revocation record is a minimal, issuer-signed side-document: receipt_id (the receipt it refers to), status (only the literal value "revoked" carries revocation meaning under the material this document specifies alone), revoked_at (the record's own signed time — window checks are evaluated against this, never the verifier's local clock), and signature (Ed25519, plus for a hybrid-keyed issuer an sig_ml_dsa_65 leg per the AND-rule of Section 5.2, over JCS(record) with this member removed).¶

Authentication. A verifier MUST treat a revocation record as authenticated only if: its resolving key manifest is itself self-consistent; its signing key resolves to a key-entry with status == "active" — a compromised or retired key's signature MUST be rejected exactly as it would be on a receipt; revoked_at falls within that key's validity window; and the signature verifies. A verifier MUST fail closed (treat as unauthenticated) on any malformed, wrong-typed, or missing input, rather than raising. An unauthenticated record that nonetheless matches this receipt's receipt_id MUST be ignored, with a warning, never honored.¶

Freshness anchor. T, in not_revoked_as_of:<T>, MUST be computed as the maximum revoked_at across all authenticated records the verifier consulted in the supplied revocation view, regardless of which receipt_id they target — it describes how current the verifier's authenticated feed is, restricted to authenticated records so that a forged far-future revoked_at cannot inflate the reported freshness. With zero authenticated records the result MUST be the bare literal unknown.¶

Revocation-view ceiling. A verifier MUST bound the number of records it will evaluate from an untrusted revocation view to 10,000. An oversized view is never truncated and never raises; it fails closed for revocable receipts (an untrusted view too large to evaluate cannot rule out a revocation, so it MUST NOT certify the receipt: this is recorded as an error, ok becomes false), while for revocability: "none" receipts an oversized view is a non-fatal warning instead, since a revocation record can never affect ok for that class regardless of view size. This bound exists independently of the Structural ceilings of Section 7: it is a per-call record-count cap on trusted-input-shaped-as-untrusted data (the revocation_view parameter), evaluated at Step 6, never a wire-format or manifest-shape structural bound checked before cryptographic or schema work runs.¶

9. Security Considerations

This section distills the security-relevant properties of the material specified above; the maintained, living threat model (docs/spec/attest-threat-model.md in the attest source repository) is the normative-in-intent, continuously updated companion analysis and takes precedence over this summary.¶

Offline verification is trust-on-first-use unless a TLS root is established. A verifier that has never fetched an issuer's key manifest over TLS from that issuer's own domain reports trust: "unauthenticated_tofu", never "verified", and this document defines no registry or alternate root of trust that upgrades that value; a relying party that requires stronger provenance than TOFU must obtain the manifest over TLS itself.¶

Key compromise and rotation continuity are fail-closed. A key marked compromised invalidates every signature ever made with it, and a discontinuous manifest rotation is reported, never silently auto-accepted (Section 6). Both properties depend on the verifier actually holding, or being able to validate, a continuous manifest chain; a verifier that bootstraps trust from an isolated manifest with no chain cannot detect a rollback to an earlier, since-compromised state on its own.¶

Canonicalization strictness is deliberate. attest-JCS's duplicate-member rejection, integer-only number restriction, and lone-surrogate rejection (Section 4) exist so that two independent implementations parsing the same bytes always compute the identical signature input; a canonicalizer bug is a silent signature mismatch, not a loud parse error, which is why cross-language parity on the conformance corpus (Section 1) is load-bearing for this property rather than merely a testing convenience.¶

Signature malleability is closed by a pinned ruleset, not by trusting a library's defaults. The Ed25519 verification rules of Section 5.1 (non-canonical scalar rejection, small-order/non-canonical point rejection) exist because different cryptographic backends do not agree on malleability handling by default; implementations built on different backends are expected to disagree loudly at conformance-test time rather than silently accepting a malleable signature in the field.¶

The hybrid profile's post-quantum rationale is explicit and bounded. Section 5.2 defends against an attacker who can break exactly one of its two primitives, whether that break is a future cryptographically-relevant quantum computer against Ed25519 or a classical cryptanalytic advance against ML-DSA-65; it makes no claim about an attacker capable of breaking both simultaneously, and the mixed-keyset prohibition (Section 5.2) exists because an issuer that adopts the hybrid profile but leaves an Ed25519-only key active would otherwise silently forfeit that guarantee for any receipt forged under the still-active classical-only sibling.¶

A signature establishes what was signed, never why. Nothing in the material this document specifies distinguishes a voluntary signature from a coerced one: a revocation record produced under compulsion authenticates identically to one produced voluntarily. This is a permanent boundary of what a signature scheme can prove, not a gap this document proposes to close.¶

Structural ceilings bound resource exhaustion before cryptographic work runs. The ceilings of Section 7 (envelope size, manifest array lengths, parse-tree nesting depth) exist so that a hostile envelope or manifest cannot force a verifier to spend unbounded resources parsing or evaluating it before any signature or schema check has a chance to reject it outright. The revocation-view record ceiling (Section 8) bounds a distinct, later-evaluated input — the untrusted revocation_view supplied at Step 6, only once signature and schema have both already succeeded — and exists independently of the pre-crypto ceilings above, for the same resource-exhaustion reason applied to that later, separately-supplied input.¶

10. Privacy Considerations

This section distills the privacy-relevant properties of the material specified above; the maintained, living privacy considerations document (docs/spec/attest-privacy.md in the attest source repository) is the continuously updated companion analysis, using the RFC 6973 threat vocabulary, and takes precedence over this summary.¶

The buyer object's specified fields carry no plaintext identifier. The buyer object's specified properties are commitment, identifier_type, and pubkey (Section 3.1); none of the three is a plaintext identifier — commitment is a salted commitment, pubkey a pseudonymous public key, and identifier_type a non-personal enum (issuer-account or email). This is a bounded property, scoped to that specified set, not a guarantee about the buyer object as a whole: Section 3.1 permits every payload object, buyer included, to carry additional, unlisted properties, and a verifier running Section 7 MUST accept a nested unrecognized buyer member as signed and valid, with no mandated warning. Such a member is outside this guarantee and MAY carry a plaintext identifier. Restricted to the specified field set, a verifier running Section 7 without a disclosure never sees a plaintext identifier there, and binding is not itself a component of ok. The per-receipt salt required by Section 3.2 means the same identifier commits to an unrelated value in each receipt, confining a leaked salt's exposure to that one receipt's commitment path.¶

buyer.pubkey is pseudonymous, not an identity credential. It is optional, defaults to null for client-less flows, and a verifier MUST NOT treat its equality across two receipts as proof of buyer identity (Section 3.2); this is a property this document requires of a conforming verifier's own verdict, not a property the wire format itself enforces against a party that chooses to reuse a key.¶

Per-receipt salting is a commitment-path control, not a general unlinkability guarantee. Two receipts issued to the same buyer carry unrelated commitment values, and that is the entire effect of the salting requirement. Every other stable value in a pair of receipts — a reused buyer.pubkey, a non-null supersedes pointer, an account handle placed in work.identifiers, a shared kid, or a per-buyer terms_uri — remains exactly what it was, and a party holding two such receipts can still join them by any of these means. This document does not claim, and implementers MUST NOT represent, unlinkability across a buyer's whole receipt set as a property the format provides; what it provides is that the commitment values themselves do not supply the join.¶

Pseudonymity toward third parties is not anonymity toward the issuer: the issuer itself computes the commitment from an identifier it holds and generates the salt, so, for as long as it retains or can derive that material, it can recompute and recognize the corresponding commitments. Neither this profile nor the living specification requires or forbids that retention.¶

11. IANA Considerations

This document has no IANA actions.¶

12. Extensions

This section is entirely non-normative. It points at material the living specification defines and normatively governs; nothing stated in this section imposes a requirement, and neither of the two profiles it summarizes is part of this document's own conformance surface (Section 1). A conforming implementation of this document alone implements neither.¶

Appendix A. Relationship to Existing Standards

This appendix is a compressed distillation of a companion document in the attest source repository, docs/spec/attest-standards-relationship.md ([ATTEST-REPO]), which is the canonical source for this material and states each boundary at full length, including what a future bridge to a given standard could look like. This appendix is necessarily incomplete relative to that document and defers to it on any point of detail.¶

W3C Verifiable Credentials [W3C.VC-DATA-MODEL]. The VC Data Model describes an open-world claim shape secured by a plurality of possible proof suites. attest's payload has a fixed required core with a single mandatory canonicalization profile (Section 4), made cross-language-safe by a shared conformance corpus rather than by proof-suite negotiation; the two models trade in opposite directions on purpose. An attest envelope could in principle be carried inside a credential's subject as an opaque, independently verifiable object; neither specification depends on the other.¶

eIDAS 2.0 and the EUDI Wallet. eIDAS 2.0 attests to identity and regulated attributes through a wallet-mediated, legally tiered apparatus (qualified and public-sector electronic attestations of attributes). attest attests to a merchant's grant of a license, verified entirely offline with no wallet, attestation provider, or Member State supervision anywhere in its path. The two frameworks attest to different kinds of fact for different kinds of relying party.¶

JOSE/JWS [RFC7515] and COSE [RFC9052]. Both formats sign the producer's own serialized payload bytes as transmitted (or a deterministic re-encoding derived from them), which is exactly what makes detached content a first-class feature of each. attest inverts that relationship: its signature input is the canonical re-derivation of the parsed payload (Section 4), recomputable from a parsed JSON object in any language with no side channel and no preserved wire form to keep — at the cost of requiring every implementation to canonicalize identically, which is exactly the cross-language risk the conformance corpus (Section 1) exists to make checkable rather than merely asserted.¶

RFC 8785 (JCS). attest-JCS (Section 4) is a restriction of, not an alternative to, [RFC8785]: every attest-JCS output is also a valid RFC 8785 output. What attest-JCS adds — the integer-only number restriction, duplicate- member rejection, and lone-surrogate rejection — narrows the accepted input set within RFC 8785's own envelope; it never departs from it.¶

C2PA [C2PA]. A C2PA manifest answers what an asset is and how it was produced. attest answers a different, adjacent question about the same asset: that a license to hold or use a copy of it was granted, by whom, to whom, and under what terms. A C2PA-signed asset and an attest receipt for the same underlying artifact are not in tension and can coexist without any new mechanism in either specification.¶

SCITT and RFC 9943. A SCITT "receipt" is a transparency service's proof that a signed statement was registered — evidence of inclusion in an append-only log. An attest "receipt" is the signed purchase statement itself (Section 2). The two protocols use one word for two different things. Where the living specification's Stage 2 log substrate (Section 12.1) genuinely does touch SCITT's territory — an append-only, Merkle-tree-based registration and inclusion-proof substrate — that overlap is real: attest's log applies the same class of transparency-log machinery to a narrower, purchase-evidence-specific evidence model, keeping the log strictly corroborative and never authoritative over a receipt's own signature-based validity.¶

RATS (RFC 9334). Restated from Section 2: "attest" is a project name chosen with no relationship to the RATS architecture, and this document's protocol makes no RATS claim — no Attester, Verifier, or Relying Party role mapping in the RATS sense, and no Evidence, Attestation Results, or execution-environment endorsement semantics.¶

Author's Address