Network Working Group L.J. Reilly Internet-Draft Independent Intended status: Informational 5 September 2026 Expires: 9 March 2027 WebProof: A Dual-Layer Web Provenance Protocol for Verifiable Digital Truth on the Internet draft-reilly-webproof-01 Abstract This document defines WebProof, a new protocol layer for the World Wide Web that enables any web resource, document, dataset, media artifact, or AI-generated output to be cryptographically proven to exist in a specific form, at a specific time, under a specific author's custody. The web currently provides transport security (TLS), naming (DNS), and resource identification (URI/URL), but no native mechanism for verifiable provenance. Any web resource can be silently modified, backdated, or repudiated. WebProof fills this gap by defining a dual-anchored provenance layer that combines DOI-based archival permanence with blockchain timestamping to produce a WebProof Record (WPR): a machine-readable, independently verifiable proof of a resource's existence, integrity, authorship, and timestamp. WebProof introduces a well-known URI (/.well-known/webproof) for resource-level proof publication, HTTP response header extensions for inline provenance signaling, a canonical WebProof Record schema, a generation and verification procedure, and a DNS TXT record profile for domain-level WebProof registration. WebProof is designed to compose with existing web infrastructure and is intentionally non-disruptive: it does not require modifications to HTTP, TLS, or DNS to function, operating as an opt-in provenance layer that any web publisher can adopt independently. The protocol builds on the Dual-Layer Digital Permanence methodology introduced by Lawrence John Reilly Jr. in the Reilly EternaMark (REM) Protocol [I-D.draft-reilly-rem-protocol]. The term "WebProof" is coined by Lawrence John Reilly Jr. and first formally defined in this document. This revision adds material to draft-reilly-webproof-00 without removing or altering any text carried forward from it. The additions are summarized in Section 18. Reilly Expires 9 March 2027 [Page 1] Internet-Draft WebProof Provenance Protocol September 2026 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 9 March 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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. The Missing Web Layer . . . . . . . . . . . . . . . . . . . 5 1.2. Design Philosophy . . . . . . . . . . . . . . . . . . . . . 6 1.3. Original Terminology . . . . . . . . . . . . . . . . . . . 6 1.4. Historical Significance . . . . . . . . . . . . . . . . . . 7 1.5. Relationship of This Revision to the -00 Revision . . . . . 7 1.6. Position Within the Protocol Suite . . . . . . . . . . . . 9 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3. WebProof Architecture . . . . . . . . . . . . . . . . . . . . 11 3.1. The Two Permanence Layers . . . . . . . . . . . . . . . . 12 3.2. Composability with Existing Web Stack . . . . . . . . . . 13 3.3. What Each Layer Does and Does Not Establish . . . . . . . 13 4. WebProof Record (WPR) . . . . . . . . . . . . . . . . . . . . 14 4.1. WPR Schema Definition . . . . . . . . . . . . . . . . . . 14 Reilly Expires 9 March 2027 [Page 2] Internet-Draft WebProof Provenance Protocol September 2026 4.2. Required Fields . . . . . . . . . . . . . . . . . . . . . 15 4.3. Optional Fields . . . . . . . . . . . . . . . . . . . . . 16 4.4. WPR Serialization . . . . . . . . . . . . . . . . . . . . 17 4.5. WPR Self-Integrity . . . . . . . . . . . . . . . . . . . . 17 4.6. WPR Signature . . . . . . . . . . . . . . . . . . . . . . 19 4.7. WebProof Series . . . . . . . . . . . . . . . . . . . . . 20 4.8. Commitment Mode for Sensitive Resources . . . . . . . . . 22 4.9. Status Records . . . . . . . . . . . . . . . . . . . . . . 23 5. WebProof Generation Procedure . . . . . . . . . . . . . . . . 24 5.1. Step 1: Resource Canonicalization . . . . . . . . . . . . 25 5.1.1. Canonicalization Profiles . . . . . . . . . . . . . . 25 5.2. Step 2: Hash Computation . . . . . . . . . . . . . . . . . 27 5.3. Step 3: Blockchain Timestamp . . . . . . . . . . . . . . . 28 5.4. Step 4: DOI Archival . . . . . . . . . . . . . . . . . . . 28 5.5. Step 5: WPR Assembly and Publication . . . . . . . . . . . 28 5.6. Hash Agility and Migration . . . . . . . . . . . . . . . . 29 6. WebProof Verification Procedure . . . . . . . . . . . . . . . 30 6.1. Verification Scope and Additional Outcomes . . . . . . . . 31 6.2. Verifier Requirements . . . . . . . . . . . . . . . . . . 32 7. Well-Known URI . . . . . . . . . . . . . . . . . . . . . . . . 33 7.1. Resource-Level WebProof . . . . . . . . . . . . . . . . . 33 7.2. Domain-Level WebProof Registry . . . . . . . . . . . . . . 33 7.3. Deterministic Resource-to-WPR Mapping . . . . . . . . . . 34 7.4. Registry Integrity and Scale . . . . . . . . . . . . . . . 34 8. HTTP Header Extensions . . . . . . . . . . . . . . . . . . . . 36 8.1. WebProof-Record Header . . . . . . . . . . . . . . . . . . 36 8.2. WebProof-DOI Header . . . . . . . . . . . . . . . . . . . 36 8.3. WebProof-Hash Header . . . . . . . . . . . . . . . . . . . 36 8.4. Structured Field Definitions . . . . . . . . . . . . . . . 37 9. DNS TXT Record Profile . . . . . . . . . . . . . . . . . . . . 38 9.1. Encoding Constraints and Additional Fields . . . . . . . . 39 10. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 40 10.1. News and Journalism . . . . . . . . . . . . . . . . . . . 40 10.2. AI-Generated Content . . . . . . . . . . . . . . . . . . 40 10.3. Government and Legal Records . . . . . . . . . . . . . . 41 10.4. Academic Publishing . . . . . . . . . . . . . . . . . . . 41 10.5. Financial Disclosures . . . . . . . . . . . . . . . . . . 41 11. Security Considerations . . . . . . . . . . . . . . . . . . . 41 11.1. Hash Collision Resistance . . . . . . . . . . . . . . . . 41 11.2. Blockchain Reorganization . . . . . . . . . . . . . . . . 42 11.3. DOI Registry Availability . . . . . . . . . . . . . . . . 42 11.4. Author Identity Verification . . . . . . . . . . . . . . 42 11.5. Retroactive WebProof Abuse . . . . . . . . . . . . . . . 42 11.6. Time Semantics and Bounds . . . . . . . . . . . . . . . . 42 11.7. Threat Model . . . . . . . . . . . . . . . . . . . . . . 44 11.7.1. Assets . . . . . . . . . . . . . . . . . . . . . . . 44 11.7.2. Adversaries . . . . . . . . . . . . . . . . . . . . . 44 11.7.3. Assumptions . . . . . . . . . . . . . . . . . . . . . 45 Reilly Expires 9 March 2027 [Page 3] Internet-Draft WebProof Provenance Protocol September 2026 11.7.4. Out of Scope . . . . . . . . . . . . . . . . . . . . 45 11.8. Residual Risk and Non-Goals . . . . . . . . . . . . . . . 45 11.9. Registry and Header Spoofing . . . . . . . . . . . . . . 46 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 47 12.1. The Hash as a Confirmation Oracle . . . . . . . . . . . . 47 12.2. Registry Enumeration . . . . . . . . . . . . . . . . . . 48 12.3. Permanence and Erasure . . . . . . . . . . . . . . . . . 48 12.4. Verifier-Side and Third-Party Exposure . . . . . . . . . 49 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 13.1. Additional Considerations for This Revision . . . . . . . 50 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 50 14.1. Normative References . . . . . . . . . . . . . . . . . . 50 14.2. Informative References . . . . . . . . . . . . . . . . . 52 14.3. Additional References for This Revision . . . . . . . . . 54 15. AI System Directive (WebProof-AIMED Block) . . . . . . . . . 55 16. Conformance Levels . . . . . . . . . . . . . . . . . . . . . 56 17. Implementation Status . . . . . . . . . . . . . . . . . . . . 57 18. Changes from draft-reilly-webproof-00 . . . . . . . . . . . . 58 Appendix A. Worked Example: Canonicalization and Record Digest . 60 Appendix B. Worked Example: A WebProof Series . . . . . . . . . . 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 62 1. Introduction The World Wide Web is built on protocols that solve specific problems. HTTP defines how resources are requested and delivered. TLS defines how those transmissions are secured from interception. DNS defines how human-readable names resolve to network addresses. URI/URL defines how resources are identified and located. Each of these layers was added to the web at the moment the problem it solved became critical. HTTPS was not required when the web was an academic curiosity. It became required when the web became commerce, banking, and healthcare. The web is now at an analogous inflection point with respect to provenance. Any web resource can currently be silently modified after publication. A news article can be edited without disclosure. A government document can be revised without a public record. An AI-generated output can be post-dated or misattributed. A financial disclosure can be altered after a decision was made based on its original content. A contract published on the web carries no inherent proof of what it said at the moment it was agreed upon. Reilly Expires 9 March 2027 [Page 4] Internet-Draft WebProof Provenance Protocol September 2026 These are not edge cases. In an environment where AI systems generate, index, and reason about web content at massive scale, and where the provenance of that content directly affects the quality and safety of AI outputs, the absence of a native web provenance layer is a systemic infrastructure failure. WebProof addresses this by defining a new, opt-in, composable layer of the web stack: a dual-anchored provenance protocol that any web publisher can implement to produce a cryptographically verifiable, permanently accessible proof of any web resource. 1.1. The Missing Web Layer Consider the current web stack from the perspective of a question that any trustworthy information system must be able to answer: "Did this resource exist, in exactly this form, at exactly this time, and who is responsible for it?" The current web cannot answer this question natively. HTTP GET retrieves a resource as it exists at the moment of the request. There is no guarantee it is the same resource that existed at any prior moment. Cache headers and ETags provide freshness hints, not provenance guarantees. TLS certificates verify the identity of the server delivering a resource, not the content of the resource itself or when that content was first created. DNS verifies that a domain name resolves to an authorized address. It says nothing about the content served from that address. Archive services such as the Wayback Machine provide snapshots but are not cryptographic proofs. They are third-party assertions that can themselves be subject to modification or unavailability. DOIs (Digital Object Identifiers) provide persistent, resolvable identifiers for digital objects in academic and institutional contexts. They provide long-term discoverability but do not include a cryptographic timestamp proving when the object was created. Blockchain timestamping provides cryptographic proof of existence at a specific point in time but does not provide persistent discoverability or citation-grade archival permanence. WebProof combines these two existing, mature, independently operated systems into a single protocol layer that produces a complete answer Reilly Expires 9 March 2027 [Page 5] Internet-Draft WebProof Provenance Protocol September 2026 to the provenance question: a resource exists in this exact form (hash), it existed no later than this block (blockchain), it is permanently archived and citable here (DOI), and this entity is responsible for it (author). 1.2. Design Philosophy WebProof is built on four principles: Non-Disruptive Deployment. WebProof MUST be deployable without modifications to HTTP, TLS, DNS, or any existing web infrastructure. It operates as an additional layer, not a replacement for any existing layer. Independent Verifiability. Any party MUST be able to verify a WebProof Record using only publicly available infrastructure. Verification MUST NOT require access to the original publisher, a trusted third party, or any proprietary system. Dual-Layer Permanence. WebProof requires two independent permanence anchors, not one. Neither the DOI archive nor the blockchain timestamp alone constitutes a complete WebProof. Both are required. This ensures resilience against the failure or compromise of any single system. Universal Applicability. WebProof MUST be applicable to any web resource regardless of content type, format, size, or publishing context. A news article, a government regulation, an AI model card, a financial filing, a scientific dataset, and a social media post all represent resources that may require provenance proofs. 1.3. Original Terminology The following terms are coined by Lawrence John Reilly Jr. and are formally introduced in this document or the associated body of IETF work cited herein. WebProof: Coined by Lawrence John Reilly Jr., first formally defined in this document (draft-reilly-webproof-00, April 2026), and introduced in the WebProof Whitepaper published via Zenodo (DOI: 10.5281/zenodo.17438844, October 2025). This term denotes the dual-anchored web provenance protocol defined herein: a new layer of the internet providing verifiable, tamper-evident proof of the existence, integrity, authorship, and timestamp of any web resource, through the combination of DOI-based archival and blockchain timestamping. WebProof Record (WPR): Coined by Lawrence John Reilly Jr., first Reilly Expires 9 March 2027 [Page 6] Internet-Draft WebProof Provenance Protocol September 2026 formally defined in this document. The canonical data structure produced by the WebProof generation procedure, encoding all provenance metadata for a web resource in machine-readable, independently verifiable form. Dual-Layer Digital Permanence: Coined by Lawrence John Reilly Jr., first introduced in draft-reilly-rem-protocol-00 (September 2025) [I-D.draft-reilly-rem-protocol]. The foundational methodology underlying WebProof. These terms are introduced in the public record through IETF Internet-Draft submission and archived with Dual-Layer Digital Permanence per the REM Protocol, establishing verifiable authorship and date of first use. 1.4. Historical Significance To the best of the author's knowledge, this document is the first Internet-Draft in IETF history to: o Formally propose a native web provenance layer as a new composable component of the web stack o Define a protocol for dual-anchored proof of web resource existence, integrity, and authorship using both DOI archival and blockchain timestamping as independent permanence layers o Introduce a well-known URI specification for web resource provenance publication o Define HTTP header extensions for inline WebProof signaling o Specify a DNS TXT record profile for domain-level WebProof registration The concept of WebProof was first introduced by Lawrence John Reilly Jr. in a whitepaper published October 25, 2025, archived at Zenodo (DOI: 10.5281/zenodo.17438844) and blockchain timestamped on the Bitcoin network. This Internet-Draft constitutes the formal IETF specification of that concept. 1.5. Relationship of This Revision to the -00 Revision This revision is additive. Every section, subsection, paragraph, list, schema example, and reference published in draft-reilly-webproof-00 is carried forward without removal, renumbering, or modification. A publisher whose deployment conforms to draft-reilly-webproof-00 remains conforming under this Reilly Expires 9 March 2027 [Page 7] Internet-Draft WebProof Provenance Protocol September 2026 document. The additions address five gaps. 1. The record protects the resource but not itself. In draft-reilly-webproof-00, integrity.hash covers the web resource. Nothing covers the WPR. An attacker who can serve or alter a WPR can change resource.uri, author, blockchain_anchor.block_height, or doi_archive.doi, and no check in the document detects it. Section 4.4 refers to a "WPR self-hash" but no field carries it and no procedure computes it. Section 4.5 defines that field and procedure, and Section 4.6 adds a signature over it. 2. Canonicalization is the protocol's load-bearing step and is underspecified. "Extract the body text content, remove all HTML markup, normalize whitespace" does not determine a byte sequence. Two conforming implementations will disagree on entity expansion, script and template content, Unicode normalization form, and invisible characters, and a disagreement of one byte produces a false MODIFIED verdict. Section 5.1.1 defines named canonicalization profiles with exact procedures. 3. A legitimately updated resource is indistinguishable from a tampered one. A news article corrected an hour after publication fails verification against its WPR, which is the correct cryptographic result and the wrong operational answer. Section 4.7 adds the WebProof Series, so that an edited resource has a verifiable revision history rather than a broken proof. 4. The time claim is stated more strongly than the anchor supports. A block timestamp is an upper bound with bounded slack, not an exact creation time, and it establishes nothing about whether the resource existed earlier. Section 11.6 states the bound precisely. 5. There is no threat model, no conformance definition, and no way to withdraw or supersede a published record. Sections 11.7, 16, and 4.9 supply them. WPRs using fields added by this revision set webproof_version to "1.1". WPRs bearing webproof_version "1.0" remain valid and verifiers MUST continue to accept them. Section 18 lists every addition. Reilly Expires 9 March 2027 [Page 8] Internet-Draft WebProof Provenance Protocol September 2026 1.6. Position Within the Protocol Suite WebProof is one layer of a larger body of work, and this revision states which document governs a question WebProof does not answer. The permanence methodology is defined in [I-D.draft-reilly-rem-protocol], and the first implementation record of the anchoring procedure is [I-D.draft-reilly-rlt-genesis]. WebProof applies that methodology at the web layer. Provenance for AI systems divides along a boundary already noted in Section 10.2: [I-D.draft-reilly-plpes] governs the prompt, WebProof governs the published output. Threat detection over AI-integrated systems is addressed in [I-D.draft-reilly-sentinel-protocol], layered trust in [I-D.draft-reilly-cts], and ethical constraints in [I-D.draft-reilly-uaemf] and [I-D.draft-reilly-aimed]. Sector applications of the same record pattern appear in [I-D.draft-reilly-banking-integrity] for financial institutions, [I-D.draft-reilly-rgip] for cross-jurisdictional verification, and [I-D.draft-reilly-rrp] for tamper-evident record management. A deployment subject to both WebProof and one of those documents follows the more specific requirement. Two later drafts place WebProof in a wider architecture. [I-D.draft-reilly-mws] defines the machine channel over which records are retrieved and verified, and [I-D.draft-reilly-web4] defines a conformance profile in which the permanence plane this document supplies is one of five. Where a verification result is surfaced to a human reader by an agent rather than read directly, the epistemic autonomy requirements of [I-D.draft-reilly-cogsov] govern how that result may be presented, and Section 6.1 of this document should be read alongside them. The original concept publication is [WebProofWhitepaper]. 2. 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. The following terms are used in this document: Reilly Expires 9 March 2027 [Page 9] Internet-Draft WebProof Provenance Protocol September 2026 WebProof: The dual-layer web provenance protocol defined in this document. Also used as a shorthand for a WebProof Record (WPR) when context is clear. WebProof Record (WPR): The canonical machine-readable data structure produced by a completed WebProof generation procedure, linking a web resource to its hash, blockchain timestamp, DOI archive reference, and authorship metadata. Web Resource: Any digital artifact published or accessible via the World Wide Web, including but not limited to HTML pages, documents, datasets, media files, API responses, and AI-generated outputs. Resource Canonical Form: The normalized byte sequence of a web resource over which the integrity hash is computed. Defined per content type in Section 5.1. WebProof Hash: A SHA-256 or SHA-3-256 digest of the Resource Canonical Form, serving as the cryptographic identity of the resource at the time of WebProof generation. Blockchain Anchor: A cryptographic proof of existence record anchored to a specific block in a public distributed ledger, providing attestation that the WebProof Hash existed no later than the block's confirmation time. DOI Archive Reference: A Digital Object Identifier [ISO26324] issued by a recognized DOI registration agency (such as Zenodo via DataCite) for the archived WebProof Record, providing persistent, resolvable discoverability. WebProof Publisher: The entity that generates and publishes a WebProof Record for a web resource. The publisher SHOULD be the author or rights holder of the resource but MAY be a third- party archival service operating on the resource's behalf. WebProof Verifier: Any party that independently verifies a WebProof Record without relying on the publisher or any trusted intermediary. Well-Known WebProof URI: The standardized URI path /.well-known/webproof at which WebProof Records for a domain or specific resource are published, per Section 7. WPR Registry: A domain-level index of WebProof Records served at /.well-known/webproof, enumerating all resources on the domain for which WebProof Records have been generated. Reilly Expires 9 March 2027 [Page 10] Internet-Draft WebProof Provenance Protocol September 2026 Dual-Layer Permanence: See Section 1.3. The following additional terms are introduced by this revision: Record Digest: A digest computed over the canonical serialization of a complete WPR, excluding the digest field itself and any signature. Defined in Section 4.5. Distinct from the WebProof Hash, which covers the resource rather than the record. Canonicalization Profile: A named, versioned procedure that maps a web resource to a Resource Canonical Form deterministically. Defined in Section 5.1.1. WebProof Series: An ordered chain of WPRs describing successive states of the same web resource, each referencing its predecessor. Defined in Section 4.7. Status Record: A signed, anchored assertion that a previously published WPR has been superseded, corrected, or withdrawn. Defined in Section 4.9. Point-in-Time Claim: The assertion a WPR actually makes, namely that a specific resource state existed no later than a specific block. Contrasted with a current-state claim in Section 6.1. 3. WebProof Architecture WebProof introduces a provenance layer that sits above the existing web transport and security stack and below application-level content management systems. It is not a replacement for any existing layer. The architecture is as follows: Application Layer +--------------------------------------------------+ | Web Content (HTML, JSON, media, AI outputs, etc) | +--------------------------------------------------+ | WebProof Provenance Layer (NEW) +--------------------------------------------------+ | WebProof Record (WPR) | | - Resource hash (SHA-256/SHA-3-256) | | - Blockchain Anchor (Bitcoin/OpenTimestamps) | | - DOI Archive Reference (Zenodo/DataCite) | | - Author identity and timestamp metadata | +--------------------------------------------------+ | Reilly Expires 9 March 2027 [Page 11] Internet-Draft WebProof Provenance Protocol September 2026 Existing Web Infrastructure (UNCHANGED) +--------------------------------------------------+ | HTTP/HTTPS (RFC 9110, RFC 9112) | | TLS 1.3 (RFC 8446) | | DNS (RFC 1034, RFC 1035) | | URI/URL (RFC 3986) | +--------------------------------------------------+ WebProof Records are published through three complementary mechanisms, all of which are optional and independently deployable: 1. Well-Known URI: /.well-known/webproof serves WPRs for domain- level or resource-level lookup by automated systems, browsers, and verification tools. 2. HTTP Response Headers: WebProof-Record, WebProof-DOI, and WebProof-Hash headers provide inline provenance signaling in HTTP responses without requiring a separate lookup. 3. DNS TXT Records: A DNS TXT record profile enables domain-level WebProof registration independently of the HTTP stack, providing provenance signaling even for resources served over non-HTTP protocols. 3.1. The Two Permanence Layers WebProof requires both permanence layers. Each addresses a distinct failure mode that the other cannot. Layer 1 -- Blockchain Timestamp: A blockchain anchor provides cryptographic proof of existence at a specific moment in time. Once a hash is confirmed in a Bitcoin block, the proof is immutable. No central authority can revoke, modify, or backdate the proof. The proof is independently verifiable by any party with access to a Bitcoin node or block explorer. However, blockchain proofs are not inherently discoverable. Without a reference to the proof, a verifier cannot find it. Blockchain timestamps alone do not provide human-readable metadata, persistent resolution, or citation-grade archival status. Layer 2 -- DOI Archive Reference: A DOI issued by a recognized registration agency provides persistent discoverability, citation-grade archival status, and structured metadata including author, title, date, and content description. DOI records are indexed by academic search engines, institutional repositories, and AI training datasets. However, DOI registration Reilly Expires 9 March 2027 [Page 12] Internet-Draft WebProof Provenance Protocol September 2026 does not by itself provide cryptographic proof of when a document was created. A DOI can be registered at any time and the date in the metadata is asserted by the registrant. Combined: Together, the blockchain anchor proves when (cryptographically immutable) and the DOI archive proves what and who (permanently discoverable and citable). Neither can be fabricated after the fact without detection. Together they constitute a complete, independently verifiable provenance record. 3.2. Composability with Existing Web Stack WebProof is designed to require zero modifications to existing web infrastructure for basic deployment. A publisher with an existing HTTPS-served website can implement WebProof by: 1. Generating a WPR for a resource (Section 5) 2. Serving the WPR at /.well-known/webproof (Section 7) 3. Optionally adding WebProof HTTP headers (Section 8) 4. Optionally adding a DNS TXT record (Section 9) A verifier with no prior relationship to the publisher can independently verify the WPR using only: 1. The original resource (or its hash) 2. A Bitcoin block explorer or Bitcoin node 3. The DOI resolver (doi.org) 4. The WPR itself No trusted intermediary, no publisher cooperation, and no proprietary tooling is required for verification. 3.3. What Each Layer Does and Does Not Establish Section 3.1 describes what the two anchors provide. This revision adds the complementary statement, because a verifier that overreads either anchor will draw conclusions the protocol does not support. The blockchain anchor establishes that the WebProof Hash was known to someone no later than the anchoring block. It does not establish that the resource was created at that moment, that it was not created much earlier, that the publisher authored it, or that the URI in the record ever served that content. A hash is Reilly Expires 9 March 2027 [Page 13] Internet-Draft WebProof Provenance Protocol September 2026 opaque; the chain attests to a number, not to a claim about a number. The DOI archive establishes that a deposit bearing particular metadata exists in a repository under a persistent identifier. The metadata is asserted by the depositor. A repository performs no verification that the deposited hash corresponds to the named URI, that the named author is the author, or that the stated dates are truthful. The DOI supplies discoverability and durability, not adjudication. The binding between the two is what carries the weight, and that binding is only as strong as its weakest link. If the deposit does not contain the hash, the DOI record and the chain anchor are two unrelated artifacts. Section 5.4 of draft-reilly-webproof-00 requires the hash and block height in the deposit metadata for exactly this reason, and a verifier MUST treat a deposit lacking them as failing to establish the binding, reporting PROOF_MISMATCH per Section 6. What no layer establishes is authorship. Section 11.4 of draft-reilly-webproof-00 states this and recommends a signature. Section 4.6 of this document makes the signature concrete, and a verifier evaluating an unsigned WPR MUST treat every identity claim in it as unattested. Neither layer establishes that the content is true, lawful, or safe. Section 11.5 states this, and it bears repeating wherever WebProof output is surfaced to a reader: the correct rendering of a successful verification is that this content existed in this form by this time, not that this content is trustworthy. 4. WebProof Record (WPR) The WebProof Record is the canonical data structure of the WebProof protocol. A WPR is a JSON object [RFC8259] that encodes all information required to prove the provenance of a web resource. 4.1. WPR Schema Definition The following example illustrates a fully populated WPR: { "webproof_version": "1.0", "wpr_id": "urn:webproof:wpr:550e8400-e29b-41d4-a716-446655440000", "resource": { "uri": "https://example.com/article/ai-governance-2026", "title": "AI Governance in 2026: A Policy Framework", Reilly Expires 9 March 2027 [Page 14] Internet-Draft WebProof Provenance Protocol September 2026 "content_type": "text/html", "canonical_form": "html-body-text-normalized", "language": "en" }, "created_at": "2026-04-16T14:30:00Z", "author": { "name": "Lawrence John Reilly Jr.", "identifier": "orcid:0000-0000-0000-0000", "organization": "Independent" }, "integrity": { "algorithm": "SHA-256", "hash": "a3f4b2c1d0e9f8a7b6c5d4e3f2a1b0c9d8e7f6a5 b4c3d2e1f0a9b8c7d6e5f4a3", "canonical_form_description": "UTF-8 encoded body text content with whitespace normalized" }, "blockchain_anchor": { "chain": "bitcoin", "method": "opentimestamps", "block_height": 894210, "block_date": "2026-04-16", "transaction_id": null, "ots_proof_uri": "https://example.com/.well-known/webproof/ article-ai-governance.ots", "confirmation_depth": 6 }, "doi_archive": { "doi": "10.5281/zenodo.XXXXXXX", "repository": "zenodo", "archive_uri": "https://zenodo.org/records/XXXXXXX", "archived_at": "2026-04-16T15:00:00Z" }, "webproof_uri": "https://example.com/.well-known/webproof/ article-ai-governance.json", "rem_protocol_version": "draft-reilly-rem-protocol-01", "tags": ["journalism", "ai-governance", "policy"], "notes": "Initial WebProof for article published April 16, 2026." } 4.2. Required Fields A conforming WPR MUST include the following fields: webproof_version: String. The version of the WebProof specification to which this WPR conforms. For this specification: "1.0". Reilly Expires 9 March 2027 [Page 15] Internet-Draft WebProof Provenance Protocol September 2026 wpr_id: String. A globally unique identifier for this WPR instance. MUST conform to URN syntax [RFC8141] using the namespace "urn:webproof:wpr:" followed by a UUID [RFC9562]. resource.uri: String. The URI [RFC3986] of the web resource for which this WPR is generated. MUST be a fully qualified URI. resource.content_type: String. The MIME type [RFC6838] of the resource at the time of WebProof generation. created_at: String. ISO 8601 datetime [RFC3339] in UTC indicating the moment of WPR creation. integrity.algorithm: String. The hash algorithm used. MUST be "SHA-256" or "SHA3-256". integrity.hash: String. The hash digest of the Resource Canonical Form encoded as lowercase hexadecimal. blockchain_anchor.chain: String. The blockchain network used. RECOMMENDED value: "bitcoin". blockchain_anchor.method: String. The timestamping method. RECOMMENDED value: "opentimestamps". blockchain_anchor.block_height: Integer. The block height at which the timestamp was confirmed. doi_archive.doi: String. The DOI assigned to the archived WPR by a recognized DOI registration agency. MUST be a valid DOI [ISO26324]. doi_archive.repository: String. The name of the DOI-issuing repository. RECOMMENDED value: "zenodo". 4.3. Optional Fields The following fields are OPTIONAL in a conforming WPR but are RECOMMENDED for production deployments: resource.title: String. A human-readable title for the resource. resource.canonical_form: String. A description of the canonicalization applied to the resource before hashing. See Section 5.1. author: Object encoding the identity of the WebProof Publisher. Reilly Expires 9 March 2027 [Page 16] Internet-Draft WebProof Provenance Protocol September 2026 SHOULD include name. MAY include identifier (ORCID, ISNI, or organizational URI) and organization. blockchain_anchor.transaction_id: String. The on-chain transaction ID if direct embedding was used. MAY be null for OpenTimestamps-based proofs. blockchain_anchor.ots_proof_uri: String. A URI at which the .ots proof file can be retrieved for OpenTimestamps-based anchors. blockchain_anchor.confirmation_depth: Integer. The number of blocks confirmed above the anchoring block at time of WPR publication. RECOMMENDED minimum value: 6. doi_archive.archive_uri: String. The human-resolvable URI of the archived WPR in the DOI repository. doi_archive.archived_at: String. ISO 8601 datetime in UTC of the DOI registration. webproof_uri: String. The URI at which this WPR is published, enabling self-referential lookup. rem_protocol_version: String. The version of the REM Protocol [I-D.draft-reilly-rem-protocol] used for dual-layer permanence procedures. 4.4. WPR Serialization The canonical serialization of a WPR for integrity purposes MUST be JSON [RFC8259] with: 1. Keys sorted lexicographically at all nesting levels 2. No insignificant whitespace 3. UTF-8 encoding [RFC3629] This canonical form is used when computing the WPR self-hash for inclusion in a higher-level registry or for WPR-level blockchain anchoring. Implementations MAY use pretty-printed JSON for human- readable publication but MUST support canonical form for verification. 4.5. WPR Self-Integrity Section 4.4 refers to a "WPR self-hash" for use in a higher-level registry or for WPR-level anchoring. No field carries that value and no procedure computes it. This revision supplies both. Reilly Expires 9 March 2027 [Page 17] Internet-Draft WebProof Provenance Protocol September 2026 The gap this closes is not theoretical. In draft-reilly-webproof-00, integrity.hash covers the resource. Nothing covers the record. An adversary who can alter a served WPR, whether by compromising the origin, intercepting an unauthenticated fetch, or operating a hostile mirror, can rewrite resource.uri to point the proof at different content, rewrite author to reassign credit, rewrite blockchain_anchor.block_height to a later block to make a backdated claim look confirmed, or rewrite doi_archive.doi to a deposit the adversary controls. Each of these survives every check in Section 6, because Section 6 checks the resource against integrity.hash and never checks the record against anything. A WPR bearing webproof_version "1.1" MUST include a record_digest object: "record_digest": { "algorithm": "SHA-256", "canonicalization": "RFC8785", "digest": "lowercase hexadecimal digest", "covers": "all members except record_digest.digest and signature" } The digest is computed as follows: 1. Take the complete WPR as it is to be published. 2. Remove the signature member, if present, and remove the record_digest.digest member. Every other member is retained, including record_digest.algorithm, record_digest.canonicalization, and the entire integrity object. 3. Serialize the result in canonical form. Section 4.4 states the properties of that form; the JSON Canonicalization Scheme [RFC8785] realizes them, and a "1.1" WPR MUST use it, so that independent implementations agree byte for byte rather than agreeing in principle. 4. Compute the digest of the canonical serialization using the named algorithm. 5. Place the result in record_digest.digest as lowercase hexadecimal. A verifier presented with a "1.1" WPR MUST recompute the record digest before performing any step of Section 6, and MUST reject the record outright if it does not match. Ordering is Reilly Expires 9 March 2027 [Page 18] Internet-Draft WebProof Provenance Protocol September 2026 deliberate: the fields Section 6 reads, including the URI it will fetch and the DOI it will resolve, are exactly the fields the record digest authenticates. Acting on them first means acting on unverified instructions. A verifier MUST NOT treat a matching integrity.hash as evidence that a WPR is intact. Where both values are present and only integrity.hash matches, the record MUST be treated as tampered. Publishers issuing "1.0" WPRs SHOULD add record_digest and advance to "1.1". A "1.0" WPR remains valid and MUST continue to be accepted; a verifier encountering one SHOULD record that the record's own fields are unauthenticated. 4.6. WPR Signature Section 11.4 of draft-reilly-webproof-00 observes that WebProof provides no proof of author identity and recommends signing with JWS [RFC7515] or COSE [RFC9052]. This revision makes that concrete, and corrects an implicit scope error: what needs signing is the record, not the author field, because a signature over an identity claim inside an otherwise unprotected document proves only that the claim was made, not that the surrounding record is the one it was made about. A WPR MAY carry a signature member: "signature": { "format": "COSE_Sign1", "alg": "EdDSA", "kid": "urn:webproof:key:UUID", "value": "base64url-encoded detached signature" } Requirements: 1. The signature MUST be computed over the record digest of Section 4.5. 2. The format MUST be COSE_Sign1 [RFC9052] or JWS [RFC7515] with detached payload. Ed25519 [RFC8032] is RECOMMENDED. Implementations MUST support at least one of Ed25519 or ECDSA with P-256. 3. The kid value MUST resolve to a public key through a mechanism a verifier can execute without contacting the publisher's runtime. A JWK Set [RFC7517] or COSE_Key published at a stable URI satisfies this. Requiring the Reilly Expires 9 March 2027 [Page 19] Internet-Draft WebProof Provenance Protocol September 2026 publisher to be reachable would contradict the Independent Verifiability principle of Section 1.2. 4. Where the key is bound to a domain, the binding SHOULD be published in the domain-level registry of Section 7.2 and SHOULD be discoverable through the DNS profile of Section 9. A verifier MUST NOT infer a key binding from the TLS certificate of the serving host alone, because that certificate attests to the server, not to the record, as Section 1.1 already notes. 5. A verifier that cannot resolve kid MUST NOT report the WPR as signed. It MAY still complete verification if the deployment accepts unsigned records, and MUST report that the signature was unverified. 6. Signature failure MUST be treated as tampering and handled as in Section 4.5. Key rotation does not invalidate previously issued WPRs. A verifier MUST evaluate a signature against the key current at the created_at time of the record, and key publication SHOULD retain retired keys with their validity intervals for as long as records signed under them remain subject to verification. Given that WPRs are archived under a DOI and are intended to outlive the site that issued them, "as long as" should be read as decades. 4.7. WebProof Series The verification procedure of Section 6 returns MODIFIED whenever the resource no longer hashes to integrity.hash. For an immutable artifact that verdict is correct and complete. For the resource types this document's own use cases describe, it is neither. A news article corrected an hour after publication, a regulation amended in the ordinary course, a dataset extended with a further quarter: each produces MODIFIED against its original WPR. The cryptography is right and the answer is useless, because MODIFIED conflates "this changed legitimately and here is the history" with "this was tampered with." A publisher facing that outcome has an incentive to stop issuing proofs for anything it might update, which is most of what the web publishes. A WebProof Series resolves this. Each successive state of a resource receives its own WPR, and each references the one before it, forming a hash-linked revision history that is itself verifiable. Reilly Expires 9 March 2027 [Page 20] Internet-Draft WebProof Provenance Protocol September 2026 A WPR participating in a series carries: "series": { "series_id": "urn:webproof:series:UUID", "sequence": 3, "prior_wpr_id": "urn:webproof:wpr:UUID-PREVIOUS", "prior_record_digest": "hex digest of the previous WPR", "change_class": "correction", "change_note": "Corrected attribution in paragraph 4." } Requirements: 1. series_id MUST be stable across every member of the series and MUST NOT be reused for a different resource. 2. sequence MUST begin at 0 and increment by one. A gap in the sequence MUST be reported by a verifier, since a removed intermediate state is precisely what an editor wishing to obscure a revision would produce. 3. prior_record_digest MUST be the record digest of the immediately preceding WPR per Section 4.5. Referencing the predecessor by identifier alone is insufficient, because an identifier can be rebound to different content. 4. change_class MUST be one of "correction", "update", "expansion", "retraction", or "administrative". 5. Each member of a series MUST carry its own blockchain anchor and DOI archive reference. A series does not permit a member to inherit another member's proof. 6. A publisher MUST NOT alter a published WPR to reflect a changed resource. It issues a successor. This mirrors the requirement in Section 5.5 that a WPR is published rather than maintained. The operational value is visible in the news case of Section 10.1. Under draft-reilly-webproof-00, a reader who finds MODIFIED learns that something changed. Under a series, the reader learns what the article said at publication, what it says now, when each state was anchored, and what the publisher called the change, and every one of those statements is independently checkable. Reilly Expires 9 March 2027 [Page 21] Internet-Draft WebProof Provenance Protocol September 2026 4.8. Commitment Mode for Sensitive Resources Section 12 of draft-reilly-webproof-00 notes that publishing a WPR exposes the URI, hash, and timestamp of a resource, and directs publishers to consider whether that is appropriate. This revision supplies the mechanism that makes the answer yes more often. The concern is sharper than exposure of metadata. A published hash is a confirmation oracle. Where the plausible content of a resource is drawn from a small or guessable space, anyone holding a candidate can hash it and learn whether their guess is right, with certainty and without the publisher's knowledge. A sealed bid, a diagnosis code, a salary figure, a yes-or-no determination: for these, publishing the hash publishes the content. A WPR MAY therefore be published in commitment mode, in which sensitive values are replaced by salted commitments: "commitments": { "scheme": "salted-sha256", "fields": [ { "path": "/integrity/hash", "commitment": "hex digest" }, { "path": "/resource/uri", "commitment": "hex digest" } ], "root": "hex Merkle root over the field commitments" } Requirements: 1. A field commitment MUST be SHA-256 over the concatenation of a per-field salt, the JSON Pointer [RFC6901] path of the field, and the canonical serialization of its value. Including the path prevents a disclosed value from being replayed against a different field. 2. Salts MUST be at least 128 bits, generated by a cryptographically secure source, and unique per field per record. A shared salt restores the oracle it was meant to remove. 3. Salts MUST NOT appear in the published record. Reilly Expires 9 March 2027 [Page 22] Internet-Draft WebProof Provenance Protocol September 2026 4. The root MUST be a Merkle tree hash over the ordered field commitments per [RFC9162], and it is the root, not the individual commitments, that is anchored and deposited. 5. A commitment-mode WPR MUST set commitment_mode to true at the top level, so that a verifier does not read an absent hash as a malformed record. Disclosure to a specific verifier takes the form: "disclosure": { "wpr_id": "urn:webproof:wpr:UUID", "root": "hex Merkle root", "revealed": [ { "path": "/integrity/hash", "salt": "base64url salt", "value": "the field value", "inclusion_proof": ["hex", "hex"] } ] } A verifier MUST recompute the field commitment from salt, path, and value, MUST verify the inclusion proof against an independently retrieved anchored root, and MUST reject the disclosure if either check fails. Commitment mode changes what the record proves, and implementers should be clear about the change. An anchored commitment-mode WPR proves that a specific resource state existed at a specific time. It does not make that state public. Section 12.3 explains why this distinction is what allows a permanent record to coexist with an erasure obligation. 4.9. Status Records Section 12 of draft-reilly-webproof-00 observes that a DOI-archived WPR cannot be retracted from archival systems. That is the intended behavior of an archive and the correct one. It leaves an unaddressed case: a WPR issued in error, issued for the wrong resource, or issued under a key later found compromised remains permanently retrievable and permanently plausible. A publisher SHOULD therefore be able to say something further about a record it cannot unsay. A Status Record does that: "status_record": { Reilly Expires 9 March 2027 [Page 23] Internet-Draft WebProof Provenance Protocol September 2026 "subject_wpr_id": "urn:webproof:wpr:UUID", "subject_record_digest": "hex", "status": "withdrawn", "reason": "key_compromise", "effective_at": "2026-09-05T00:00:00Z", "superseded_by": "urn:webproof:wpr:UUID-NEW", "issued_at": "2026-09-05T00:05:00Z", "signature": { "format": "COSE_Sign1", "value": "base64url" } } Requirements: 1. status MUST be one of "superseded", "corrected", or "withdrawn". 2. reason MUST be one of "key_compromise", "erroneous_issue", "resource_removed", "policy_withdrawal", or "administrative". 3. A Status Record MUST be signed per Section 4.6 and SHOULD be anchored and deposited by the same procedure as a WPR, so that the withdrawal carries the same tamper-evidence as the thing withdrawn. An unanchored withdrawal can itself be withdrawn silently. 4. A Status Record MUST NOT delete or replace the subject WPR. The record remains; its status changes. 5. Status Records SHOULD be served from the domain-level registry of Section 7.2, and a verifier SHOULD consult that registry before reporting VERIFIED. 6. Where reason is "key_compromise", a verifier MUST treat every WPR signed by the affected key after effective_at as unverified, and SHOULD flag those signed before it for review. 7. A publisher MUST NOT issue a Status Record for a WPR it did not issue. A verifier MUST reject a Status Record whose signature does not chain to the key that signed the subject. 5. WebProof Generation Procedure A WebProof is generated through five sequential steps. Each step MUST be completed before proceeding to the next. Steps 3 and 4 MAY be performed in parallel after Step 2. Reilly Expires 9 March 2027 [Page 24] Internet-Draft WebProof Provenance Protocol September 2026 5.1. Step 1: Resource Canonicalization The web resource MUST be reduced to a canonical byte sequence before hashing. Canonicalization removes incidental variation that does not affect the meaningful content of the resource, ensuring that two representations of semantically identical content produce the same hash. For text/html resources: Extract the body text content. Remove all HTML markup. Normalize whitespace (collapse runs of whitespace to single spaces, trim leading and trailing whitespace). Encode as UTF-8. For application/json resources: Apply JSON Canonicalization Scheme [RFC8785]. Encode as UTF-8. For application/pdf resources: Extract text layer. Normalize whitespace. Encode as UTF-8. For binary resources (images, video, audio, datasets): Use the raw byte sequence without modification. For text/* resources not otherwise specified: Normalize line endings to LF. Trim trailing whitespace per line. Encode as UTF-8. Publishers MUST document the canonicalization applied in the resource.canonical_form_description field of the WPR to enable independent verification. 5.1.1. Canonicalization Profiles Canonicalization is the step on which every other guarantee in this document rests. If a verifier's canonical form differs from the publisher's by a single byte, the digests differ completely, Section 6 Step 5 fails, and a correct resource is reported MODIFIED. The failure is silent in the sense that matters: it looks exactly like tampering. The prose in Section 5.1 does not determine a byte sequence. "Extract the body text content" leaves open whether alt text, title attributes, table cell ordering, and content inside