Cryptographic Proof of Effort (CPoE): Architecture and Evidence Format

6.1. RATS Entity Roles

CPoE maps to RATS entity roles [RFC9334] as follows. Verifier and Relying Party follow standard RATS definitions; the remaining roles have CPoE-specific characteristics:¶

Attester:

The authoring application and its host platform. Unlike traditional RATS deployments, the Attester is operated by the entity whose claims are being verified (the author).¶

Attesting Environment (AE):

The authoring application, OS entropy interfaces, and hardware Secure Elements (TPM/SE) when available.¶

Endorser:

Hardware manufacturers that issue TPM endorsement certificates and platform attestation credentials for T3/T4 tiers.¶

Reference Value Provider:

The CPoE specification itself (behavioral patterns, SWF parameters) and calibration services that provide updated forensic baselines.¶

Target Environment:

The document editor session and its content state. The Target Environment is measured by the Attesting Environment at each checkpoint via content hashing and behavioral telemetry capture.¶

6.2. Compatibility with RATS Architecture

CPoE extends RATS from device state attestation to process attestation, verifying that a physical process (human authorship) occurred as claimed. The fundamental problem structure is identical: an Attester generates Evidence, conveys it to a Verifier, and the Verifier produces Attestation Results for Relying Parties.¶

CPoE implements a critical trust inversion: in traditional remote attestation, the adversary is external (malware, network attackers). In CPoE, the Attester is operated by the author, and the primary adversary is the Attester operator themselves. This inversion shapes the security model:¶

• Evidence must be unforgeable by the entity generating it¶

• Temporal claims must be bound to physical constraints the Attester cannot circumvent¶

• Behavioral entropy must be computationally expensive to simulate¶

• Hardware attestation provides value only when the hardware root of trust is genuinely inaccessible to the Attester operator¶

The RATS architecture accommodates this through its layered trust model and configurable Appraisal Policies ([RFC9334]). The companion appraisal document ([CPoE-Appraisal]) defines domain-specific verification procedures. The rationale for Experimental status is provided in Section 17.¶

6.3. Adversarial Attester as RATS Profile

CPoE constitutes a RATS profile in which the standard Attester-operator trust assumption is explicitly relaxed. RFC 9334 Section 3 defines Attester roles functionally (the entity producing Evidence) without requiring the operator to be trusted. CPoE leverages this by treating the Attester operator as the primary adversary and relying on physics-based constraints, memory-hard functions, and hardware trust anchors (at T3/T4) rather than Attester honesty.¶

This profile is analogous to anti-cheat and DRM attestation patterns where the platform operator is adversarial, and differs from traditional RATS deployments (firmware integrity, supply chain verification) where external compromise is the primary threat. Implementations and Verifier policies MUST account for this trust model when interpreting CPoE Evidence.¶

6.4. Evidence Format and EAT Relationship

CPoE Evidence Packets use a domain-specific CBOR structure (tag 1129336645) rather than CWT/JWT-wrapped EAT tokens. This design reflects the fundamental difference between CPoE Evidence and traditional EAT claims:¶

• EAT ([RFC9711]) models entity state as a set of claims at a point in time. CPoE Evidence models a continuous physical process as an ordered sequence of checkpoints with SWF proofs, behavioral entropy, and physical state bindings.¶

• The checkpoint chain structure (sequential process-proofs, hash-linked deltas, jitter bindings) has no natural representation in the EAT claims model.¶

• Wrapping each checkpoint as a separate EAT would lose the cryptographic chain integrity that is central to CPoE's security properties.¶

The EAT profile URI "urn:ietf:params:rats:eat:profile:cpoe:1.0" applies to the Attestation Result (WAR) format defined in [CPoE-Appraisal], which carries EAT-compatible claims (verdict, attestation tier, forensic assessments). The Evidence Packet uses its own profile URI "urn:ietf:params:cpoe:profile:1.0" to identify the CPoE Evidence format. Generic EAT tooling cannot parse CPoE Evidence without CPoE-specific support, but can consume WAR Attestation Results via the EAR compatibility mapping defined in [CPoE-Appraisal].¶

6.5. Reference Value Trust Model

The Reference Value Provider role in CPoE differs from traditional RATS deployments where RVPs supply known-good platform measurements from a trusted supply chain. In CPoE, Reference Values take two forms:¶

Specification-defined values:

SWF parameters, forensic thresholds, and profile requirements defined in this document and [CPoE-Appraisal]. These are static and trusted by virtue of the specification itself.¶

Author-generated behavioral baselines:

Per-author behavioral profiles (baseline-digest) accumulated across sessions within the Attesting Environment. These are self-asserted by the Attester and MUST NOT be treated as trusted Reference Values. The baseline-digest is signed by the Evidence Packet's signing key and bound to the author identity via identity-fingerprint, but at T1/T2 tiers the signing key is software-controlled and the baseline could be synthetically constructed (see Section 8.3).¶

Verifiers MUST treat behavioral baselines as corroborative evidence whose weight scales with the confidence-tier (population-reference through mature), not as independent attestation of authenticity. The forensic mechanisms (SNR, CLC, error topology) operate independently of baseline data and provide the primary discrimination between biological and synthetic authoring.¶

7.1. Passport Model Message Flow

CPoE follows the RATS passport model ([RFC9334], Section 8.1; [RATS-Models]):¶

+----------+  .cpoe   +-----------+  .cwar   +-----------+
| Attester +--------->+  Verifier +--------->+  Relying  |
| (Author/ |Evidence  |           |Attestation|   Party   |
|    AE)   |          |           | Results  |(Publisher)|
+----------+          +-----+-----+          +-----------+
                            ^
              Endorsements  |  Reference Values
             (TPM/SE certs) | (SWF params, baselines)
                            |
               +------------+------------+
               |  Endorser / Ref. Value  |
               |       Provider          |
               +-------------------------+

The CPoE-specific message flow is:¶

1. The Attester (authoring application running in the Attesting Environment) collects behavioral telemetry during content creation and generates an Evidence Packet (.cpoe) containing SWF proofs, jitter bindings, and physical state markers.¶

2. The Evidence Packet is conveyed to a Verifier, which appraises chain integrity, temporal ordering, behavioral entropy, and content binding per the procedures defined in [CPoE-Appraisal].¶

3. The Verifier produces a Cryptographic Written Authorship Report (.cwar) containing EAT claims, forensic assessment scores, and forgery cost estimates.¶

4. The Relying Party (publisher, reader, or automated platform) consumes the WAR to make trust decisions about the claimed authorship provenance.¶

Endorsers (hardware manufacturers) supply TPM endorsement certificates and Secure Element attestations that Verifiers use to validate hardware-bound claims in T3/T4 Evidence. Reference Value Providers supply the expected behavioral patterns, SWF difficulty parameters, and profile specifications that Verifiers use as appraisal baselines.¶

Note: In some deployments, the Relying Party (e.g., a content management system or publishing platform) may receive an Evidence Packet alongside content and forward it to a Verifier on behalf of the author. This is operationally similar to the RATS background-check model ([RFC9334], Section 8.2), where the Relying Party initiates verification. However, the Evidence Packet is still generated by the Attester and travels with the content as a self-contained credential, making this architecturally consistent with the passport model. Deployments using this pattern SHOULD ensure that the Relying Party does not modify the Evidence Packet before forwarding it to the Verifier.¶

7.2. Evidence Lifecycle

The following sequence illustrates the end-to-end lifecycle of a CPoE attestation session:¶

 Author        Attester (AE)          Verifier         Relying Party
   |                |                     |                  |
   | begin session  |                     |                  |
   +--------------->|                     |                  |
   |                |--+ sample physical  |                  |
   |                |  | freshness anchor |                  |
   |                |<-+ (entropy, thermal)|                 |
   |                |                     |                  |
   |                |--+ collect initial  |                  |
   |                |  | jitter sample    |                  |
   |                |<-+ (32+ bytes)      |                  |
   |                |                     |                  |
   | keystrokes,    |                     |                  |
   | edits, pauses  |                     |                  |
   +--------------->| capture jitter,     |                  |
   |                | semantic events     |                  |
   |                |                     |                  |
   |                |--+ CHECKPOINT:      |                  |
   |                |  | compute SWF,     |                  |
   |                |  | bind jitter +    |                  |
   |                |  | physical state,  |                  |
   |                |  | extend hash chain|                  |
   |                |<-+                  |                  |
   |                |                     |                  |
   |   ... (repeat per checkpoint interval) ...             |
   |                |                     |                  |
   | end session    |                     |                  |
   +--------------->| SEAL: sign chain,   |                  |
   |                | emit .cpoe file     |                  |
   |                |                     |                  |
   |                | .cpoe (Evidence)    |                  |
   |                +-------------------->|                  |
   |                |                     | appraise:        |
   |                |                     | chain, SWF,      |
   |                |                     | entropy, MACs    |
   |                |                     |                  |
   |                |                     | .cwar (Result)   |
   |                |                     +----------------->|
   |                |                     |                  | trust
   |                |                     |                  | decision
   |                |                     |                  |

