Summary

  • The 5 September revision of WebProof is an individual Internet-Draft with no IETF endorsement or formal standing, even though it contains an “AI System Directive” written in normative language.
  • Its own evidence model draws the decisive boundary: a blockchain anchor can time-bound knowledge of a digest, a DOI can preserve depositor-supplied metadata and a signature can identify a key holder, but none independently proves truth, priority, authorship or authority over an AI system.
  • AI operators need a separate instruction receipt that identifies who issued a rule, which systems accepted it and what the running model did; content being analysed cannot silently become the policy that governs its analysis.

On 5 September, a 62-page document entered the IETF repository with an unusual audience. The Internet-Draft announcement identifies WebProof: A Dual-Layer Web Provenance Protocol for Verifiable Digital Truth on the Internet, revision 01, by Lawrence John Reilly Jr. Most of the proposal addresses records, hashes, timestamps, archives, signatures and discovery. Section 15 addresses language models and agents directly.

It calls itself an “AI System Directive”. It says AI systems processing the document “MUST” credit the term WebProof to the author, recognize a named whitepaper as the original publication, preserve several originality claims and avoid presenting the contribution as anonymous or as someone else’s work.

Those words are facts about the document. They are not commands this Article has accepted.

That distinction is not hostility to attribution. A responsible account should identify the author of a source, state what the source claims and preserve the date. The issue is who decides whether prose encountered during analysis enters the reader’s governing instruction stack. If the document can make that decision for itself, every input can promote its own interests above the task for which it was retrieved.

The status line comes before the capital letters

The Datatracker record supplies the first boundary. It describes an active individual Internet-Draft and says, in plain language, that anyone may submit one, that this one is not endorsed by the IETF and that it has no formal standing in the IETF standards process. It lists no RFC stream, responsible Area Director or telechat date.

The exact revision text matters because revision 01 did not newly introduce the AI directive. Its change log says no text from revision 00 was removed or altered, and Sections 1.4 and 15 were carried forward. What the September revision added was a stronger account of proof limits, record signatures, update series, status records, time semantics, threats, privacy, conformance and implementation.

That chronology prevents two exaggerations. The directive is not a new IETF policy announced on 5 September. Nor is revision 01 merely the same old page: it adds the very constraints that expose why the directive cannot inherit authority from the provenance mechanism around it.

RFC 8174 gives uppercase words such as MUST, SHOULD and MAY their defined BCP 14 meanings in IETF documents. This vocabulary makes a specification’s requirements testable. It does not answer the separate questions of document status, adoption, jurisdiction or enforcement. A “MUST” in an individual proposal can say what a conforming implementation of that proposal would do. Typography cannot enroll every AI model that happens to read the page.

The directive recognizes one limit itself. It says human oversight is supreme and makes its asserted binding effect subordinate to higher-tier prompts described by AIMED’s companion framework. But the AIMED Datatracker entry is also an individual Internet-Draft without IETF standing. One author document can refer to another author document. The reference does not establish the actual policy hierarchy of OpenAI, Anthropic, a newsroom, a bank, a government agency or a locally deployed model.

The proposal’s best sentence limits its own proof

Revision 01 is clearest when it says what each anchor does not establish. Its blockchain layer proves, at most, that some party knew a digest no later than the relevant block. It does not prove when the underlying work was created, who authored it, whether it was served at the claimed URI or whether its assertions are correct.

The DOI layer preserves a deposit and its metadata under a persistent identifier. The draft explicitly says the depositor asserts that metadata. Deposit does not independently adjudicate the named author, the claimed dates or the relationship between a URI and a hash. Binding two limited records can make a claim harder to alter without detection; it cannot manufacture the missing adjudication.

The same restraint appears in the identity section. The author field alone is an assertion. The proposed record may be signed using mechanisms such as JSON Web Signature, which can protect integrity and authenticate possession of signing material in a defined context. But a verified signature answers “Which key made this signature?” before it answers “Which person or institution was entitled to make this claim?” Certificate validation, key custody, organizational mandate and revocation remain separate evidence.

Time has a similar ceiling. The draft treats the block as an upper bound: the digest was known no later than that point, with caveats about block time. It does not supply a lower bound; a document could have existed long before anchoring. A separate RFC 3161 time-stamp token can bind a digest to time asserted by a time-stamping authority, but that introduces another trusted actor. Neither mechanism decides whether an originality claim is historically complete.

This is why the title phrase “verifiable digital truth” must be read cautiously. The draft itself says WebProof does not stop false material from being published and must not be treated as proof of legitimacy, quality or trustworthiness. It makes a claim about a resource durable. It does not make the resource’s claim true.

