Proof of Process (PoP): Architecture, Evidence Format, and VDF

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 18 August 2026.¶

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

The rapid proliferation of generative artificial intelligence has created an authenticity crisis in digital discourse. While traditional provenance tracks the "custody of pixels," it fails to attest to the human-driven process of creation. This document specifies the Proof of Process (PoP) protocol, which extends the RATS architecture [RFC9334] to validate the "provenance of effort."¶

2. Core Principles

The PoP framework is built upon five foundational pillars:¶

• Physics-based Cost: Using memory-hard sequential functions (Argon2id) to establish an economic lower bound on forgery.¶
• Physical Freshness: Anchoring sessions to non-deterministic physical markers (e.g., thermal noise) to prevent replay.¶
• Biological Binding: Entangling human motor-signal jitter as a non-deterministic seed for cryptographic proofs generated within the Attesting Environment (AE).¶
• Out-of-Band Presence: Utilizing secondary physical devices (e.g., smartphone QR scans) to bridge the digital-physical gap.¶
• Asymmetric Verification: Ensuring that complex, long-duration proofs can be verified efficiently by third parties.¶

3. RATS Role Mapping

Attester:

The writing environment (e.g., a text editor or OS service) that captures behavioral events and generates PoP Evidence packets (.pop).¶

Verifier:

A trusted entity that appraises PoP Evidence and issues a Writers Authenticity Report (WAR).¶

Relying Party:

An end-user or system that consumes the WAR to make a trust decision.¶

4. Attester State Machine

To ensure protocol robustness, the Attesting Environment (AE) MUST implement a formal state machine:¶

• RECORDING: AE captures semantic events and physical telemetry into a hash-linked buffer.¶
• PENDING_CHECK: The event block is frozen to initiate a VDF proof.¶
• CHECKPOINT: AE computes the VDF and weaves the entangled seed into the chain.¶
• SEALING: The final transcript root is signed by the hardware Secure Element.¶

5. Evidence Content Tiers and Assurance Levels

PoP Evidence is classified by both content depth (CORE, ENHANCED, MAXIMUM) and attestation assurance strength (T1-T4):¶

6. Evidence Format and CDDL

Evidence Packets are identified by the semantic CBOR tag 1347571280.¶

evidence-packet = {
    1 => uint,                              ; version
    2 => tstr,                              ; profile-uri
    3 => uuid,                              ; packet-id
    4 => pop-timestamp,                     ; created
    5 => document-ref,                      ; document
    6 => [+ checkpoint],                    ; checkpoints
    ? 7 => attestation-tier,                ; T1-T4 assurance level
    ? 8 => [* tstr],                        ; attestation-limitations
    ? 10 => [+ presence-challenge],         ; QR/OOB presence proofs
    ? 18 => physical-liveness-section,      ; CDCE markers
}

checkpoint = {
    1 => uint,                              ; sequence (strictly monotonic)
    2 => uuid,                              ; checkpoint-id
    4 => hash-value,                        ; content-hash
    9 => process-proof,                     ; process-proof (VDF)
    10 => jitter-binding,                   ; behavioral-entropy
    11 => physical-state,                   ; Thermal/Entropy Weave
    12 => bstr .size 32,                    ; entangled-mac (HMAC-SHA256)
}

document-ref = {
    1 => hash-value,                        ; content-hash
    3 => uint,                              ; byte-length
    ? 5 => hash-salt-mode,                  ; 0=unsalted, 1=author-salted
    ? 6 => bstr,                            ; salt-commitment
}

7. VDF and Temporal Proofs

Implementations MUST support Argon2id [RFC9106] as the MTI memory-hard function.¶

  hat-seed = H(tpm-counter || physical-freshness || document-hash)

8. IANA Considerations

This document requests registration of CBOR tags 1347571280 ("PPP ") and 1463894560 ("WAR "), and the EAT profile urn:ietf:params:rats:eat:profile:pop:1.0.¶

9. Security Considerations

The primary security goal is to provide tamper-evident records of document evolution. Implementations MUST validate all CDDL constraints and ensure checkpoint sequence monotonicity.¶

Author's Address