Attesters SHOULD use checkpoint intervals between 10 and 120 seconds (default 30 seconds). Verifiers MUST accept Evidence with any positive checkpoint interval but MAY flag intervals outside this range in warnings. When behavioral entropy capture is active (ENHANCED or MAXIMUM content tier), each checkpoint SHOULD contain jitter-binding data from at least 20 inter-keystroke intervals. Checkpoints with fewer than 20 intervals provide insufficient data for behavioral analysis; the Attester SHOULD extend the checkpoint interval rather than emit a low-entropy checkpoint. Verifiers MUST accept checkpoints with any number of intervals (including zero for paste-only intervals) but SHOULD flag checkpoints with fewer than 20 intervals as providing no behavioral assurance. Each checkpoint interval produces one link in the hash chain. The SWF computation runs continuously during the interval, binding the author's behavioral entropy and the platform's physical state to the elapsed wall-clock time. At session end or rollover boundary, the Attester seals the chain into a .cpoe Evidence Packet. For long-running authoring projects, the Session Continuation mechanism (Section 7.3) allows a series of Evidence Packets to be cryptographically linked.¶

7.3. Session Continuation

Long-running authoring projects (e.g., books, dissertations, multi-day reports) may produce checkpoint chains that exceed practical memory and file-size limits. To support these workflows, the Attester MAY partition the authoring process into a series of Evidence Packets linked by the previous-packet-ref field (evidence-packet key 14).¶

Attesters MUST begin a new Evidence Packet when the checkpoint count exceeds 1000 or the serialized packet size exceeds 10 MiB, whichever occurs first. Attesters SHOULD roll over to a new Evidence Packet when the checkpoint count within the current packet approaches these limits. A maximum of 10,000 checkpoints per Evidence Packet is RECOMMENDED as an upper bound for implementations that do not enforce the 1000-checkpoint trigger.¶

The following rules govern session continuation:¶

1. The first Evidence Packet in a series MUST omit the previous-packet-ref field (key 14) and MUST set packet-sequence (key 15) to 1, or omit both fields entirely. Omission of both fields indicates a standalone (non-continuation) Evidence Packet.¶

2. Each subsequent Evidence Packet MUST include previous-packet-ref containing the hash (using the series' hash-algorithm) of the complete CBOR-encoded preceding Evidence Packet. packet-sequence MUST be set to one greater than the preceding packet's packet-sequence value.¶

3. The document-ref (evidence-packet key 5) MUST be identical across all packets in a series. Verifiers MUST reject a continuation packet whose document-ref differs from the initial packet's.¶

4. The first checkpoint in a continuation packet MUST set its prev-hash to the final checkpoint-hash of the preceding Evidence Packet (not to H(CBOR-encode(document-ref)), which is reserved for the series' first checkpoint). This cryptographically links the two packets into one logical chain.¶

5. Checkpoint sequence numbers (checkpoint key 1) MUST be globally monotonic across the series. The first checkpoint in a continuation packet MUST have a sequence number strictly greater than the last checkpoint in the preceding packet.¶

6. The Attester MUST seal the current Evidence Packet before beginning a new one. Concurrent open packets for the same document-ref MUST NOT exist.¶

This mechanism preserves the full cryptographic chain integrity of a single Evidence Packet while bounding per-file resource consumption. A Verifier appraising a series reconstructs the logical chain by following previous-packet-ref links from the final packet back to the initial packet.¶

7.4. Behavioral Baseline Verification

The Attester MAY include a baseline-verification structure (evidence-packet key 19) that enables Verifiers to assess behavioral consistency across writing sessions by the same author. A baseline-verification contains a session-behavioral-summary (IKI histogram, coefficient of variation, Hurst exponent, cognitive pause frequency, duration, keystroke count) and optionally a baseline-digest summarizing the author's historical profile with a COSE_Sign1 signature. When baseline-verification is present, the identity-fingerprint within the baseline MUST match the Evidence Packet's identity-fingerprint. Verifiers MUST reject Evidence where these values differ.¶

The identity-fingerprint MUST be computed as SHA-256(public-key) where public-key is the raw bytes of the author's signing key. The baseline-digest aggregates per-session statistics using Welford's online algorithm (streaming-stats). The session-merkle-root field contains a Merkle Mountain Range root over incorporated session hashes; Attesters without MMR tracking MUST set it to 32 zero bytes, and Verifiers MUST NOT elevate confidence-tier based on a zero value.¶

The confidence-tier indicates baseline maturity: population-reference (1, 0-4 sessions), emerging (2, 5-9), established (3, 10-19), mature (4, 20+). During initial enrollment (no prior sessions), the Attester MUST omit baseline-digest and digest-signature. When baseline-digest is present, digest-signature MUST also be present; Verifiers MUST verify the COSE_Sign1 signature and that identity-fingerprint equals SHA-256 of the signing key.¶

8.1. Adversarial Attester Model

The PRIMARY threat in CPoE 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.¶

The adversarial Attester has the following capabilities:¶

• Full software control: Can modify, instrument, or replace any software component including the authoring application and operating system¶

• Timing manipulation: Can adjust system clocks, virtualize execution environments, and attempt to compress or expand apparent time¶

• Entropy injection: Can inject synthetic behavioral data (keystroke timing, jitter sequences) from pre-recorded or generated sources¶

• Content pre-generation: Can generate document content using AI tools or other assistance before initiating the attestation session¶

• Parallel execution: Can run multiple attestation sessions simultaneously or use distributed resources¶

The adversary is constrained by:¶

• Physics: Cannot violate thermodynamic laws or accelerate hardware beyond physical limits¶

• Memory bandwidth: SWF computations are bounded by available memory bandwidth¶

• Hardware isolation: In T3/T4 tiers, cannot extract keys from Secure Elements without physical tampering¶

• Economic rationality: Will not expend resources exceeding the value of successful forgery¶

8.2. Security Goals

CPoE provides the following authentication properties, defined in terms of adversary advantage:¶

Temporal Authenticity:

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)) < D - epsilon] is negligible for meaningful epsilon.¶

Behavioral Authenticity:

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

Content Binding:

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

Non-repudiation (T3/T4):

In hardware-bound tiers, Evidence is signed with keys that the Attester cannot extract or duplicate, providing non-repudiation of the attestation act.¶

8.3. Attack Taxonomy

The following attacks are in scope for CPoE defenses. Cross-references to individual attacks (e.g., Section 8.3) refer to rows in this table and the corresponding defense analysis in Section 19.¶

8.4. Out-of-Scope Threats

The following threats are explicitly out of scope:¶

• Nation-state HSM compromise: Adversaries capable of extracting keys from certified HSMs via invasive physical attacks¶

• Physics-level laboratory spoofing: Adversaries capable of simulating thermal trajectories and entropy sources at sub-microsecond precision¶

• Quantum computation: Attacks requiring large-scale quantum computers (hash function collision finding, Argon2id inversion)¶

13.1. Tier T1: Software-Only

Binding Strength:

none or hmac_local¶

NIST AAL Mapping:

AAL1¶

Security Properties:

• SWF timing provides temporal ordering¶

• Hash chains provide tamper evidence¶

• Jitter entropy provides behavioral binding¶

• No hardware root of trust; keys stored in software¶

13.2. Tier T2: Attested Software

T2 extends T1 with optional hardware attestation hooks. The AE attempts to use platform security features (Keychain, DeviceCheck) but degrades gracefully. Maps to AAL2.¶

13.3. Tier T3: Hardware-Bound

Requires TPM 2.0 or platform Secure Enclave key binding. Evidence generation MUST fail if hardware is unavailable. Maps to AAL3.¶

13.4. Tier T4: Hardware-Hardened

Discrete TPM + PUF binding + Enclave execution. Anti-tamper evidence required. Exceeds AAL3 requirements; maps to ISO/IEC 29115 LoA4.¶

14.1. Conformance Requirements

A conforming Attester MUST implement at least the CORE profile. A conforming Verifier MUST be capable of validating all three profiles. Verifiers MUST reject Evidence containing unrecognized integer keys in the range 0-99 (reserved for this specification). Verifiers MUST ignore unrecognized keys with values 100 or greater. Verifiers receiving an Evidence Packet with version greater than 1 MUST reject the packet unless they implement the corresponding protocol version.¶

The profile-uri field in an Evidence Packet MUST be set to "urn:ietf:params:cpoe:profile:1.0" for Evidence conforming to this specification. This URI identifies the CPoE Evidence format and is distinct from the EAT profile URI "urn:ietf:params:rats:eat:profile:cpoe:1.0", which identifies CPoE Attestation Results (see Section 6.4).¶