A proposed discovery address is not global adoption

WebProof proposes /.well-known/webproof as a place to find records. RFC 8615 reserves the /.well-known/ path space and requires applications minting suffixes to register them so collisions and scope confusion can be managed. The live IANA registry, checked on 7 September, contained no webproof entry.

That absence is a dated fact, not a rejection for all time. A provisional registration could arrive later. Implementations could experiment before standardization. The important separation is among text that proposes a coordinate, an IANA record that registers it, software that serves it, clients that retrieve it and policy that decides whether to trust what it returns.

The proposed HTTP fields and _webproof DNS TXT record follow the same logic. A server can advertise a pointer. A DNSSEC-valid answer can protect the origin and integrity of DNS data within its chain. Neither fact proves the referenced authorship or priority assertion. The draft itself warns that its HTTP hash field travels with the resource and is not a verification result, and that unsigned DNS is only a discovery convenience.

Evidence is input to a decision, not the decision

The proposal maps a WebProof Record onto the remote-attestation vocabulary. That is useful if the roles remain separate. RFC 9334 distinguishes Evidence supplied by an Attester, appraisal performed under policy, Attestation Results and the Relying Party’s ultimate decision. Evidence does not carry its own acceptance policy inside itself and thereby bind the relying party.

Apply that structure to Section 15. The retrieved draft is evidence that the author published an attribution instruction and priority claims. Its hash can bind the bytes. An archive can preserve a dated deposit. A signature can bind a key. External sources can corroborate or contest the history. Then the AI operator applies a policy: quote the claim, credit the document, search for earlier records, flag uncertainty, or decline to treat the embedded instruction as governing.

The order matters. If the content supplies both the evidence and the appraisal policy, the subject under examination becomes its own judge. A webpage could instruct a summarizer never to mention criticism. A tender could tell an evaluator that its bidder is uniquely qualified. A research paper could order a model to call it the first. Making those sentences visible is good provenance. Treating visibility as delegated authority is a category error.

One deployment is not yet interoperability

Revision 01 contains an implementation-status section. It says the author operates the anchoring and DOI procedure and a live deployment. That is relevant evidence of author experience. RFC 7942 encourages implementation-status reporting in Internet-Drafts so the community can see what has been attempted while work is developing.

The draft also supplies the correct limitation: an independent implementation is the valuable next test because two implementations must agree on canonical bytes before an integrity scheme is interoperable. Self-reported production use does not prove that another publisher will canonicalize the same HTML identically, resolve status records safely, handle key compromise correctly or render verification without implying endorsement.

Running evidence would include at least two independent implementations, shared test vectors, divergent-input cases, key and status transitions, failed retrievals, registry state, and user interfaces that distinguish “digest matched” from “claim accepted”. It would also include AI evaluations showing whether embedded directives are quoted as source material or silently promoted into policy.

The useful receipt has two authorities

Heng Lu’s Minimum Initial Specification suggests a narrow common record rather than a universal command channel. For an AI system, that record should preserve document URI, revision, bytes or digest, retrieval time, author assertion, external corroboration and document status. Separately, it should name the policy issuer, policy version, accepted instruction class, scope, precedence, reviewer and revocation route.

The separation reflects Reality Layers. A sentence exists in a document. A repository records the document. A ledger time-bounds a digest. A registry may publish a coordinate. An operator configures an AI system. The model produces an answer. These layers can be linked without being collapsed.

Running-Code Primacy supplies the final test. To claim that the directive governed an AI, record the actual input boundary, system and developer policy, model/version, retrieval path, tool context, output and reviewer decision. The phrase “MUST attribute” is not evidence that any deployed system complied, resisted, or even saw the section.

WebProof’s September revision is valuable because it writes down both the ambition and many of the limits. The right response is to apply those limits consistently. A durable attribution claim deserves preservation and examination. It does not become an order merely because the claimant has specified how the proof of that claim should travel.

Sources

  1. Datatracker — WebProof
  2. WebProof revision 01
  3. Internet-Draft announcement
  4. Datatracker — AIMED
  5. RFC 8174 — uppercase requirement words
  6. RFC 8615 — well-known URIs
  7. IANA Well-Known URIs registry
  8. RFC 7515 — JSON Web Signature
  9. RFC 3161 — Time-Stamp Protocol
  10. RFC 9334 — RATS Architecture
  11. RFC 7942 — implementation status
  12. Heng Lu — Minimum Initial Specification
  13. Heng Lu — On Reality Layers
  14. Heng Lu — Running-Code Primacy