<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
     version="3"
     docName="draft-condrey-rats-pop-appraisal-03"
     ipr="trust200902"
     category="exp"
     consensus="false"
     submissionType="IETF"
     sortRefs="true"
     symRefs="true"
     tocInclude="true"
     tocDepth="4">

  <front>
    <title abbrev="PoP Appraisal">Proof of Process (PoP): Forensic Appraisal and Security Model</title>
    <seriesInfo name="Internet-Draft" value="draft-condrey-rats-pop-appraisal-03"/>
    <author fullname="David Condrey" initials="D." surname="Condrey">
      <organization abbrev="WritersLogic">WritersLogic Inc</organization>
      <address>
        <postal>
          <city>San Diego, California</city>
          <country>United States</country>
        </postal>
        <email>david@writerslogic.com</email>
      </address>
    </author>
    <date year="2026" month="February" day="16"/>

    <area>Security</area>
    <workgroup>Remote ATtestation procedureS</workgroup>

    <keyword>attestation</keyword>
    <keyword>forensics</keyword>
    <keyword>biometrics</keyword>
    <keyword>security economics</keyword>

    <abstract>
      <t>
        This document specifies the forensic appraisal methodology and quantitative security model for the Proof of Process (PoP) framework. It defines how Verifiers evaluate behavioral entropy, perform liveness detection, and calculate forgery cost bounds. Additionally, it establishes the taxonomy for Absence Proofs and the Tool Receipt protocol for AI attribution within the linear human authoring process.
      </t>
    </abstract>
  </front>

  <middle>
    <section anchor="introduction">
      <name>Introduction</name>
      <t>
        The value of Proof of Process (PoP) evidence lies in the Verifier's ability to distinguish biological effort from algorithmic simulation. While traditional RATS <xref target="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).
      </t>
    </section>

    <section anchor="requirements-language">
      <name>Requirements Language</name>
      <t>
        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 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and
        only when, they appear in all capitals, as shown here.
      </t>
    </section>

    <section anchor="verification-procedure">
      <name>Step-by-Step Verification Procedure</name>
      <t>
        A Verifier MUST perform the following procedure to appraise a PoP Evidence Packet:
      </t>
      <ol>
        <li><strong>Chain Integrity:</strong> Verify the SHA-256 hash link between all checkpoints. Any break invalidates the subsequent chain.</li>
        <li><strong>Temporal Order:</strong> 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.</li>
        <li><strong>Entropy Threshold:</strong> 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."</li>
        <li><strong>Entanglement:</strong> Verify the HMAC signature (entangled-mac) over the combined document, jitter, and physical state.</li>
        <li><strong>State Matching:</strong> Reconstruct the document from the semantic event transcript and verify the final hash matches the document-ref.</li>
      </ol>
    </section>

    <section anchor="forensic-assessment">
      <name>Forensic Assessment Mechanisms</name>
      <t>
        The appraisal logic is designed to detect "Synthetic Authoring" -- content generated by AI and subsequently "back-filled" with timing and hardware attestation.
      </t>
      <dl spacing="normal">
        <dt>SNR (Signal-to-Noise Ratio) Analysis:</dt>
        <dd>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 <xref target="Monrose2000"/> that are computationally expensive to simulate realistically.</dd>
        
        <dt>Cognitive Load Correlation (CLC):</dt>
        <dd>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."</dd>

        <dt>Mechanical Turk Detection:</dt>
        <dd>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.</dd>

        <dt>Error Topology Analysis:</dt>
        <dd>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.</dd>

        <dt>QR Presence Challenge (OOB-PC):</dt>
        <dd>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.</dd>
      </dl>
    </section>

    <section anchor="economic-model">
      <name>Forgery Cost Bounds (Quantified Security)</name>
      <t>
        Forgery cost bounds provide a Verifier with a lower bound on the computational resources required to forge an Evidence Packet. The cost (<em>C_total</em>) is computed as:
      </t>
      <artwork><![CDATA[
  C_total = C_swf + C_entropy + C_hardware
      ]]></artwork>
      <ul>
        <li><strong>C_swf:</strong> 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.</li>
        <li><strong>C_entropy:</strong> An estimate of the compute resources required to synthesize biological noise that satisfies SNR, CLC, and Topology constraints via high-fidelity AI modeling.</li>
        <li><strong>C_hardware:</strong> Pro-rated cost of discrete TPMs or high-bandwidth DRAM interfaces (HBM3) required for MHSF acceleration.</li>
      </ul>
      <t>
        Verifiers MUST include these estimates in the WAR to allow Relying Parties to set trust thresholds based on objective economic risk.
      </t>
    </section>

    <section anchor="absence-proofs">
      <name>Absence Proofs: Negative Evidence Taxonomy</name>
      <t>
        Absence proofs assert that certain events did NOT occur during the monitored session. They are divided into categories based on verifiability:
      </t>
      <dl>
        <dt>Type 1: Computationally-Bound Claims</dt>
        <dd>Verifiable from the Evidence Packet alone (e.g., "Max single delta size &lt; 500 bytes" or "No checkpoint timestamps out of order").</dd>
        <dt>Type 2: Monitoring-Dependent Claims</dt>
        <dd>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).</dd>
        <dt>Type 3: Environmental Claims</dt>
        <dd>Assertions about the execution environment (e.g., "No debugger attached" or "Hardware temperature remained within stable physical bounds").</dd>
      </dl>
    </section>

    <section anchor="tool-receipt-protocol">
      <name>Tool Receipt Protocol (AI Attribution)</name>
      <t>
        When external tools (LLMs) contribute content, the framework enables a "compositional provenance" model:
      </t>
      <ol>
        <li><strong>Receipt Signing:</strong> 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).</li>
        <li><strong>Binding:</strong> The human Attester records a PASTE event in the transcript referencing the Tool Receipt's output_commit.</li>
        <li><strong>Countersigning:</strong> The Attester binds the Receipt into the next human-driven checkpoint, anchoring the automated work into the linear human effort.</li>
      </ol>
      <t>
        Verifiers appraise the ratio of human-to-machine effort based on these receipts and the intervening SWF-proved intervals.
      </t>
      <t>
        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.
      </t>
    </section>

    <section anchor="adversary-model">
      <name>Adversary Model</name>
      <t>
        This document inherits the adversary model defined in Section 4 of <xref target="PoP-Protocol"/>. The appraisal procedures defined herein assume the adversarial Attester capabilities and constraints specified there.
      </t>
      <t>
        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 <xref target="forensic-assessment"/> are specifically designed to detect the Retype Attack and other forgery vectors described in the protocol specification's threat model.
      </t>
    </section>

    <section anchor="privacy-and-accessibility">
      <name>Privacy and Inclusivity</name>
      <section anchor="privacy">
        <name>Privacy Considerations and Evidence Quantization</name>
        <t>
          High-resolution behavioral data poses a stylometric de-anonymization risk <xref target="Goodman2007"/>. Implementations SHOULD support Evidence Quantization, reducing timing resolution to a level that maintains forensic confidence (detecting robots) while breaking unique author fingerprints.
        </t>
      </section>
      <section anchor="accessibility">
        <name>Accessibility and Assistive Modes</name>
        <t>
          Verifiers MUST NOT automatically reject evidence based solely on atypical timing patterns. Implementations MUST support "Assistive Modes" that adjust SNR and CLC thresholds for authors with motor disabilities or those using assistive technologies (eye-tracking, dictation).
        </t>
        <t>
          To signal assistive mode usage, the Attester SHOULD include an assistive-mode indicator in the profile-declaration structure of the Evidence Packet. When this indicator is present, Verifiers MUST apply adjusted thresholds as follows:
        </t>
        <ul>
          <li>SNR threshold: Reduced by 50% (accepting higher periodicity in motor signals)</li>
          <li>CLC correlation threshold: r &gt; 0.1 (reduced from r &gt; 0.2)</li>
          <li>Error topology: Waived for dictation modes; adjusted for eye-tracking</li>
        </ul>
        <t>
          The WAR MUST indicate when assistive mode thresholds were applied. The specific CDDL extension for assistive-mode signaling will be defined in a future revision of <xref target="PoP-Protocol"/>.
        </t>
      </section>
    </section>

    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>
        This document has no IANA actions. All IANA registrations for the PoP framework are defined in <xref target="PoP-Protocol"/>.
      </t>
    </section>

    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>
        This document defines forensic appraisal procedures that inherit and extend the security model from <xref target="PoP-Protocol"/>. The broader RATS security considerations <xref target="Sardar-RATS"/> also apply. Implementers MUST consider the following security aspects:
      </t>
      <section anchor="sec-entropy-manipulation">
        <name>Entropy Manipulation Attacks</name>
        <t>
          An adversary may attempt to inject synthetic jitter patterns that satisfy entropy thresholds while lacking biological origin. Verifiers MUST employ multi-dimensional analysis (SNR, CLC, Error Topology) rather than relying on single metrics. The correlation between semantic content complexity and timing variation provides defense-in-depth against high-fidelity simulation.
        </t>
      </section>
      <section anchor="sec-verifier-trust">
        <name>Verifier Trust Model</name>
        <t>
          The forensic assessments defined in this document produce probabilistic confidence scores, not binary determinations. Relying Parties MUST understand that forgery cost bounds represent economic estimates, not cryptographic guarantees. Trust decisions SHOULD incorporate the declared Attestation Tier (T1-T4) and the specific absence proof types claimed.
        </t>
      </section>
      <section anchor="sec-stylometric-risk">
        <name>Stylometric De-anonymization</name>
        <t>
          High-resolution behavioral data (keystroke timing, pause patterns) can enable author identification even when document content is not disclosed. Implementations SHOULD support Evidence Quantization to reduce timing resolution while maintaining forensic utility. The trade-off between forensic confidence and privacy MUST be documented for Relying Parties.
        </t>
      </section>
      <section anchor="sec-assistive-bypass">
        <name>Assistive Mode Abuse</name>
        <t>
          Adversaries may falsely claim assistive technology usage to bypass behavioral entropy checks. Verifiers SHOULD require consistent assistive mode declarations across sessions and MAY request additional out-of-band verification for mode changes. The WAR MUST clearly indicate when assistive modes were active.
        </t>
      </section>
    </section>
  </middle>

  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9334.xml"/>
      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="PoP-Protocol">
          <front>
            <title>Proof of Process (PoP): Architecture and Evidence Format</title>
            <author fullname="David Condrey" initials="D." surname="Condrey"/>
            <date year="2026"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-condrey-rats-pop-protocol-04"/>
        </reference>
        <reference anchor="Monrose2000" target="https://doi.org/10.1145/351427.351438">
          <front>
            <title>Keystroke dynamics as a biometric for authentication</title>
            <author fullname="F. Monrose" initials="F." surname="Monrose"/>
            <author fullname="A. Rubin" initials="A." surname="Rubin"/>
            <date year="2000"/>
          </front>
        </reference>
        <reference anchor="Goodman2007" target="https://doi.org/10.1007/978-3-540-77343-6_14">
          <front>
            <title>Using Stylometry for Biometric Keystroke Dynamics</title>
            <author fullname="A. Goodman" initials="A." surname="Goodman"/>
            <author fullname="V. Zabala" initials="V." surname="Zabala"/>
            <date year="2007"/>
          </front>
        </reference>
        <reference anchor="Sardar-RATS" target="https://datatracker.ietf.org/doc/html/draft-sardar-rats-sec-cons-02">
          <front>
            <title>Security Considerations for Remote ATtestation procedureS (RATS)</title>
            <author fullname="Muhammad Usama Sardar" initials="M.U." surname="Sardar"/>
            <date year="2026" month="February"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-sardar-rats-sec-cons-02"/>
        </reference>
      </references>
    </references>

    <section anchor="verification-checklist" numbered="false">
      <name>Appendix A: Verification Constraint Summary</name>
      <t>
        The following constraints MUST be verified by conforming Verifiers:
      </t>
      <section anchor="structural-checks" numbered="false">
        <name>A.1 Structural Integrity</name>
        <ol>
          <li>Chain Integrity: SHA-256 hash chain is unbroken from genesis to final checkpoint.</li>
          <li>Temporal Monotonicity: All checkpoint timestamps strictly exceed their predecessors.</li>
          <li>SWF Continuity: Recompute Argon2id from seed; verify sampled Merkle proofs.</li>
          <li>Content Binding: Final document hash matches document-ref in Evidence Packet.</li>
        </ol>
      </section>
      <section anchor="behavioral-checks" numbered="false">
        <name>A.2 Behavioral Analysis (ENHANCED/MAXIMUM profiles)</name>
        <ol>
          <li>Entropy Threshold: jitter-binding.entropy-estimate >= 128 bits per segment.</li>
          <li>SNR Analysis: Jitter exhibits 1/f fractal noise, not periodic or "perfect" patterns.</li>
          <li>CLC Correlation: Semantic complexity correlates with timing (r > 0.2, or r > 0.1 for assistive mode).</li>
          <li>Error Topology: Correction patterns consistent with human cognitive processing.</li>
          <li>Mechanical Turk Detection: No robotic pacing (machine-clocked editing rate).</li>
        </ol>
      </section>
      <section anchor="absence-checks" numbered="false">
        <name>A.3 Absence Proof Validation</name>
        <ol>
          <li>Type 1 Claims: Verify computationally from Evidence Packet (delta sizes, timestamp ordering).</li>
          <li>Type 2 Claims: Weight by Attestation Tier (T1-T4).</li>
          <li>Type 3 Claims: Evaluate environmental assertions against physical-state markers.</li>
        </ol>
      </section>
      <section anchor="tool-receipt-checks" numbered="false">
        <name>A.4 Tool Receipt Validation (when present)</name>
        <ol>
          <li>Verify Tool signature over Receipt.</li>
          <li>Verify PASTE event references correct output_commit.</li>
          <li>Calculate human-to-machine effort ratio from SWF-proved intervals.</li>
        </ol>
      </section>
    </section>
  </back>
</rfc>