In the document-ref structure, byte-length is the length in bytes of the UTF-8 encoded document, and char-count is the number of Unicode scalar values (code points).¶

If the Evidence Packet omits the attestation-tier field, the Verifier MUST derive the tier from evidence content: T1 if no hardware attestation is present, T2 if platform attestation hooks are detected, T3 if TPM key binding is verified, T4 if anti-tamper evidence and PUF binding are confirmed. The attestation-tier field is informational; Verifiers MUST NOT rely on it as authoritative when contradicted by the evidence content.¶

15.1. Edit Graph Hash

The edit-graph-hash (edit-delta key 5) provides a cryptographic commitment to the full editing trajectory within a checkpoint interval. It MUST be present in ENHANCED and MAXIMUM content tiers and MAY be present in CORE.¶

The Attestation Environment MUST compute the edit-graph-hash as follows:¶

edit-graph-input = [
    cursor-positions,    ; [* uint] char offsets, 100ms sample
    revision-depths,     ; [* uint] edit depth at each sample
    pause-durations      ; [* uint] inter-keystroke gaps in ms
]

edit-graph-hash = H(
    "CPoE-EditGraph-v1" ||
    CBOR-encode(edit-graph-input)
)

Where H is the Evidence Packet's selected hash function and CBOR-encode produces deterministic CBOR per Section 4.2.1 of [RFC8949]. The cursor-positions array MUST contain cursor position samples at minimum 100ms intervals. The revision-depths array MUST record the number of prior edits at each cursor position at the same sample rate. The pause-durations array MUST record all inter-keystroke intervals exceeding 500ms. Arrays MUST be truncated to the 10,000 most recent samples measured from the current checkpoint boundary.¶

When the edit-graph-hash is present, it is entangled into the SWF seed derivation (Section 16.4).¶

15.2. Edit Graph Histograms

Edit-delta keys 9-11 carry 8-bin histograms summarizing the editing trajectory. These fields MUST be present in MAXIMUM content tier and MUST be absent in CORE. They MAY be present in ENHANCED. The edit graph is represented as a set of histograms over operation types (cursor trajectory, revision depth) and inter-event timing (pause duration). Each histogram is an array of exactly 8 unsigned integers representing event counts per bin. The histogram bin boundaries and computation procedure are specified in [CPoE-Appraisal].¶

The device-signature in a presence-challenge MUST be a COSE_Sign1 structure [RFC9052] covering the challenge-nonce. The signing key MUST be hardware-bound on the secondary device. The Verifier obtains the corresponding public key through prior device registration (the registration mechanism is out of scope for this document). Platform-specific attestation formats (e.g., Apple App Attest, Android Key Attestation) MAY be carried as the COSE_Sign1 payload to provide hardware-tier evidence alongside the presence proof.¶

Active-probe structures (checkpoint key 14) record challenge-response interactions issued by the Attester or Verifier during the authoring session. Each probe records the probe-type, the stimulus timestamp and payload, and the captured biological response. Galton-board probes (type 1) present a visual randomness challenge whose response distribution is compared against biological invariants. Reflex-gate probes (type 2) measure involuntary motor reflex latency. Spatial-target probes (type 3) measure pointing accuracy to on-screen targets. The response-latency field, when present, MUST equal (response-time minus stimulus-time) in milliseconds. Verifiers appraise active-probe responses as specified in [CPoE-Appraisal].¶

Per-checkpoint physical-state (checkpoint key 11) captures instantaneous thermal and entropy measurements. Packet-level physical-liveness (evidence-packet key 18) provides a session-wide thermal trajectory for replay detection. physical-liveness SHOULD be included in ENHANCED and MAXIMUM profiles. When both are present, Verifiers MUST verify that per-checkpoint thermal values are consistent with the session-wide trajectory.¶

When available, the Attester MAY include inertial-sample data (physical-state key 4) containing tri-axis accelerometer readings sampled during the checkpoint interval. Each sample records the timestamp (milliseconds) and acceleration in micro-g (1e-6 * 9.81 m/s^2) on three orthogonal axes. Inertial data captures mechanical shockwaves from physical keystrokes, enabling cross-modal verification: the Verifier can assess whether the digital IKI signal is consistent with physical keystroke impulses by computing cross-spectral coherence (see [CPoE-Appraisal]). In T1/T2 tiers, inertial data is software-reported and MUST NOT be treated as unforgeable; its value is limited to increasing the dimensionality of data an adversary must fabricate consistently. In T3/T4 tiers where a hardware-isolated sensor provides the readings, inertial coherence provides meaningful anti-injection protection. Inertial samples MUST be normalized to relative deltas from a session baseline to prevent device fingerprinting.¶

The baseline-verification structure (evidence-packet key 19) carries per-session behavioral metrics and, when available, a signed digest of the author's accumulated behavioral baseline. The session-behavioral-summary uses a fixed 9-bin IKI histogram with bin edges at 0, 50, 100, 150, 200, 300, 500, 1000, and 2000 milliseconds. The streaming-stats type within baseline-digest records count, mean, M2 (Welford's sum of squared differences from the mean), min, and max for each tracked metric. This representation supports numerically stable incremental updates without retaining raw sample data. Appraisal of baseline-verification data is specified in [CPoE-Appraisal].¶

15.3. Checkpoint Hash Computation

The checkpoint-hash field MUST be computed as follows:¶

checkpoint-hash = H(
    "CPoE-Checkpoint-v1" ||
    prev-hash ||
    content-hash ||
    CBOR-encode(edit-delta) ||
    CBOR-encode(jitter-binding) ||
    CBOR-encode(physical-state) ||
    process-proof.merkle-root
)

Where H is the Evidence Packet's selected hash function, || denotes concatenation, and CBOR-encode produces deterministic CBOR per Section 4.2.1 of [RFC8949]. The UTF-8 Domain Separation Tag (DST) prefix "CPoE-Checkpoint-v1" MUST be prepended as the first input to prevent cross-context hash collisions. When edit-graph-hash (edit-delta key 5) is present, it is already included within the CBOR-encoded edit-delta and requires no separate term in the checkpoint-hash computation.¶

For the first checkpoint in the initial Evidence Packet of a series (or a standalone packet), prev-hash MUST be set to H(CBOR-encode(document-ref)). This anchors the chain to the document identity. For the first checkpoint in a continuation packet (previous-packet-ref present), prev-hash MUST be set to the final checkpoint-hash of the preceding Evidence Packet (see Section 7.3).¶

When jitter-binding and physical-state fields are absent (CORE profile), the checkpoint-hash MUST be computed without those terms: checkpoint-hash = H("CPoE-Checkpoint-v1" || prev-hash || content-hash || CBOR-encode(edit-delta) || process-proof.merkle-root).¶

15.4. Checkpoint Computation Order

The fields within a checkpoint MUST be computed in the following order:¶

1. When edit-graph-hash is present: compute the edit-graph-hash from the accumulated cursor-positions, revision-depths, and pause-durations arrays per Section 15.1. When histograms are present (MAXIMUM tier): populate the 8-bin arrays per Section 15.2. Assemble the edit-delta structure including these fields.¶

2. Compute the SWF: run the proof-algorithm with the derived seed (which incorporates the edit-graph-hash when present). For modes 20/21, evaluate Argon2id iteratively for the configured number of steps. For mode 10, evaluate Argon2id once then iterate SHA-256 with memory-hard waypoints at every W-th step. Construct the Merkle tree over all intermediate states using tagged hashing (Section 16.5) to obtain the merkle-root (process-proof key 4).¶

3. Derive the shared PRK and per-field keys via the two-stage HKDF hierarchy (Section 16.8.1).¶

4. Compute the jitter-tag using the tag-key and jitter-binding.intervals as HMAC input. Assemble the jitter-binding structure (intervals, entropy-estimate, jitter-tag).¶

5. Compute the entangled-binding using the binding-key and prev-hash, content-hash, jitter-binding, and physical-state as HMAC input.¶

6. Compute the checkpoint-hash over the DST "CPoE-Checkpoint-v1", prev-hash, content-hash, edit-delta, jitter-binding, physical-state, and merkle-root.¶

This ordering ensures that each subsequent computation can reference the outputs of prior steps. Implementations MUST follow this order to produce interoperable checkpoints.¶

15.5. Evidence Protection

For T3 and T4 Attestation Tiers, Evidence Packets MUST be wrapped in a COSE_Sign1 envelope [RFC9052]. For T1 and T2 tiers, COSE_Sign1 wrapping is RECOMMENDED. The COSE_Sign1 payload is the complete CBOR-encoded evidence-packet including tag 1129336645; ES256 or EdDSA is RECOMMENDED for the algorithm identifier.¶

For T3/T4 tiers, the signing key MUST be bound to a hardware Secure Element (TPM or platform SE). For T1/T2 tiers, a software-managed key is acceptable.¶

