Proof of Process (PoP): Forensic Appraisal and Security Model

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 20 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 value of Proof of Process (PoP) evidence lies in the Verifier's ability to distinguish biological effort from algorithmic simulation. While traditional RATS [RFC9334] appraisals verify system state, PoP appraisal verifies a continuous physical process. This document provides the normative framework for forensic appraisal, defining the logic required to generate a Writers Authenticity Report (WAR).¶

2. Requirements Language

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.¶

3. Step-by-Step Verification Procedure

A Verifier MUST perform the following procedure to appraise a PoP Evidence Packet:¶

1. Chain Integrity: Verify the SHA-256 hash link between all checkpoints. Any break invalidates the subsequent chain.¶
2. Temporal Order: For each process-proof, recompute Argon2id from the declared seed to obtain state_0, then verify sampled Merkle proofs against the committed root. Ensure claimed duration is consistent with SWF difficulty parameters.¶
3. Entropy Threshold: Verify that the entropy-estimate field in each jitter-binding structure meets or exceeds 128 bits. Low-entropy segments (below threshold) MUST be flagged as "Non-Biological."¶
4. Entanglement: Verify the HMAC signature (entangled-mac) over the combined document, jitter, and physical state.¶
5. State Matching: Reconstruct the document from the semantic event transcript and verify the final hash matches the document-ref.¶

4. Forensic Assessment Mechanisms

The appraisal logic is designed to detect "Synthetic Authoring" -- content generated by AI and subsequently "back-filled" with timing and hardware attestation.¶

SNR (Signal-to-Noise Ratio) Analysis:

Verifiers MUST evaluate the stochasticity of jitter. High-precision robotic injection often exhibits "perfect" noise or periodic patterns. Human motor signals exhibit 1/f fractal noise signatures [Monrose2000] that are computationally expensive to simulate realistically.¶

Cognitive Load Correlation (CLC):

To defeat high-fidelity AI jitter models, Verifiers MUST correlate timing patterns with semantic complexity. Human authors exhibit increased inter-keystroke intervals (IKI) and pause frequency during the composition of high-entropy segments (e.g., technical definitions) compared to low-entropy segments (e.g., common connectors). A simulation that maintains a constant biological signature regardless of content complexity MUST be flagged as a "Semantic Mismatch."¶

Mechanical Turk Detection:

Analyzes intra-checkpoint correlation (C_intra) to detect "robotic pacing" -- where an automated system maintains a machine-clocked editing rate. Statistical correlation between pause duration and subsequent edit complexity is a mandatory check.¶

Error Topology Analysis:

Human authors exhibit characteristic patterns: Localized corrections near recent insertions, fractal self-similarity in revision patterns across different time scales, and a specific ratio of deletions to new content consistent with human cognitive processing.¶

QR Presence Challenge (OOB-PC):

To bridge the digital-physical gap, the Attester MAY issue an Out-of-Band Presence Challenge. A non-deterministic QR code is displayed on the primary screen, which the author MUST scan with a registered secondary device (e.g., smartphone). The secondary device signs the challenge with its own hardware-bound key. Verifiers MUST verify the wall-clock alignment of this OOB signature within the checkpoint chain.¶

5. Forgery Cost Bounds (Quantified Security)

Forgery cost bounds provide a Verifier with a lower bound on the computational resources required to forge an Evidence Packet. The cost (C_total) is computed as:¶

  C_total = C_swf + C_entropy + C_hardware

• C_swf: Iterations * Joules per iteration * Energy Cost. The memory-hard nature of Argon2id ensures that the wall-clock duration proved cannot be significantly compressed by parallel compute.¶
• C_entropy: An estimate of the compute resources required to synthesize biological noise that satisfies SNR, CLC, and Topology constraints via high-fidelity AI modeling.¶
• C_hardware: Pro-rated cost of discrete TPMs or high-bandwidth DRAM interfaces (HBM3) required for MHSF acceleration.¶

Verifiers MUST include these estimates in the WAR to allow Relying Parties to set trust thresholds based on objective economic risk.¶

6. Absence Proofs: Negative Evidence Taxonomy

Absence proofs assert that certain events did NOT occur during the monitored session. They are divided into categories based on verifiability:¶

Type 1: Computationally-Bound Claims

Verifiable from the Evidence Packet alone (e.g., "Max single delta size < 500 bytes" or "No checkpoint timestamps out of order").¶

Type 2: Monitoring-Dependent Claims

Require trust in the AE's event monitoring (e.g., "No paste from unauthorized AI tool" or "No clipboard activity detected"). Trust in these claims MUST be weighted by the declared Attestation Tier (T1-T4).¶

Type 3: Environmental Claims

Assertions about the execution environment (e.g., "No debugger attached" or "Hardware temperature remained within stable physical bounds").¶

7. Tool Receipt Protocol (AI Attribution)

When external tools (LLMs) contribute content, the framework enables a "compositional provenance" model:¶

1. Receipt Signing: The Tool signs a "Receipt" containing its tool_id, an output_commit (SHA-256 hash of generated text), and an optional input_ref (SHA-256 hash of the prompt).¶
2. Binding: The human Attester records a PASTE event in the transcript referencing the Tool Receipt's output_commit.¶
3. Countersigning: The Attester binds the Receipt into the next human-driven checkpoint, anchoring the automated work into the linear human effort.¶

Verifiers appraise the ratio of human-to-machine effort based on these receipts and the intervening SWF-proved intervals.¶

NOTE: The complete CDDL wire format for Tool Receipts, including signature algorithms and binding mechanisms, will be specified in a future revision of this document or a separate companion specification. Implementations SHOULD treat this section as informative guidance until normative wire formats are defined.¶

8. Adversary Model

This document inherits the adversary model defined in Section 4 of [PoP-Protocol]. The appraisal procedures defined herein assume the adversarial Attester capabilities and constraints specified there.¶

The primary threat is an adversarial Attester -- an author who controls the Attesting Environment and seeks to generate Evidence for content they did not authentically author. The forensic assessment mechanisms in Section 4 are specifically designed to detect the Retype Attack and other forgery vectors described in the protocol specification's threat model.¶

9. Privacy and Inclusivity

10. IANA Considerations

This document has no IANA actions. All IANA registrations for the PoP framework are defined in [PoP-Protocol].¶

11. Security Considerations

This document defines forensic appraisal procedures that inherit and extend the security model from [PoP-Protocol]. The broader RATS security considerations [Sardar-RATS] also apply. Implementers MUST consider the following security aspects:¶

Appendix A: Verification Constraint Summary

The following constraints MUST be verified by conforming Verifiers:¶

Author's Address