<?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-protocol-04"
     ipr="trust200902"
     category="exp"
     consensus="false"
     submissionType="IETF"
     sortRefs="true"
     symRefs="true"
     tocInclude="true"
     tocDepth="4">

  <front>
    <title abbrev="PoP Protocol">Proof of Process (PoP): Architecture and Evidence Format</title>
    <seriesInfo name="Internet-Draft" value="draft-condrey-rats-pop-protocol-04"/>
    <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>RATS</keyword>
    <keyword>provenance</keyword>
    <keyword>authorship</keyword>

    <abstract>
      <t>
        This document specifies the Proof of Process (PoP) Evidence Framework, a specialized profile of Remote Attestation Procedures (RATS) designed to validate the provenance of effort in digital authorship. Unlike traditional provenance, which tracks file custody, PoP attests to the continuous physical process of creation.
      </t>
      <t>
        The protocol defines a cryptographic mechanism for generating Evidence Packets utilizing a composite Sequential Work Function (SWF) to enforce temporal monotonicity and Cross-Domain Constraint Entanglement (CDCE) to bind behavioral entropy (human jitter) and physical state to the document. Technical specifications for wire formats, sequential work functions, and hardware-anchored trust are provided.
      </t>
    </abstract>
  </front>

  <middle>
    <section anchor="introduction">
      <name>Introduction</name>
      <t>
        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 <xref target="RFC9334"/> to validate the "provenance of effort."
      </t>
      <t>
        Unlike traditional attestation which captures static system state, PoP attests to a continuous physical process. It introduces Proof of Biological Space-Time (PoBST) to enforce temporal monotonicity and Cross-Domain Constraint Entanglement (CDCE) to bind behavioral entropy (human jitter) and physical state (thermodynamics) to the document's evolution.
      </t>
      <t>
        By entangling content hashes with these physical constraints, this protocol enables an Attester to generate an Evidence Packet (.pop) that imposes quantifiable cost on forgery of authorship claims, preserving privacy by design without disclosing document content.
      </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="system-model">
      <name>System Model</name>
      <t>
        This section defines the PoP system model in terms of the RATS architecture <xref target="RFC9334"/> and identifies where PoP diverges from standard remote attestation assumptions.
      </t>

      <section anchor="rats-entity-roles">
        <name>RATS Entity Roles</name>
        <t>
          PoP maps to RATS entity roles as follows:
        </t>
        <dl>
          <dt>Attester:</dt>
          <dd>The authoring application and its host platform. The Attester generates Evidence Packets (.pop) containing behavioral entropy, physical state markers, and SWF proofs. Unlike traditional RATS deployments, the Attester in PoP is operated by the entity whose claims are being verified (the author).</dd>
          <dt>Attesting Environment (AE):</dt>
          <dd>The software and hardware components that collect telemetry and generate cryptographic bindings. This includes the authoring application, operating system interfaces for entropy collection, and hardware Secure Elements (TPM/SE) when available.</dd>
          <dt>Verifier:</dt>
          <dd>An entity that appraises Evidence Packets and produces Attestation Results (WAR). Verifiers may be operated by publishers, platforms, or independent third parties. Verifier logic is specified in <xref target="PoP-Appraisal"/>.</dd>
          <dt>Relying Party:</dt>
          <dd>Consumers of WAR Results who make trust decisions based on the appraisal. This includes publishers, readers, or automated systems that need authenticity assurance.</dd>
          <dt>Endorser:</dt>
          <dd>Entities that provide Reference Values for verification. In PoP, this includes hardware manufacturers (TPM endorsement certificates) and the PoP specification itself (defining expected behavioral patterns).</dd>
        </dl>
      </section>

      <section anchor="rats-compatibility">
        <name>Compatibility with RATS Architecture</name>
        <t>
          PoP implements a specialized RATS profile with a critical trust inversion: in traditional remote attestation, the Attester is a device whose owner (Relying Party) wants assurance about its state. The adversary is typically external -- malware, network attackers, or supply chain threats.
        </t>
        <t>
          In PoP, the Attester is operated by the author, and the Relying Party (publisher, reader) has no privileged access to the authoring environment. The primary adversary is the Attester operator themselves. This fundamental inversion shapes the entire security model:
        </t>
        <ul>
          <li>Evidence must be unforgeable by the entity generating it</li>
          <li>Temporal claims must be bound to physical constraints the Attester cannot circumvent</li>
          <li>Behavioral entropy must be computationally expensive to simulate</li>
          <li>Hardware attestation provides value only when the hardware root of trust is genuinely inaccessible to the Attester operator</li>
        </ul>
        <t>
          Despite this inversion, PoP maintains compatibility with RATS message flows and data formats, enabling integration with existing RATS infrastructure where appropriate.
        </t>
      </section>
    </section>

    <section anchor="threat-model">
      <name>Threat Model</name>
      <t>
        This section defines the adversary model following the methodology of <xref target="RFC3552"/> and incorporating insights from RATS security analysis <xref target="Sardar-RATS"/>. The threat model assumes a Dolev-Yao style adversary <xref target="Dolev-Yao"/> with domain-specific constraints.
      </t>

      <section anchor="adversarial-attester">
        <name>Adversarial Attester Model</name>
        <t>
          The PRIMARY threat in PoP is an adversarial Attester -- an author who controls the Attesting Environment and seeks to generate Evidence for content they did not authentically author. This inverts the standard RATS trust assumption where the Attester is trusted to report honestly.
        </t>
        <t>
          The adversarial Attester has the following capabilities:
        </t>
        <ul>
          <li><strong>Full software control:</strong> Can modify, instrument, or replace any software component including the authoring application and operating system</li>
          <li><strong>Timing manipulation:</strong> Can adjust system clocks, virtualize execution environments, and attempt to compress or expand apparent time</li>
          <li><strong>Entropy injection:</strong> Can inject synthetic behavioral data (keystroke timing, jitter sequences) from pre-recorded or generated sources</li>
          <li><strong>Content pre-generation:</strong> Can generate document content using AI tools or other assistance before initiating the attestation session</li>
          <li><strong>Parallel execution:</strong> Can run multiple attestation sessions simultaneously or use distributed resources</li>
        </ul>
        <t>
          The adversary is constrained by:
        </t>
        <ul>
          <li><strong>Physics:</strong> Cannot violate thermodynamic laws or accelerate hardware beyond physical limits</li>
          <li><strong>Memory bandwidth:</strong> MHSF computations are bounded by available memory bandwidth</li>
          <li><strong>Hardware isolation:</strong> In T3/T4 tiers, cannot extract keys from Secure Elements without physical tampering</li>
          <li><strong>Economic rationality:</strong> Will not expend resources exceeding the value of successful forgery</li>
        </ul>
      </section>

      <section anchor="security-goals">
        <name>Security Goals</name>
        <t>
          PoP provides the following authentication properties, defined in terms of adversary advantage:
        </t>
        <dl>
          <dt>Temporal Authenticity:</dt>
          <dd>Given Evidence claiming authorship duration D, an adversary cannot produce valid Evidence in time significantly less than D. Formally: Adv_temporal = Pr[Verify(E) = accept AND Time(Generate(E)) &lt; D - epsilon] is negligible for meaningful epsilon.</dd>
          <dt>Behavioral Authenticity:</dt>
          <dd>Given Evidence containing behavioral entropy B, an adversary cannot efficiently generate synthetic entropy that is indistinguishable from biological origin. The cost of generating synthetic behavioral data satisfying all forensic constraints MUST exceed a defined threshold.</dd>
          <dt>Content Binding:</dt>
          <dd>Evidence E is cryptographically bound to document D such that E cannot be repurposed to attest a different document D'. This property is unconditional given collision resistance of SHA-256.</dd>
          <dt>Non-repudiation (T3/T4):</dt>
          <dd>In hardware-bound tiers, Evidence is signed with keys that the Attester cannot extract or duplicate, providing non-repudiation of the attestation act.</dd>
        </dl>
      </section>

      <section anchor="attack-taxonomy">
        <name>Attack Taxonomy</name>
        <t>
          The following attacks are in scope for PoP defenses:
        </t>

        <section anchor="retype-attack">
          <name>Retype Attack</name>
          <t>
            The canonical forgery attack against PoP: an adversary generates content using AI or other assistance, then retypes the pre-existing content while collecting "authentic" behavioral telemetry. This attack exploits the gap between typing existing text and composing original text.
          </t>
          <t>
            PoP defends against retype attacks through:
          </t>
          <ul>
            <li><strong>Cognitive Load Correlation:</strong> Authentic composition exhibits increased inter-keystroke intervals during high-complexity passages. Retyping known text shows uniform timing regardless of content complexity. Evidence with semantic-timing correlation r &lt; 0.2 is flagged for additional scrutiny (see <xref target="sec-retype-defense"/>).</li>
            <li><strong>Error Topology:</strong> Authentic authoring exhibits characteristic error patterns (hesitations, deletions near recent insertions, self-corrections). Retyping from reference exhibits either unnaturally low error rates or artificially injected errors lacking positional correlation.</li>
            <li><strong>Semantic-Temporal Binding:</strong> The SWF proof binds the document's semantic evolution to wall-clock time. Retyping requires real-time effort proportional to document length, even if content was pre-generated.</li>
          </ul>
          <t>
            Retype attacks remain economically viable for short documents. The forgery cost scales with document length and checkpoint frequency, providing graduated assurance rather than binary security.
          </t>
        </section>

        <section anchor="replay-attack">
          <name>Replay Attack</name>
          <t>
            Attempting to reuse previously valid Evidence for new claims. Defeated by Physical Freshness anchors that bind Evidence to non-reproducible physical state (thermal trajectories, kernel entropy samples).
          </t>
        </section>

        <section anchor="relay-attack">
          <name>Relay Attack</name>
          <t>
            Forwarding challenges or Evidence between a legitimate author and an adversary's session. In PoP, this manifests as claiming credit for another author's work. Defeated by hardware-bound signing (T3/T4) and out-of-band presence challenges that verify physical proximity.
          </t>
        </section>

        <section anchor="swf-acceleration">
          <name>SWF Acceleration Attack</name>
          <t>
            Using specialized hardware to compute SWF proofs faster than consumer hardware. Mitigated by Argon2id's memory-hardness (computation bounded by memory bandwidth, not ALU throughput) and Hardware-Anchored Time in T3/T4 tiers.
          </t>
        </section>

        <section anchor="ae-spoofing">
          <name>AE Spoofing</name>
          <t>
            Presenting a virtualized or modified Attesting Environment as genuine. In T1/T2 tiers, this is possible and Evidence should be weighted accordingly. T3/T4 tiers require hardware attestation that is difficult to spoof without physical access to the Secure Element.
          </t>
        </section>

        <section anchor="diversion-attack">
          <name>Diversion Attack</name>
          <t>
            An adversary redirects Evidence intended for one Verifier to a different Verifier or Relying Party context. PoP Evidence Packets do not inherently bind to a specific Verifier identity. When conveyed over TLS, implementations SHOULD use Exported Keying Material <xref target="RFC9266"/> to bind Evidence to the transport session. For offline verification, Relying Parties MUST evaluate Evidence provenance through out-of-band channels.
          </t>
        </section>
      </section>

      <section anchor="out-of-scope-threats">
        <name>Out-of-Scope Threats</name>
        <t>
          The following threats are explicitly out of scope:
        </t>
        <ul>
          <li><strong>Nation-state HSM compromise:</strong> Adversaries capable of extracting keys from certified HSMs via invasive physical attacks</li>
          <li><strong>Physics-level laboratory spoofing:</strong> Adversaries capable of simulating thermal trajectories and entropy sources at sub-microsecond precision</li>
          <li><strong>Quantum computation:</strong> Attacks requiring large-scale quantum computers (SHA-256 collision, Argon2id inversion)</li>
        </ul>
      </section>
    </section>

    <section anchor="core-principles">
      <name>Core Principles and Claims</name>
      <t>Building on the threat model defined above, PoP operates on five primary constraints:</t>
      <ul>
        <li>Physics-based Cost: Memory-Hard Sequential Functions (MHSF) establish an economic lower bound on forgery, ensuring consumer hardware remains competitive with specialized ASICs.</li>
        <li>Physical Freshness: Replay and simulation attacks are defeated by anchoring sessions to irreversible physical markers (Thermal Trajectories and Kernel Entropy pools). Every session incorporates Non-deterministic Physical Freshness sampled within the AE at the start of the sequential work function execution.</li>
        <li>Biological Binding: Captured human motor-signal randomness (jitter) serves as the non-deterministic seed for the spacetime proof.</li>
        <li>Out-of-Band Presence: Utilizing secondary physical devices (e.g., smartphone QR scans) to bridge the digital-physical gap and ensure a human is in the loop.</li>
        <li>Asymmetric Verification: The sequential work function allows proofs to be verified probabilistically via Merkle-sampled audit proofs, ensuring scalability and DoS resistance.</li>
      </ul>
    </section>

    <section anchor="rationale-and-terminology">
      <name>Protocol Rationale and Terminology</name>
      <t>
        The Proof of Process (PoP) framework follows the RATS architecture while introducing domain-specific extensions for physical process attestation.
      </t>
      <dl>
        <dt>PoP Evidence Packet (.pop):</dt>
        <dd>An Attester artifact containing Merkle trees, PoBST traces, and physical liveness markers (CBOR tag 1347571280, encoding ASCII "POP ").</dd>
        <dt>WAR Result (.war):</dt>
        <dd>A Verifier Attestation Result containing signed EAT claims and forensic assessments (CBOR tag 1463894560). The WAR format is specified in <xref target="PoP-Appraisal"/>.</dd>
        <dt>PoBST:</dt>
        <dd>Proof of Biological Space-Time. A memory-hard sequential function with probabilistic verification, entangled with human jitter.</dd>
        <dt>CDCE:</dt>
        <dd>Cross-Domain Constraint Entanglement. The method of weaving jitter and thermodynamics into the cryptographic chain.</dd>
        <dt>SWF:</dt>
        <dd>Sequential Work Function. The composite construction combining Argon2id and iterated SHA-256 (see <xref target="swf-construction"/>).</dd>
      </dl>
    </section>

    <section anchor="attester-state-machine">
      <name>Attester State Machine</name>
      <t>
        The Attesting Environment (AE) MUST implement the following formal state machine:
      </t>
      <ul>
        <li>RECORDING: AE captures semantic events and physical telemetry into a hash-linked buffer. Events are appended and the block hash is updated.</li>
        <li>PENDING_CHECK: The current event block is frozen to prepare for a checkpoint. No new events are accepted into this block.</li>
        <li>CHECKPOINT: AE computes the SWF over the entangled seed (previous hash + current jitter + physical markers).</li>
        <li>SEALING: The Attester generates a final snapshot, signs the transcript root with a hardware Secure Element (TPM/SE), and prepares the transport container (.pop).</li>
      </ul>
    </section>

    <section anchor="evidence-tiers">
    <name>Evidence Content Tiers</name>
    <t>
      PoP Evidence packets are classified by the depth of behavioral and forensic data collected:
    </t>
    <dl>
      <dt>CORE (Tier Value 1):</dt>
      <dd>Checkpoint chain with PoBST proofs, SHA-256 content binding, and physical freshness anchors. Proves temporal ordering and content integrity.</dd>
      <dt>ENHANCED (Tier Value 2):</dt>
      <dd>All CORE components plus behavioral entropy capture (Jitter Seals) and intra-checkpoint correlation. Adds evidence of interactive authoring behavior.</dd>
      <dt>MAXIMUM (Tier Value 3):</dt>
      <dd>All ENHANCED components plus CDCE, error topology analysis, and forgery cost bounds. Provides the strongest available evidence.</dd>
    </dl>
    </section>

    <section anchor="attestation-assurance-levels">
    <name>Attestation Assurance Levels</name>
    <t>
      The attestation tier system maps to established assurance frameworks
      including NIST SP 800-63B Authenticator Assurance Levels (AAL),
      ISO/IEC 29115 Levels of Assurance (LoA), and Entity Attestation Token
      (EAT) security levels as defined in <xref target="RFC9711"/>.
    </t>

    <section anchor="tier-t1-software">
      <name>Tier T1: Software-Only</name>
      <dl>
        <dt>Binding Strength:</dt><dd>none or hmac_local</dd>
        <dt>NIST AAL Mapping:</dt><dd>AAL1</dd>
        <dt>Security Properties:</dt>
        <dd>
          <ul>
            <li>SWF timing provides temporal ordering</li>
            <li>Hash chains provide tamper evidence</li>
            <li>Jitter entropy provides behavioral binding</li>
            <li>No hardware root of trust; keys stored in software</li>
          </ul>
        </dd>
      </dl>
    </section>

    <section anchor="tier-t2-attested">
      <name>Tier T2: Attested Software</name>
      <t>T2 extends T1 with optional hardware attestation hooks. The AE attempts to use platform security features (Keychain, DeviceCheck) but degrades gracefully. Maps to AAL2.</t>
    </section>

    <section anchor="tier-t3-hardware-bound">
      <name>Tier T3: Hardware-Bound</name>
      <t>Requires TPM 2.0 or platform Secure Enclave key binding. Evidence generation MUST fail if hardware is unavailable. Maps to AAL3.</t>
    </section>

    <section anchor="tier-t4-hardware-hardened">
      <name>Tier T4: Hardware-Hardened</name>
      <t>Discrete TPM + PUF binding + Enclave execution. Anti-tamper evidence required. Exceeds AAL3 requirements; maps to ISO/IEC 29115 LoA4.</t>
    </section>
    </section>

    <section anchor="profile-architecture">
    <name>Profile Architecture</name>
    <t>
      The PoP specification defines three implementation profiles that establish Mandatory-to-Implement (MTI) requirements for interoperability.
    </t>
    <table>
      <thead>
        <tr><th>Feature ID</th><th>Feature Name</th><th>CORE</th><th>ENHANCED</th><th>MAXIMUM</th></tr>
      </thead>
      <tbody>
        <tr><td>1</td><td>swf-argon2id-sha256</td><td>M</td><td>M</td><td>M</td></tr>
        <tr><td>2</td><td>content-binding</td><td>M</td><td>M</td><td>M</td></tr>
        <tr><td>4</td><td>checkpoint-chain</td><td>M</td><td>M</td><td>M</td></tr>
        <tr><td>50</td><td>behavioral-entropy</td><td>O</td><td>M</td><td>M</td></tr>
        <tr><td>105</td><td>hardware-attestation</td><td>O</td><td>O</td><td>M</td></tr>
      </tbody>
    </table>

    <section anchor="conformance">
      <name>Conformance Requirements</name>
      <t>
        A conforming Attester MUST implement at least the CORE profile. A conforming Verifier MUST be capable of validating all three profiles. Verifiers encountering unknown fields MUST ignore them and proceed with validation of known fields.
      </t>
    </section>
    </section>

    <section anchor="wire-format">
      <name>Evidence Format and CDDL</name>
      <t>
        Evidence Packets are CBOR-encoded <xref target="RFC8949"/> and identified by semantic tag 1347571280. The CDDL notation <xref target="RFC8610"/> is used to define the wire format.
      </t>
      <artwork type="cddl"><![CDATA[
; Primary structures
evidence-packet = {
    1 => uint,                    ; version (MUST be 1)
    2 => tstr,                    ; profile-uri
    3 => uuid,                    ; packet-id
    4 => pop-timestamp,           ; created
    5 => document-ref,            ; document
    6 => [+ checkpoint],          ; checkpoints
    ? 7 => attestation-tier,      ; T1-T4
    ? 8 => [* tstr],              ; limitations
    ? 9 => profile-declaration,   ; profile
    ? 10 => [+ presence-challenge], ; QR/OOB proofs
    ? 18 => physical-liveness,    ; CDCE markers
}

checkpoint = {
    1 => uint,                    ; sequence (monotonic)
    2 => uuid,                    ; checkpoint-id
    3 => pop-timestamp,           ; timestamp (local)
    4 => hash-value,              ; content-hash
    5 => uint,                    ; char-count
    6 => edit-delta,              ; delta
    7 => hash-value,              ; prev-hash
    8 => hash-value,              ; checkpoint-hash
    9 => process-proof,           ; SWF proof
    10 => jitter-binding,         ; behavioral-entropy
    11 => physical-state,         ; CDCE Weave
    12 => bstr .size 32,          ; entangled-mac
}

document-ref = {
    1 => hash-value,              ; content-hash
    ? 2 => tstr,                  ; filename
    3 => uint,                    ; byte-length
    4 => uint,                    ; char-count
    ? 5 => hash-salt-mode,        ; salting mode
    ? 6 => bstr,                  ; salt-commitment
}

process-proof = {
    1 => proof-algorithm,         ; algorithm id
    2 => proof-params,            ; SWF params
    3 => bstr,                    ; input (seed)
    4 => bstr,                    ; output (root)
    5 => [+ merkle-proof],        ; sampled proofs
    6 => float32,                 ; claimed-duration
}

; Subsidiary type definitions
attestation-tier = &(
    software-only: 1,
    attested-software: 2,
    hardware-bound: 3,
    hardware-hardened: 4,
)

proof-algorithm = &(
    sha256-chain: 1,
    pobst-argon2id: 20,
)

hash-salt-mode = &(
    unsalted: 0,
    author-salted: 1,
)

proof-params = {
    1 => uint,                    ; time-cost (t)
    2 => uint,                    ; memory-cost (m, KiB)
    3 => uint,                    ; parallelism (p)
    4 => uint,                    ; iterations
}

jitter-binding = {
    1 => [+ float32],             ; intervals (ms)
    2 => float32,                 ; entropy-estimate (bits)
    3 => bstr .size 32,           ; jitter-seal (HMAC)
}

merkle-proof = {
    1 => uint,                    ; leaf-index
    2 => [+ bstr .size 32],       ; sibling-path
    3 => bstr .size 32,           ; leaf-value
}

edit-delta = {
    1 => int,                     ; chars-added
    2 => int,                     ; chars-deleted
    3 => uint,                    ; op-count
    ? 4 => [* edit-position],     ; positions
}

edit-position = [
    uint,                         ; offset
    int,                          ; change (+/-)
]

physical-state = {
    1 => [+ float32],             ; thermal (relative)
    2 => uint,                    ; entropy-delta
    ? 3 => bstr .size 32,         ; kernel-commitment
}

physical-liveness = {
    1 => [+ thermal-sample],      ; thermal trajectory
    2 => bstr .size 32,           ; entropy-anchor
}

thermal-sample = [
    pop-timestamp,                ; sample time
    float32,                      ; temperature delta
]

presence-challenge = {
    1 => bstr,                    ; challenge-nonce
    2 => bstr,                    ; device-signature
    3 => pop-timestamp,           ; response-time
}

profile-declaration = {
    1 => tstr,                    ; profile-id
    2 => [+ uint],                ; feature-flags
}

; Base types
uuid = bstr .size 16
pop-timestamp = #6.1(number)
hash-value = {
    1 => hash-algorithm,
    2 => bstr,
}
hash-algorithm = &(
    sha256: 1,
    sha384: 2,
    sha512: 3,
)
      ]]></artwork>

      <section anchor="checkpoint-hash-computation">
        <name>Checkpoint Hash Computation</name>
        <t>
          The checkpoint-hash field MUST be computed as follows:
        </t>
        <artwork><![CDATA[
checkpoint-hash = SHA-256(
    prev-hash ||
    content-hash ||
    CBOR-encode(edit-delta) ||
    CBOR-encode(jitter-binding) ||
    CBOR-encode(physical-state) ||
    process-proof.output
)
        ]]></artwork>
        <t>
          Where || denotes concatenation and CBOR-encode produces deterministic CBOR per Section 4.2 of <xref target="RFC8949"/>.
        </t>
      </section>
    </section>

    <section anchor="swf-construction">
      <name>Sequential Work Function</name>
      <t>
        PoP uses a composite Sequential Work Function (SWF) combining Argon2id <xref target="RFC9106"/> for memory-hardness with iterated SHA-256 for sequential ordering. This construction is NOT a Verifiable Delay Function in the formal sense <xref target="Boneh2018"/>; it does not provide efficient public verification of the delay claim from the output alone.
      </t>
      <t>
        Instead, verification relies on Merkle-sampled audit proofs: the Attester commits to a Merkle tree over intermediate states, and the Verifier checks a random subset of state transitions. This provides probabilistic verification in O(k * log n) time where k is the sample count and n is the iteration count.
      </t>

      <section anchor="swf-algorithm">
        <name>Construction</name>
        <t>The SWF is computed as follows:</t>
        <artwork><![CDATA[
state_0 = Argon2id(seed, salt=seed, t=1, m=65536, p=1, len=32)
for i in 1..iterations:
    state_i = SHA-256(state_{i-1})
output = state_iterations
        ]]></artwork>
        <t>
          The salt for Argon2id MUST be set equal to the seed value to ensure deterministic output. Implementations MUST NOT use a random salt.
        </t>
      </section>

      <section anchor="swf-verification">
        <name>Verification Protocol</name>
        <t>The Verifier MUST:</t>
        <ol>
          <li>Recompute Argon2id from the declared seed to obtain state_0</li>
          <li>For each sampled proof in the Merkle tree, verify the sibling path against the committed root and recompute SHA-256(state_i) to compare against state_{i+1}</li>
          <li>Verify the final state matches the declared output</li>
        </ol>
        <t>
          A minimum of 20 sampled proofs is REQUIRED for CORE profile. ENHANCED profile requires 50 proofs. MAXIMUM profile requires 100 proofs.
        </t>
      </section>

      <section anchor="swf-security">
        <name>Security Bound</name>
        <t>
          An adversary who skips fraction f of iterations will be detected with probability 1-(1-f)^k where k is the number of sampled proofs. With k=20 and f=0.1, detection probability exceeds 0.878. With k=100 and f=0.05, detection probability exceeds 0.994.
        </t>
      </section>

      <section anchor="hat">
        <name>Hardware-Anchored Time (HAT)</name>
        <t>
          In T3/T4 tiers, the AE MUST anchor the SWF seed to the TPM Monotonic Counter. This prevents "SWF Speed-up" attacks by ensuring that the temporal proof is bound to the hardware's internal perception of time.
        </t>
      </section>
    </section>

    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>
        This document requests the following IANA registrations:
      </t>
      <section anchor="iana-cbor-tags">
        <name>CBOR Tags</name>
        <t>
          Registration of CBOR tag 1347571280 (encoding ASCII "POP ") for PoP Evidence Packets and tag 1463894560 (encoding ASCII "WAR ") for WAR Results.
        </t>
      </section>
      <section anchor="iana-smi-pen">
        <name>SMI Private Enterprise Number</name>
        <t>
          This document uses SMI PEN 65074, which has been requested from IANA for WritersLogic Inc. Registration is pending confirmation.
        </t>
      </section>
      <section anchor="iana-eat-profile">
        <name>EAT Profile</name>
        <t>
          Registration of the EAT profile URI: urn:ietf:params:rats:eat:profile:pop:1.0
        </t>
      </section>
      <section anchor="iana-media-types">
        <name>Media Types</name>
        <t>Requests registration of:</t>
        <ul>
          <li>application/vnd.writerslogic-pop+cbor</li>
          <li>application/vnd.writerslogic-war+cbor</li>
        </ul>
      </section>
    </section>

    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>
        This section provides security analysis following <xref target="RFC3552"/> guidelines. The threat model is defined in <xref target="threat-model"/> with the adversarial Attester as the primary threat actor. Detailed forensic security analysis is provided in <xref target="PoP-Appraisal"/>.
      </t>

      <section anchor="sec-primary-threat">
        <name>Primary Threat: Adversarial Attester</name>
        <t>
          Unlike traditional remote attestation where external adversaries threaten system integrity, PoP's primary threat is the Attester operator themselves. The author controls the Attesting Environment and has incentive to claim authenticity for AI-generated or assisted content.
        </t>
        <t>
          This threat model inversion has fundamental implications:
        </t>
        <ul>
          <li>Software-only attestation (T1) provides minimal assurance since the Attester controls all software</li>
          <li>Cryptographic proofs must be bound to physical constraints the Attester cannot circumvent</li>
          <li>Behavioral entropy must be economically expensive to forge, not merely cryptographically secure</li>
          <li>Trust in Evidence scales with the Attestation Tier and the cost of bypassing its guarantees</li>
        </ul>
      </section>

      <section anchor="sec-retype-defense">
        <name>Retype Attack Defenses</name>
        <t>
          The retype attack (see <xref target="retype-attack"/>) is the canonical forgery vector. Defenses are layered:
        </t>
        <dl>
          <dt>Cognitive Load Correlation (CLC):</dt>
          <dd>Verifiers MUST analyze correlation between content complexity and typing cadence. Retyping known text produces flat cognitive load curves; authentic composition shows elevated latency during complex passages. Detection threshold: r &lt; 0.2 correlation flags evidence for additional scrutiny.</dd>
          <dt>Error Topology Analysis:</dt>
          <dd>Authentic authoring produces characteristic error patterns: corrections localized near recent insertions, deletion-to-insertion ratios consistent with human cognitive models <xref target="Salthouse1986"/>, and fractal self-similarity in revision patterns. Retyping produces either unnaturally low error rates or randomly distributed artificial errors.</dd>
          <dt>Temporal Cost:</dt>
          <dd>Even successful retype attacks require real-time effort. A 5,000-word document with 10-second checkpoint intervals requires 8+ hours of continuous typing effort to forge. The attack does not scale economically for high-volume forgery.</dd>
        </dl>
        <t>
          Relying Parties MUST understand that retype attacks remain viable for short documents or high-value targets willing to invest real time. PoP provides graduated assurance proportional to document length and checkpoint density.
        </t>
      </section>

      <section anchor="sec-relay-replay">
        <name>Relay and Replay Attack Defenses</name>
        <t>
          As defined in <xref target="replay-attack"/> and <xref target="relay-attack"/>, these attacks are defeated through Physical Freshness anchors binding Evidence to non-reproducible physical state:
        </t>
        <ul>
          <li>Thermal trajectories captured during SWF computation cannot be replayed</li>
          <li>Kernel entropy pool deltas are bound to specific execution moments</li>
          <li>Out-of-band presence challenges (QR scans) verify real-time physical proximity</li>
        </ul>
        <t>
          Verifiers MUST reject Evidence where physical freshness markers are stale, inconsistent with timestamps, or exhibit patterns suggesting simulation.
        </t>
      </section>

      <section anchor="sec-swf-speedup">
        <name>SWF Acceleration Defenses</name>
        <t>
          As analyzed in <xref target="swf-acceleration"/>, specialized hardware attacks are mitigated by:
        </t>
        <ul>
          <li><strong>Memory-hardness:</strong> Argon2id computation is bounded by memory bandwidth (approximately 50 GB/s for DDR5), not ALU throughput. ASICs provide minimal advantage.</li>
          <li><strong>Hardware-Anchored Time (T3/T4):</strong> SWF seeds are bound to TPM monotonic counters, preventing time compression even with faster computation.</li>
          <li><strong>Merkle sampling:</strong> Skipping SWF iterations is detected probabilistically. With k=100 samples, skipping 5% of iterations has >99.4% detection probability.</li>
        </ul>
      </section>

      <section anchor="sec-tier-trust">
        <name>Trust Gradation by Tier</name>
        <t>
          Relying Parties MUST interpret Evidence according to its Attestation Tier:
        </t>
        <dl>
          <dt>T1 (Software-Only):</dt>
          <dd>Provides temporal ordering and content binding only. Adversarial Attester can forge all behavioral claims. Suitable only for low-stakes applications or as supplementary evidence.</dd>
          <dt>T2 (Attested Software):</dt>
          <dd>Adds platform attestation hooks but degrades gracefully. Provides moderate assurance against casual forgery but not determined adversaries.</dd>
          <dt>T3 (Hardware-Bound):</dt>
          <dd>Signing keys are hardware-protected. Forgery requires physical access to the Secure Element. Provides strong assurance for most applications.</dd>
          <dt>T4 (Hardware-Hardened):</dt>
          <dd>Anti-tamper evidence and PUF binding. Forgery requires invasive hardware attacks. Suitable for high-stakes legal or financial applications.</dd>
        </dl>
      </section>

      <section anchor="sec-economic-bounds">
        <name>Forgery Cost Bounds</name>
        <t>
          Implementations SHOULD report quantified forgery cost estimates in WAR Results. For CORE profile (10,000 iterations, m=65536 KiB):
        </t>
        <ul>
          <li>Sequential computation time: approximately 45 seconds per checkpoint</li>
          <li>Memory requirement: 64 MiB per concurrent chain</li>
          <li>Energy cost: approximately 0.01 USD per checkpoint at consumer electricity rates</li>
        </ul>
        <t>
          For ENHANCED profile, adversary must additionally satisfy behavioral constraints (CV > 0.15, semantic correlation r > 0.3, error topology matching). These constraints are conjunctive per checkpoint and scale superlinearly with checkpoint count due to session consistency requirements.
        </t>
      </section>

      <section anchor="sec-dos">
        <name>Denial of Service</name>
        <t>
          SWF verification is asymmetric: Merkle-sampled proofs verify in O(k * log n) versus O(n) generation. Verifiers cannot be overwhelmed by expensive verification requests. Implementations SHOULD implement rate limiting on Evidence submission.
        </t>
      </section>

      <section anchor="sec-implementation-requirements">
        <name>Implementation Security Requirements</name>
        <t>
          Conforming implementations MUST:
        </t>
        <ul>
          <li>Use constant-time comparison for all cryptographic operations</li>
          <li>Zero sensitive memory (keys, jitter data) after use</li>
          <li>Validate all input lengths and formats before processing</li>
          <li>Reject Evidence with inconsistent internal state (e.g., checkpoint-hash verification failure)</li>
        </ul>
        <t>
          T3/T4 implementations MUST additionally:
        </t>
        <ul>
          <li>Store signing keys exclusively in hardware Secure Elements</li>
          <li>Bind SWF seeds to TPM monotonic counters</li>
          <li>Verify platform integrity before Evidence generation</li>
        </ul>
      </section>
    </section>

    <section anchor="privacy-considerations">
      <name>Privacy Considerations</name>
      <t>
        This section addresses privacy in accordance with <xref target="RFC6973"/>.
      </t>

      <section anchor="priv-minimization">
        <name>Data Minimization</name>
        <t>
          PoP Evidence Packets MUST NOT contain document content. Content binding uses cryptographic hashes (SHA-256) which are computationally irreversible. The author-salted mode (hash-salt-mode=1) provides additional protection by preventing rainbow-table correlation across documents.
        </t>
      </section>

      <section anchor="priv-fingerprinting">
        <name>Behavioral Fingerprinting</name>
        <t>
          Jitter sequences in ENHANCED and MAXIMUM profiles constitute behavioral biometrics. Verifiers MUST NOT:
        </t>
        <ul>
          <li>Store jitter data beyond the verification session</li>
          <li>Correlate jitter across multiple Evidence Packets to deanonymize authors</li>
          <li>Use jitter data for any purpose other than authenticity verification</li>
        </ul>
        <t>
          Attesters SHOULD quantize jitter values to reduce fingerprinting precision while preserving statistical validity. A minimum quantization of 5ms is RECOMMENDED.
        </t>
      </section>

      <section anchor="priv-physical-leakage">
        <name>Physical State Leakage</name>
        <t>
          Thermal trajectories and kernel entropy deltas in the physical-state field may reveal information about the Attester's hardware configuration. Implementations SHOULD normalize thermal data to relative deltas rather than absolute values to prevent device fingerprinting.
        </t>
      </section>

      <section anchor="priv-unlinkability">
        <name>Unlinkability</name>
        <t>
          Authors who wish to remain pseudonymous SHOULD use per-document signing keys and the author-salted content binding mode to prevent cross-document linkage.
        </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.3552.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6973.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.8610.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8949.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9106.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9266.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9334.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9711.xml"/>
      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="Boneh2018" target="https://doi.org/10.1007/978-3-319-96884-1_25">
          <front>
            <title>Verifiable Delay Functions</title>
            <author fullname="Dan Boneh" initials="D." surname="Boneh"/>
            <author fullname="Joseph Bonneau" initials="J." surname="Bonneau"/>
            <author fullname="Benedikt Bunz" initials="B." surname="Bunz"/>
            <author fullname="Ben Fisch" initials="B." surname="Fisch"/>
            <date year="2018"/>
          </front>
          <seriesInfo name="CRYPTO" value="2018"/>
        </reference>
        <reference anchor="Dolev-Yao" target="https://doi.org/10.1109/TIT.1983.1056650">
          <front>
            <title>On the Security of Public Key Protocols</title>
            <author fullname="Danny Dolev" initials="D." surname="Dolev"/>
            <author fullname="Andrew Yao" initials="A." surname="Yao"/>
            <date year="1983"/>
          </front>
          <seriesInfo name="IEEE Transactions on Information Theory" value="29(2), 198-208"/>
        </reference>
        <reference anchor="Salthouse1986" target="https://doi.org/10.1037/0096-1523.12.3.370">
          <front>
            <title>Perceptual, Cognitive, and Motoric Aspects of Transcription Typing</title>
            <author fullname="Timothy A. Salthouse" initials="T.A." surname="Salthouse"/>
            <date year="1986"/>
          </front>
          <seriesInfo name="Psychological Bulletin" value="99(3), 303-319"/>
        </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>
        <reference anchor="PoP-Appraisal">
          <front>
            <title>Proof of Process (PoP): Forensic Appraisal and Security Model</title>
            <author fullname="David Condrey" initials="D." surname="Condrey"/>
            <date year="2026"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-condrey-rats-pop-appraisal-03"/>
        </reference>
      </references>
    </references>

    <section anchor="test-vectors" numbered="false">
      <name>Appendix A: SWF Test Vectors</name>
      <t>
        The following test vectors validate SWF implementations. The salt for Argon2id is set equal to the seed.
      </t>
      <artwork><![CDATA[
Seed: "witnessd-genesis-v1"
Seed (hex): 7769746e657373642d67656e657369732d7631
Salt: (same as seed)

Argon2id Parameters:
  Time Cost (t): 1
  Memory Cost (m): 65536 KiB
  Parallelism (p): 1
  Output Length: 32 bytes

Iterations: 10,000

Intermediate States:
  state_0 (Argon2id):
    80c61705757b131005819066fad7f251a0fee7016cdae38eb753409931d1b46a
  state_1000:
    a9aa3186ec6a3cdcc299735564f46ac42e31cacb463ced34d6d7e4086625dbe3
  state_5000:
    4264f594f871d61029fb413715b391977bc7bb40144fa8b6e89cb04a7de0d160
  state_9999:
    4ece1d5c51ca6b7a5da4827416535566fca98ea260fa00b2f93e10ee63b98498
  state_10000 (final):
    bf3883035ced837663ccc46a37d1e4fd4f324a5caeadbd17f9bf0c34004294dc
      ]]></artwork>
    </section>
  </back>
</rfc>