When COSE_Sign1 wrapping is not used (e.g., offline file-based conveyance), the Evidence Packet's integrity relies solely on the internal hash chain. Relying Parties MUST evaluate the trust implications of unwrapped Evidence.¶

For online conveyance, COSE_Sign1-wrapped Evidence Packets can be encapsulated within a Conceptual Message Wrapper (CMW) for transport via the SEAT cmw_attestation TLS extension [SEAT-EXPAT]. This enables CPoE Evidence to be delivered alongside platform attestation evidence in a single post-handshake authentication exchange, which is the preferred attestation timing model [SEAT-Timing]. The SEAT use cases [SEAT-UseCases] identify runtime attestation and operation-triggered re-attestation as key requirements, both of which CPoE's continuous checkpoint model satisfies.¶

15.6. ASCII-Armored Encoding

Evidence Packets and Attestation Results MAY be encoded in an ASCII-armored representation for text-based transport or archival. The format uses -----BEGIN CPoE EVIDENCE----- / -----END CPoE EVIDENCE----- boundaries for Evidence Packets (.cpoe) and -----BEGIN CPoE WAR----- / -----END CPoE WAR----- for Attestation Results (.cwar).¶

The payload is Base64-encoded ([RFC4648], Section 4) with lines not exceeding 76 characters. The payload MUST be the complete CBOR-encoded structure including the CBOR semantic tag (and COSE_Sign1 envelope when present). No key-value headers are permitted between the boundary line and the Base64 block. Implementations MUST accept both armored and raw CBOR encodings.¶

16.1. SWF Construction Summary

The SWF construction, verification protocol, Fiat-Shamir sample derivation, and Merkle tree construction are defined normatively in [PoSME]. CPoE implementations MUST conform to the PoSME specification for all generic SWF operations. The CPoE-specific domain separation tag prefix is "CPoE-" (e.g., "CPoE-salt-v1", "CPoE-Fiat-Shamir-v1"). PoSME defines the algorithm; CPoE defines the application-specific seed derivation and binding computations below.¶

16.2. Verification

Verification procedures for all three modes (10, 20, 21) are specified in [PoSME]. CPoE Verifiers MUST additionally verify the CPoE-specific seed derivation (Section 16.4) and entangled binding (Section 16.8) after completing the generic SWF verification.¶

16.3. Fiat-Shamir and Merkle Construction

Fiat-Shamir sample derivation and Merkle tree construction follow [PoSME] with the "CPoE-Fiat-Shamir-v1" domain separation tag. See [PoSME] for the normative specification.¶

16.4. SWF Seed Derivation

To prevent cross-mode seed collisions, the seed derivation MUST include the proof-algorithm identifier as the first term after the version prefix, providing domain separation between modes. The identifier is encoded as a single byte via I2OSP(proof-algorithm, 1).¶

For swf-argon2id (Mode 20), the SWF seed for each checkpoint MUST be derived as:¶

seed = H(
    "CPoE-SWF-Seed-v1" ||
    I2OSP(20, 1) ||
    prev-hash ||
    CBOR-encode(jitter-binding.intervals) ||
    CBOR-encode(physical-state) ||
    edit-graph-hash
)

When edit-graph-hash is absent, the seed MUST be computed without the final term. Mode 10 (swf-sha256) uses the same derivation with I2OSP(10, 1). Mode 21 (swf-argon2id-entangled) additionally includes prev-swf-output (the final Argon2id state from the immediately preceding checkpoint) after prev-hash, creating a strict cryptographic dependency chain: each checkpoint's SWF cannot begin until the previous checkpoint's SWF has completed.¶

When a verifier-nonce is present ([CPoE-Anchoring]), the nonce MUST be inserted into the seed derivation after prev-swf-output (for Mode 21) or after prev-hash (for Modes 10/20), before any behavioral data. When both verifier-nonce and beacon-anchor are present in the seed, the concatenation order MUST be: prev-hash || verifier-nonce || beacon-anchor || jitter-sample. When edit-graph-hash is present, it MUST be the final term in the seed derivation, after all behavioral data and any beacon-anchor value.¶

For the first checkpoint (sequence = 1), all modes use:¶

seed = H(
    "CPoE-SWF-Seed-v1" ||
    CBOR-encode(document-ref) ||
    initial-jitter-sample
)

The first checkpoint seed does not include edit-graph-hash because no editing trajectory has accumulated at session start.¶

Where initial-jitter-sample is a minimum 32-byte sample of behavioral entropy collected before the first checkpoint. When jitter-binding and physical-state are absent (CORE profile without behavioral data), the seed MUST incorporate at least the prev-hash and a locally-generated 32-byte random nonce: seed = H("CPoE-SWF-Seed-v1" || prev-hash || local-nonce). For the first checkpoint, the nonce provides non-determinism when initial-jitter-sample is unavailable. Implementations MUST NOT use a fully deterministic seed derivation.¶

16.5. Merkle Tree Construction

The SWF Merkle tree construction (domain-separated tagged hashing per [RFC6962] with 0x00/0x01/0x02 prefix tags) is specified in [PoSME]. The Merkle root is stored in process-proof.merkle-root (key 4).¶

16.6. Mandatory SWF Parameters

Conforming Attesters SHOULD use the following minimum SWF parameters for each Evidence Content Tier. The underlying SWF algorithm is defined in [PoSME]; these values are CPoE-specific calibration parameters (see Section 17) and may be revised based on deployment experience.¶

For swf-argon2id (20) and swf-argon2id-entangled (21):¶

For swf-sha256 (10):¶

The waypoint-interval and waypoint-memory parameters MUST be declared in proof-params (keys 5 and 6) for Mode 10 Evidence. Verifiers MUST reject Mode 10 Evidence that omits these parameters.¶

Verifiers MUST reject Evidence where declared proof-params are below the mandatory minimums for the claimed content tier.¶

Expected wall-clock times for swf-argon2id modes on reference hardware (DDR4, approximately 25 GB/s memory bandwidth [JESD79-4]): each Argon2id step with t=1, m=65536 KiB requires approximately 100ms [Biryukov2016]. Target duty cycles at 30-second default checkpoint intervals: CORE approximately 30% (90 steps, ~9s), ENHANCED approximately 50% (150 steps, ~15s), MAXIMUM approximately 70% (210 steps, ~21s). For ENHANCED and MAXIMUM, entangled mode (swf-argon2id-entangled) is MANDATORY per Section 16.7.¶

For swf-sha256 mode, the initial Argon2id evaluation requires approximately 50-100ms; subsequent SHA-256 steps add approximately 0.1ms per 1000 steps.¶

16.7. Entangled Mode Requirement

Attesters claiming ENHANCED or MAXIMUM content tier with swf-argon2id MUST use swf-argon2id-entangled (21) instead of swf-argon2id (20). This ensures that each checkpoint's SWF computation depends on the previous checkpoint's final state, creating a strict inter-checkpoint sequential dependency that eliminates parallel pre-computation. Verifiers MUST reject ENHANCED or MAXIMUM Evidence that uses proof-algorithm 20 instead of 21, assigning verdict invalid (4).¶

16.8. Entangled Binding Computation

When present, the entangled-binding field (checkpoint key 12) MUST be computed as HMAC-H [RFC2104] with keys derived via the two-stage HKDF hierarchy defined below.¶

PRK = HKDF-Extract(
    salt = "CPoE-key-derivation-v1",
    IKM  = process-proof.merkle-root || process-proof.input
)
binding-key = HKDF-Expand(PRK, "CPoE-entangled-binding-v1", hash_len)
tag-key     = HKDF-Expand(PRK, "CPoE-jitter-tag-v1", hash_len)

binding-input = prev-hash || content-hash ||
                CBOR-encode(jitter-binding) ||
                CBOR-encode(physical-state)
entangled-binding = HMAC-H(binding-key, binding-input)

16.9. Jitter Tag Computation

When present, the jitter-tag field (jitter-binding key 3) MUST be computed as HMAC-H using the tag-key derived from the shared PRK (see Section 16.8.1):¶

tag-input = CBOR-encode(jitter-binding.intervals)
jitter-tag = HMAC-H(tag-key, tag-input)

The jitter-tag binds the timing measurements to the checkpoint's SWF computation, preventing transplantation of jitter data from a different session. It is subject to the same adversarial Attester limitation as the entangled-binding (Section 19.9).¶

NOTE: In the adversarial Attester model, the Attester generates both the SWF output (from which the binding keys are derived) and the input data. The entangled-binding and jitter-tag therefore provide data integrity binding but do not prevent an adversarial Attester from computing tags over fabricated data. Their security value is limited to ensuring internal consistency within an honestly-generated checkpoint. See Section 19.¶

16.10. Temporal Anchoring Mechanisms

CPoE defines three temporal anchoring mechanisms that bind checkpoints to external time sources, forming a hierarchy of increasing assurance:¶

An Evidence Packet MAY include any combination. When multiple anchoring mechanisms are present, the Verifier SHOULD use the strongest available: verifier-nonce > witness-anchor > beacon-anchor. Attesters claiming T2 or higher assurance SHOULD include a witness-anchor in every checkpoint. The Evidence Packet MUST NOT claim a tier higher than T1 if any checkpoint lacks a valid witness-anchor.¶

The full specification of beacon-anchored binding, witness-anchored nonce binding (including the witness service protocol, nonce expiry, duplicate checks, transparency log, and CDDL definitions), and verifier-nonce binding is provided in [CPoE-Anchoring].¶

16.11. Security Bound

The SWF security bound and seed grinding resistance proof are specified in [PoSME]. In summary: an adversary who skips fraction f of steps is detected with probability 1-(1-f)^k where k is the number of sampled proofs. Seed grinding is strictly anti-profitable for all skip fractions and sample counts (see [PoSME] for the formal proof). These bounds apply independently to each CPoE checkpoint.¶

16.12. Hardware-Anchored Time (HAT)

Hardware-Anchored Time (HAT) binds SWF computations to TPM-attested clock readings at T3/T4 tiers. HAT is specified in [RATS-HAT]. Attesters claiming T3/T4 MUST include HAT proofs in checkpoint key 15.¶

18.1. CBOR Tags

This document requests registration of two CBOR tags in the "CBOR Tags" registry per RFC 8949, Section 9.2:¶

Tag 1129336645:¶

Tag:

1129336645¶

Data Item:

map¶

Semantics:

CPoE Evidence Packet (see Section 15 of this document)¶

Point of Contact:

David Condrey (david@writerslogic.com)¶

Description of Semantics:

[this document]¶

Tag 1129791826:¶

Tag:

1129791826¶

Data Item:

map¶

Semantics:

CPoE Attestation Result (see [CPoE-Appraisal])¶

Point of Contact:

David Condrey (david@writerslogic.com)¶

Description of Semantics:

[this document], [CPoE-Appraisal]¶

18.2. Note on SMI Private Enterprise Number

This specification does not require or register an SMI Private Enterprise Number. WritersLogic Inc (PEN 65074) is the author's organizational affiliation and is noted here for transparency; no IANA action is requested for this PEN.¶

18.3. EAT Profile

This document requests registration of the following EAT profile in the "EAT Profiles" registry (or its successor registry established by [RFC9711] or the EAR specification):¶

Profile Name:

CPoE Attestation Result Profile¶

Profile URI:

urn:ietf:params:rats:eat:profile:cpoe:1.0¶

Description:

Profile for Cryptographic Proof of Effort (CPoE) Attestation Results (WAR format) as defined in [CPoE-Appraisal]. The CPoE Evidence Packet format uses a domain-specific CBOR structure (tag 1129336645) that is not an EAT token; this profile URI identifies the Verifier output format. See Section 6.4 for the architectural rationale.¶

Reference:

[this document]¶

Change Controller:

David Condrey (david@writerslogic.com)¶

18.4. Media Types

This document requests provisional registration of the following media types in the Standards tree per [RFC6838]:¶

18.5. TLS Exporter Label

This document requests registration of the following TLS exporter label in the "TLS Exporter Labels" registry defined in [RFC5705]:¶

Value:

EXPORTER-CPoE-channel-binding¶

DTLS-OK:

Y¶

Recommended:

N¶

Reference:

[this document]¶

18.6. Future Registry Considerations

This specification and its companion [CPoE-Appraisal] define several enumerated code points in their CDDL schemas. Code points defined in this document: proof-algorithm, attestation-tier, content-tier, hash-algorithm, hash-salt-mode, binding-type, probe-type, and confidence-tier. Code points defined in [CPoE-Appraisal]: verdict, absence-type, and cost-unit. During the Experimental phase, these values are defined inline in the CDDL and do not require separate IANA registries. Extension keys in the evidence-packet and checkpoint structures use integer values 100 or greater (keys 0-99 are reserved for this specification).¶

If this specification advances beyond Experimental status, IANA registries with "Specification Required" or "Expert Review" policies will be established for these code points to enable interoperable extension.¶

19.1. Security Layer Model

CPoE security guarantees operate at three distinct layers with different assurance properties. Verifiers MUST NOT treat lower layers as providing the formal guarantees of higher layers.¶

Layer 1, Behavioral Authentication (Primary):

Behavioral signals -- inter-keystroke timing entropy (SNR, spectral slope), cognitive load correlation (CLC), error correction topology, editing trajectory analysis, and session consistency -- provide the primary evidence of human cognitive involvement. These mechanisms detect fabricated behavioral data by exploiting the computational difficulty of simultaneously satisfying multiple independent statistical constraints that characterize biological motor control. Behavioral authentication is the core value proposition of CPoE. Thresholds are grounded in the keystroke dynamics literature [Monrose2000][Monaco2018][Salthouse1986][Dhakal2018] and calibrated against real-world composition data [ScholaWrite][ScholaWriteAugmented]. Single-feature timing approaches are demonstrably insecure [Condrey2026Attack]; the multi-dimensional cross-domain entanglement architecture is a direct response to those attack classes.¶

Layer 2, Temporal Binding (Cryptographic):

The SWF forces minimum real wall-clock cost derivable from Argon2id memory-hardness [RFC9106] and the sequential dependency chain. This is a time-lock that prevents retroactive fabrication of evidence, not a proof of work. With entangled mode at 50% duty cycle, forging N hours of Evidence requires approximately N/2 hours of computation at minimum. This layer complements Layer 1 by ensuring that an adversary cannot generate behavioral evidence after-the-fact.¶

Layer 3, Hardware Attestation (Physical):

T3/T4 non-repudiation via hardware roots of trust provides physical freshness markers non-reproducible by the Attester operator.¶

The forgery cost estimates in the WAR incorporate all three layers. Layer 1 mechanisms inform the forensic-summary and forensic-flag fields. Layer 2 provides the C_swf temporal cost bound. Layer 3 provides the C_hardware cost bound when hardware attestation is present.¶

19.2. Primary Threat: Adversarial Attester

Unlike traditional remote attestation where external adversaries threaten system integrity, CPoE'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.¶

This threat model inversion has fundamental implications:¶

• Software-only attestation (T1) provides minimal assurance since the Attester controls all software¶

• Cryptographic proofs must be bound to physical constraints the Attester cannot circumvent¶

• Behavioral entropy must be economically expensive to forge, not merely cryptographically secure¶

• Trust in Evidence scales with the Attestation Tier and the cost of bypassing its guarantees¶

At T1/T2, the security guarantee is: (a) the SWF imposes a quantifiable wall-clock floor on evidence generation (Layer 2), and (b) an adversary must simultaneously fabricate plausible values across multiple independent behavioral dimensions (IKI distribution, coefficient of variation, Hurst exponent, cognitive load correlation, error correction topology, editing trajectory) that jointly satisfy Verifier forensic analysis. The multi-dimensional fabrication burden is empirically grounded in the keystroke dynamics literature but has not been formally bounded against adaptive adversaries. Single-feature timing forgery is demonstrably feasible [Condrey2026Attack]; the protocol's defense relies on the joint consistency requirement across independent feature classes, which raises the practical cost of forgery but does not provide a cryptographic guarantee. Relying Parties SHOULD calibrate trust in T1/T2 Evidence accordingly.¶

19.3. Retype Attack Defenses

The retype attack (see Section 8.3) is the canonical forgery vector. Defenses are layered:¶

Cognitive Load Correlation (CLC):

Verifiers analyze correlation between content complexity and typing cadence as specified in [CPoE-Appraisal].¶

Error Topology Analysis:

Authentic authoring produces characteristic error patterns: corrections localized near recent insertions, deletion-to-insertion ratios consistent with human cognitive models [Salthouse1986][ScholaWrite][ScholaWriteAugmented], and long-range temporal dependence in revision patterns consistent with 1/f noise in cognitive performance [Orden2003]. Retyping produces either unnaturally low error rates or randomly distributed artificial errors.¶

Temporal Cost:

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

Relying Parties need to be aware that retype attacks remain viable for short documents or high-value targets willing to invest real time. CPoE provides graduated assurance proportional to document length and checkpoint density.¶

19.4. Relay and Replay Attack Defenses

As defined in Section 8.3 and Section 8.3, these attacks are defeated through Physical Freshness anchors binding Evidence to non-reproducible physical state:¶

• Thermal trajectories captured during SWF computation cannot be replayed¶

• Kernel entropy pool deltas are bound to specific execution moments¶

• Out-of-band presence challenges (QR scans) verify real-time physical proximity¶

Verifiers MUST reject Evidence where physical freshness markers are stale, inconsistent with timestamps, or exhibit patterns suggesting simulation.¶

19.5. SWF Acceleration Defenses

As analyzed in Section 8.3, specialized hardware attacks are mitigated by:¶

• Memory-hardness: For modes 20/21, every SWF step is a full Argon2id evaluation bounded by memory bandwidth (approximately 50 GB/s for DDR5 [JESD79-5]), not ALU throughput. ASICs provide minimal advantage per step, and this resistance compounds across all steps in the chain. For mode 10, memory-hard waypoints (Section 16.1) bound the ASIC advantage at waypoint steps to the Argon2id limit.¶

• Hardware-Anchored Time (T3/T4): The HAT temporal sandwich protocol (Section 16.12) brackets each SWF computation with TPM-attested clock readings, preventing time compression even with faster computation. The Verifier checks that the TPM clock delta meets or exceeds the expected SWF duration.¶

• Merkle sampling: Skipping SWF steps is detected probabilistically. With k=100 samples, skipping 5% of steps has >99.4% detection probability. Seed grinding does not improve the adversary's position (see [PoSME]).¶

19.6. Trust Gradation by Tier

Relying Parties SHOULD interpret Evidence according to its Attestation Tier. Detailed per-tier verification constraints are defined in [CPoE-Appraisal].¶

19.7. Forgery Cost Bounds

Implementations SHOULD report quantified forgery cost estimates in Attestation Results. For CORE profile with swf-argon2id (90 steps, m=65536 KiB), each checkpoint requires ~9 seconds of sustained memory-hard computation on consumer hardware (DDR4, ~25 GB/s), a ~30% duty cycle within the 30-second checkpoint interval. Entangled mode creates strict inter-checkpoint sequential dependencies: forging N hours of ENHANCED authorship requires approximately N/2 hours of real computation on consumer hardware.¶

Applying a conservative ASIC advantage factor of 10x, a committed adversary reduces this to approximately N/20 hours. For a 5-hour document, the adversary cost is approximately 15 minutes of ASIC computation plus capital cost of hardware. The forgery cost scales linearly with session duration; parallel machines can produce independent forgeries but cannot accelerate a single session's sequential chain. Relying Parties SHOULD evaluate forgery cost against the adversary's economic context, not the honest Attester's computation time.¶

Detailed ASIC advantage analysis (TMTO bounds, memory bandwidth scaling, silicon optimization factors) is provided in [CPoE-Appraisal]. Verifiers SHOULD use an ASIC advantage factor of 10x when computing c-swf in forgery-cost-estimate.¶

19.8. Denial of Service

SWF verification is asymmetric: Merkle-sampled proofs verify in O(k) versus O(n) generation, where k is the sample count and n is the step count. For swf-argon2id modes, each sampled proof requires one Argon2id evaluation (~100ms), so verification cost is approximately k * 100ms (2s for CORE, 5s for ENHANCED, 10s for MAXIMUM). This is substantially less than generation cost (9-21s per checkpoint). Implementations SHOULD implement rate limiting on Evidence submission.¶

19.9. Consistency Binding Limitations

The entangled-binding and jitter-tag fields are HMAC values keyed from the SWF output via a two-stage HKDF hierarchy (Section 16.8.1). In the adversarial Attester model, the Attester generates the SWF output and therefore knows the binding keys. An adversarial Attester can compute valid bindings over fabricated data (synthetic jitter, manufactured physical state). These fields provide internal consistency checking but do not prevent forgery by the Attester. Their value is limited to:¶

• Binding data fields to the SWF computation within an honestly-generated checkpoint, ensuring the data was committed at checkpoint-generation time (when the SWF output was computed) rather than substituted afterward¶

• Providing internal consistency verification (note: the binding keys are derivable from the public merkle-root field; these bindings do not provide third-party tamper detection)¶

• In T3/T4 tiers, the packet-level hardware-bound signature (see Section 11) provides the actual integrity guarantee¶

• When beacon-anchoring ([CPoE-Anchoring]) is used, the binding keys incorporate externally-verifiable randomness, providing temporal anchoring even without hardware attestation¶

19.10. Edit Graph Commitment Limitations

The edit-graph-hash (Section 15.1) entangles editing trajectory data into the SWF seed, binding the claimed editing pattern to the SWF time proof. This binding ensures that an adversary cannot substitute a different editing pattern after SWF computation without recomputing the entire chain.¶

However, the edit graph commitment does not prove that the committed data reflects genuine human authoring. In T1/T2 tiers, the adversarial Attester controls the Attestation Environment and can fabricate plausible cursor positions, revision depths, and pause durations before computing the SWF. The edit-graph-hash adds one additional dimension of data that must be fabricated consistently, but does not create a cryptographic barrier to fabrication.¶

The MAXIMUM-tier histograms (Section 15.2) enable statistical analysis of editing patterns by Verifiers. These histograms may reveal anomalies such as unnaturally uniform distributions, missing burstiness in pause patterns, or zero revision depth across all regions. Such statistical tests are probabilistic and can be defeated by a sufficiently sophisticated adversary. Verifiers SHOULD treat histogram analysis as one signal among many, not as definitive authentication.¶

19.11. Selective Checkpoint Omission

The hash chain prevents modification of included checkpoints but does not prevent omission of trailing checkpoints. An adversary can truncate the chain at any point and claim the authoring session ended there. Without external anchoring, the Verifier cannot determine whether additional checkpoints were generated and discarded. Witness-anchored nonce binding ([CPoE-Anchoring]) with transparency logging provides detection of omission: the witness log records the checkpoint count per session, enabling Verifiers to detect gaps. Deployments where selective omission is a concern SHOULD require witness anchoring with transparency logging. Beacon anchoring ([CPoE-Anchoring]) provides weaker omission detection: the Verifier can verify that the final checkpoint's beacon round is consistent with the claimed session end time, but cannot detect omitted intermediate checkpoints.¶

19.12. Physical Freshness by Tier

In T1 (Software-Only) and T2 (Attested Software) tiers, the Attester controls all software including the operating system. Physical state readings (thermal trajectories, kernel entropy deltas) are obtained from OS interfaces that the adversarial Attester can intercept or fabricate. Verifiers MUST NOT treat physical-state or physical-liveness fields as evidence of physical freshness in T1/T2 Evidence Packets. Their value in these tiers is limited to increasing the dimensionality of data that an adversary must fabricate consistently.¶

Physical freshness provides meaningful anti-replay protection only in T3/T4 tiers where hardware attestation binds physical state readings to a trusted execution environment.¶

19.13. Implementation Security Requirements

Conforming implementations MUST:¶

• Use constant-time comparison for all cryptographic operations¶

• Zero sensitive memory (keys, jitter data) after use¶

• Validate all input lengths and formats before processing¶

• Reject Evidence with inconsistent internal state (e.g., checkpoint-hash verification failure)¶

• Enforce a maximum Evidence Packet size of 16 MiB after CBOR decoding¶

• Enforce a maximum CBOR nesting depth of 32 levels during parsing¶

• Reject Evidence Packets containing more than 10,000 checkpoints¶

T3/T4 implementations MUST additionally:¶

• Store signing keys exclusively in hardware Secure Elements¶

• Bind SWF seeds to TPM monotonic counters¶

• Verify platform integrity before Evidence generation¶

19.14. Internationalization and Input Method Considerations

The behavioral model described in this specification is calibrated primarily against alphabetic keyboard input (Latin script, QWERTY layout). Input Method Editors (IMEs) for CJK languages (Chinese Pinyin/Wubi, Japanese Kana/Romaji, Korean Hangul) produce fundamentally different keystroke patterns: phonetic key sequences followed by candidate selection, with composition events that may not generate standard key-down/key-up pairs. Similarly, right-to-left scripts (Arabic, Hebrew) produce bidirectional cursor movement patterns that differ from left-to-right editing trajectories.¶

Implementations MUST capture IME composition events as behavioral input alongside raw keystrokes. Verifiers MUST NOT apply alphabetic-typing forensic thresholds (Hurst exponent ranges, IKI distribution expectations) to Evidence generated with IME-based input without appropriate recalibration. The jitter-binding structure captures inter-event intervals regardless of input method; the forensic interpretation of those intervals is input-method-dependent and is specified in [CPoE-Appraisal].¶

Future revisions of this specification may define input-method profile identifiers to enable Verifiers to select appropriate forensic baselines automatically.¶

19.15. Signing Key Lifecycle and Rotation

For T1/T2 tiers where signing keys are software-managed, the Attester SHOULD implement a key rotation policy to limit the impact of key compromise. The following normative guidelines apply:¶

1. Rotation frequency: Software-managed signing keys SHOULD be rotated at least every 90 days or after generating 10,000 Evidence Packets, whichever comes first. Attesters MAY rotate more frequently.¶

2. Key binding: Each Evidence Packet's COSE_Sign1 envelope identifies the signing key. When a key is rotated, the Attester MUST begin using the new key for all subsequent Evidence Packets. Evidence Packets MUST NOT be re-signed with a new key after initial generation.¶

3. Key continuity: To allow Verifiers to validate older Evidence Packets, the Attester SHOULD publish a key history document (format out of scope) linking retired public keys to their validity periods. Verifiers MUST accept Evidence signed with a retired key if the Evidence creation timestamp falls within the key's validity period. Verifiers SHOULD maintain signing key history for at least 365 days.¶

4. Compromise response: If a signing key is suspected compromised, the Attester MUST immediately cease using it and SHOULD publish a revocation. Evidence Packets signed with a compromised key after the suspected compromise date SHOULD be treated as inconclusive by Verifiers.¶

For T3/T4 tiers, key management is governed by the hardware Secure Element's lifecycle. Key rotation in hardware tiers typically requires device re-provisioning, which is outside the scope of this specification.¶

20.1. Data Minimization

CPoE Evidence Packets do not contain document content. Content binding uses cryptographic hashes (H, as selected by hash-algorithm) which are computationally irreversible. The author-salted mode (hash-salt-mode=1) provides additional protection by preventing rainbow-table correlation across documents.¶

However, hash-based content binding provides confidentiality only when the document space is effectively unbounded. In constrained domains where the set of candidate documents is small (e.g., standardized legal forms, academic paper templates, published preprints), an observer with access to the candidate set can compute hashes and match against content-hash values in checkpoints, revealing document identity and editing trajectory without accessing the document itself. Authors working in constrained document spaces MUST use author-salted mode to prevent this correlation. Even with salting, the checkpoint count and temporal pattern of an Evidence Packet may reveal document length and composition timeline; authors should consider this metadata exposure when deciding whether to share Evidence.¶

20.2. Behavioral Fingerprinting

Jitter sequences in ENHANCED and MAXIMUM profiles constitute behavioral biometrics. Keystroke dynamics are classified as biometric data under multiple legal frameworks including GDPR Article 4(14), CCPA/CPRA, and Illinois BIPA. Deployments that collect, store, or transmit jitter-binding data MUST comply with applicable biometric data regulations, which may require explicit informed consent, purpose limitation, data retention limits, and right-to-deletion mechanisms. To protect author privacy, Verifiers are expected to:¶

• Discard jitter data after the verification session completes¶

• Avoid correlating jitter across multiple Evidence Packets to prevent author deanonymization¶

• Use jitter data solely for authenticity verification¶

Attesters MUST apply a minimum quantization step of 5 milliseconds to all inter-keystroke interval values before encoding in jitter-binding. Finer resolution MUST NOT be used without explicit operator configuration and documented consent.¶

20.3. Physical State Leakage

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

Inertial samples, when present, carry additional fingerprinting risk: accelerometer frequency response and noise floor characteristics can identify specific device models. Implementations MUST normalize inertial data to relative deltas from a per-session baseline and SHOULD apply the same quantization and privacy budget constraints as jitter data.¶

20.4. Unlinkability

Authors who wish to remain pseudonymous SHOULD use per-document signing keys and the author-salted content binding mode to prevent cross-document linkage.¶

20.5. Privacy Budget

Each Evidence Packet released by an Attester discloses behavioral telemetry that incrementally reduces the author's anonymity set. Attesters SHOULD maintain an accounting of cumulative privacy exposure and enforce budgetary limits on high-fidelity data disclosure:¶

Jitter resolution:

Attesters SHOULD default to the coarsest quantization (5ms) that satisfies the target content tier's entropy threshold. Finer resolution (1ms) SHOULD only be emitted when explicitly required by the Verifier's appraisal policy and the author has consented to the increased disclosure.¶

Physical-state detail:

CORE and ENHANCED profiles SHOULD omit per-checkpoint physical-state (key 11) unless required by the deployment's appraisal policy. When included, thermal values MUST be normalized to relative deltas.¶

Session-level budget:

Attesters SHOULD track the cumulative number of Evidence Packets generated for a given author identity (or signing key). When the cumulative count exceeds 1,000 packets with the same behavioral source, the Attester SHOULD warn the author that cross-document stylometric correlation risk is elevated and SHOULD recommend key rotation and increased jitter quantization.¶

Selective disclosure:

When the Relying Party's trust requirements are satisfied by a lower content tier, the Attester SHOULD generate Evidence at the lowest tier sufficient for the use case, minimizing the behavioral data emitted.¶

21.1. Normative References

[PoSME]

Condrey, D., "Proof of Sequential Memory Execution (PoSME)", Work in Progress, Internet-Draft, draft-condrey-posme-00, May 2026, <https://datatracker.ietf.org/doc/html/draft-condrey-posme-00>.

[RFC2104]

Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, <https://www.rfc-editor.org/rfc/rfc2104>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC4648]

Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/rfc/rfc4648>.

[RFC5705]

Rescorla, E., "Keying Material Exporters for Transport Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, March 2010, <https://www.rfc-editor.org/rfc/rfc5705>.

[RFC5869]

Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010, <https://www.rfc-editor.org/rfc/rfc5869>.

[RFC8017]

Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, "PKCS #1: RSA Cryptography Specifications Version 2.2", RFC 8017, DOI 10.17487/RFC8017, November 2016, <https://www.rfc-editor.org/rfc/rfc8017>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC8610]

Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, <https://www.rfc-editor.org/rfc/rfc8610>.

[RFC8949]

Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, <https://www.rfc-editor.org/rfc/rfc8949>.

[RFC9052]

Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, August 2022, <https://www.rfc-editor.org/rfc/rfc9052>.

[RFC9106]

Biryukov, A., Dinu, D., Khovratovich, D., and S. Josefsson, "Argon2 Memory-Hard Function for Password Hashing and Proof-of-Work Applications", RFC 9106, DOI 10.17487/RFC9106, September 2021, <https://www.rfc-editor.org/rfc/rfc9106>.

[RFC9266]

Whited, S., "Channel Bindings for TLS 1.3", RFC 9266, DOI 10.17487/RFC9266, July 2022, <https://www.rfc-editor.org/rfc/rfc9266>.

[RFC9334]

Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, <https://www.rfc-editor.org/rfc/rfc9334>.

[RFC9711]

Lundblade, L., Mandyam, G., O'Donoghue, J., and C. Wallace, "The Entity Attestation Token (EAT)", RFC 9711, DOI 10.17487/RFC9711, April 2025, <https://www.rfc-editor.org/rfc/rfc9711>.

21.2. Informative References

[AG-Human-Authored]

The Authors Guild, "Authors Guild Launches "Human Authored" Certification to Preserve Authenticity in Literature", January 2025, <https://authorsguild.org/news/ag-launches-human-authored-certification-to-preserve-authenticity-in-literature/>.

[Amazon-KDP-AI]

Amazon.com, Inc., "Kindle Direct Publishing Content Guidelines", 2025, <https://kdp.amazon.com/en_US/help/topic/G200672390>.

[Biryukov2016]

Biryukov, A., Dinu, D., and D. Khovratovich, "Argon2: New Generation of Memory-Hard Functions for Password Hashing and Other Applications", IEEE EuroS&P pp. 292-302, 2016, <https://doi.org/10.1109/EuroSP.2016.31>.

[Boneh2018]

Boneh, D., Bonneau, J., Bunz, B., and B. Fisch, "Verifiable Delay Functions", CRYPTO 2018, 2018, <https://doi.org/10.1007/978-3-319-96884-1_25>.

[C2PA]

Coalition for Content Provenance and Authenticity, "C2PA Technical Specification", Version 2.2, 2024, <https://c2pa.org/specifications/specifications/2.2/specs/C2PA_Specification.html>.

[Condrey2026Attack]

Condrey, D., "On the Insecurity of Keystroke-Based AI Authorship Detection: Timing-Forgery Attacks Against Motor-Signal Verification", arXiv 2601.17280, 2026, <https://arxiv.org/abs/2601.17280>.

[CPoE-Anchoring]

Condrey, D., "Cryptographic Proof of Effort (CPoE): Temporal Anchoring Extensions", Work in Progress, Internet-Draft, draft-condrey-cpoe-anchoring-00, May 2026, <https://datatracker.ietf.org/doc/html/draft-condrey-cpoe-anchoring-00>.

[CPoE-Appraisal]

Condrey, D., "Cryptographic Proof of Effort (CPoE): Forensic Appraisal and Security Model", Work in Progress, Internet-Draft, draft-condrey-cpoe-appraisal-00, May 2026, <https://datatracker.ietf.org/doc/html/draft-condrey-cpoe-appraisal-00>.

[CPoE-UseCases]

Condrey, D., "Cryptographic Proof of Effort (CPoE): Use Cases and Deployment Considerations", Work in Progress, Internet-Draft, draft-condrey-cpoe-usecases-00, May 2026, <https://datatracker.ietf.org/doc/html/draft-condrey-cpoe-usecases-00>.

[Dhakal2018]

Dhakal, V., Feit, A.M., Kristensson, P.O., and A. Oulasvirta, "Observations on Typing from 136 Million Keystrokes", ACM CHI 2018, 2018, <https://doi.org/10.1145/3173574.3174220>.

[Dolev-Yao]

Dolev, D. and A. Yao, "On the Security of Public Key Protocols", IEEE Transactions on Information Theory 29(2), 198-208, 1983, <https://doi.org/10.1109/TIT.1983.1056650>.

[GPTZero]

GPTZero, Inc., "GPTZero: AI Detection and Writing Process for Google Docs", 2025, <https://gptzero.me/chrome>.

[HaberStornetta1991]

Haber, S. and W.S. Stornetta, "How to Time-Stamp a Digital Document", Journal of Cryptology 3(2), 99-111, 1991, <https://doi.org/10.1007/BF00196791>.

[HHS-AI-RFI]

U.S. Department of Health and Human Services, Office of the National Coordinator for Health Information Technology, "Request for Information: Accelerating the Adoption and Use of Artificial Intelligence as Part of Clinical Care", Federal Register 2025-23641, December 2025, <https://www.regulations.gov/docket/HHS-ONC-2026-0001>.

[JESD79-4]

JEDEC Solid State Technology Association, "DDR4 SDRAM Standard", JEDEC JESD79-4D, 2012, <https://www.jedec.org/standards-documents/docs/jesd79-4a>.

[JESD79-5]

JEDEC Solid State Technology Association, "DDR5 SDRAM Standard", JEDEC JESD79-5D, 2020, <https://www.jedec.org/standards-documents/docs/jesd79-5d>.

[Liang2023]

Liang, W., Yuksekgonul, M., Mao, Y., Wu, E., and J. Zou, "GPT Detectors Are Biased Against Non-Native English Writers", Patterns 4(7), 100779, July 2023, <https://doi.org/10.1016/j.patter.2023.100779>.

[Monaco2018]

Monaco, J.V., "SoK: Keylogging Side Channels", IEEE Symposium on Security and Privacy pp. 211-228, 2018, <https://doi.org/10.1109/SP.2018.00026>.

[Monrose2000]

Monrose, F. and A. Rubin, "Keystroke Dynamics as a Biometric for Authentication", Future Generation Computer Systems 16(4), 351-359, 2000, <https://doi.org/10.1016/S0167-739X(99)00059-X>.

[NIST-AI-Agents-RFI]

National Institute of Standards and Technology, "Request for Information Regarding Security Considerations for Artificial Intelligence Agents", Federal Register 2026-00206, January 2026, <https://www.regulations.gov/docket/NIST-2025-0035>.

[Orden2003]

Van Orden, G.C., Holden, J.G., and M.T. Turvey, "Self-Organization of Cognitive Performance", Journal of Experimental Psychology: General 132(3), 331-350, 2003, <https://doi.org/10.1037/0096-3445.132.3.331>.

[RATS-HAT]

Condrey, D., "Hardware Attestation of Time (HAT): TPM-Based Temporal Binding for Remote Attestation", Work in Progress, Internet-Draft, draft-condrey-hat-00, 2026, <https://datatracker.ietf.org/doc/html/draft-condrey-hat-00>.

[RATS-Models]

Birkholz, H., Eckel, M., Pan, W., and E. Voit, "Reference Interaction Models for Remote Attestation Procedures", Work in Progress, Internet-Draft, draft-ietf-rats-reference-interaction-models-15, 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-rats-reference-interaction-models-15>.

[RFC3161]

Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)", RFC 3161, DOI 10.17487/RFC3161, August 2001, <https://www.rfc-editor.org/rfc/rfc3161>.

[RFC3552]

Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, <https://www.rfc-editor.org/rfc/rfc3552>.

[RFC6838]

Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <https://www.rfc-editor.org/rfc/rfc6838>.

[RFC6962]

Laurie, B., Langley, A., and E. Kasper, "Certificate Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, <https://www.rfc-editor.org/rfc/rfc6962>.

[RFC6973]

Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, <https://www.rfc-editor.org/rfc/rfc6973>.

[Salthouse1986]

Salthouse, T.A., "Perceptual, Cognitive, and Motoric Aspects of Transcription Typing", Psychological Bulletin 99(3), 303-319, 1986, <https://doi.org/10.1037/0033-2909.99.3.303>.

[Sardar-RATS]

Sardar, M.U., "Security Considerations for Remote ATtestation procedureS (RATS)", Work in Progress, Internet-Draft, draft-sardar-rats-sec-cons-02, February 2026, <https://datatracker.ietf.org/doc/html/draft-sardar-rats-sec-cons-02>.

[ScholaWrite]

Wang, L., Lee, M., Volkov, R., Chau, L.T., and D. Kang, "ScholaWrite: A Dataset of End-to-End Scholarly Writing Process", arXiv 2502.02904, 2025, <https://arxiv.org/abs/2502.02904>.

[ScholaWriteAugmented]

Condrey, D., "ScholaWrite-Augmented: Revision-Tracked Scholarly Writing Dataset with Annotated External Insertion Events", GitHub writerslogic/scholawrite-augmented, 2026, <https://github.com/writerslogic/scholawrite-augmented>.

[SEAT-EXPAT]

Sardar, M.U., Fossati, T., Reddy, T., Sheffer, Y., Tschofenig, H., and I. Mihalcea, "Remote Attestation with Exported Authenticators", Work in Progress, Internet-Draft, draft-fossati-seat-expat-01, January 2026, <https://datatracker.ietf.org/doc/html/draft-fossati-seat-expat-01>.

[SEAT-Timing]

Sardar, M.U., "Pre-, Intra- and Post-handshake Attestation", Work in Progress, Internet-Draft, draft-usama-seat-intra-vs-post-03, January 2026, <https://datatracker.ietf.org/doc/html/draft-usama-seat-intra-vs-post-03>.

[SEAT-UseCases]

Mihalcea, I., Sardar, M.U., Fossati, T., Reddy, T., Jiang, Y., and M. Chen, "Use Cases and Properties for Integrating Remote Attestation with Secure Channel Protocols", Work in Progress, Internet-Draft, draft-mihalcea-seat-use-cases-01, January 2026, <https://datatracker.ietf.org/doc/html/draft-mihalcea-seat-use-cases-01>.

[Takens1981]

Takens, F., "Detecting Strange Attractors in Turbulence", Lecture Notes in Mathematics 898, 366-381, 1981, <https://doi.org/10.1007/BFb0091924>.

swf-sha256 (Mode 10) Test Vector

Seed: "cpoe-genesis-v1"
Seed (hex): 63706f652d67656e657369732d7631
Salt: H(0x00 || "CPoE-salt-v1" || seed)

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

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

Steps: 10,000
Waypoint Interval (W): 1000

Salt (hex): 20d10e03c713b5be87fbecccab13465e
             513eac5835e52ac0ac9c8d50dab9fba8

Intermediate States:
  state_0 (Argon2id):
    f4a9461757a2ab266e7572ffbfc662b9
    c3afd5d6b2233d163f0d28add6ed529f
  state_1000 (waypoint, Argon2id):
    2c926557fd907959bcd7a970a42b837c
    3738cf6f104bf862741c38cbe5fd3924
  state_5000 (waypoint, Argon2id):
    35e8e8fb91f7fbe1a4078f42074dc1ea
    a5b3892749170b0892787bbef5f4e6f0
  state_9999 (SHA-256):
    de7e5e1928f5bc4db0f36eb407b67772
    2b4000337ef6c197e91a211220ea58c5
  state_10000 (waypoint, Argon2id, final):
    a207cf20421f2a231503d811352f1b45
    fa75f7819b627f71ae0e7e626f64a51a

swf-argon2id (Mode 20) Test Vector

Seed: "cpoe-genesis-v1"
Seed (hex): 63706f652d67656e657369732d7631

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

Steps: 3

Intermediate States:
  state_0 (Argon2id, seed as password,
           salt=H(0x00 || "CPoE-salt-v1" || seed)):
    f4a9461757a2ab266e7572ffbfc662b9
    c3afd5d6b2233d163f0d28add6ed529f
  state_1 (Argon2id, state_0 as password,
           salt=H(0x01 || "CPoE-salt-v1" || I2OSP(1, 4))):
    c16d4c36d8bec173d03b302740dccb5e
    c221d90d5cfbab4ac852851270a7839f
  state_2 (Argon2id, state_1 as password,
           salt=H(0x01 || "CPoE-salt-v1" || I2OSP(2, 4))):
    6a5e0491d3d27a1880a2896732739cc6
    c279262bb56bd74d20125320bde7ab70
  state_3 (Argon2id, state_2 as password,
           salt=H(0x01 || "CPoE-salt-v1" || I2OSP(3, 4))):
    458670264b4dd3be8598749ad33567d2
    4a4e50eddc2f6b2751ae1f17713a31b1