Remote ATtestation procedureS D. Condrey Internet-Draft Writerslogic Inc Intended status: Informational 6 February 2026 Expires: 10 August 2026 Proof of Process: An Evidence Framework for Digital Authorship Attestation draft-condrey-rats-pop-00 Abstract This document specifies Proof of Process (PoP), an evidence framework for digital authorship attestation. The framework produces tamper- evident, independently verifiable process evidence describing how documents evolve over time, without capturing document content or keystroke data. Proof of Process implements a specialized profile of the Remote ATtestation procedureS (RATS) architecture, extending it with behavioral entropy bindings, Verifiable Delay Function (VDF) temporal proofs, and a taxonomy of absence claims with explicit trust requirements. The specification defines two complementary CBOR- encoded formats: Evidence Packets (.pop) produced by Attesters during document authorship, and Attestation Results (.war) produced by Verifiers after appraising Evidence. The framework is designed around four core principles: privacy by construction (no content storage), zero trust (locally generated, independently verifiable), evidence over inference (observable facts, not conclusions), and cost-asymmetric forgery (expensive to fake, not impossible). This specification does not address AI detection, stylometric analysis, or intent inference. About This Document This note is to be removed before publishing as an RFC. Status of this Memo: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Condrey Expires 10 August 2026 [Page 1] Internet-Draft Proof of Process February 2026 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 10 August 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 9 1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 9 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.2.1. What This Specification Defines . . . . . . . . . . . 11 1.2.2. What This Specification Does NOT Define . . . . . . . 11 1.2.3. Relationship to RATS Architecture . . . . . . . . . . 12 1.3. Design Goals . . . . . . . . . . . . . . . . . . . . . . 12 1.3.1. Privacy by Construction . . . . . . . . . . . . . . . 12 1.3.2. Zero Trust: Locally Generated, Independently Verifiable . . . . . . . . . . . . . . . . . . . . . 13 1.3.3. Evidence Over Inference . . . . . . . . . . . . . . . 13 1.3.4. Cost-Asymmetric Forgery . . . . . . . . . . . . . . . 13 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 14 Condrey Expires 10 August 2026 [Page 2] Internet-Draft Proof of Process February 2026 1.5. Document Structure . . . . . . . . . . . . . . . . . . . 15 1.6. Conventions and Definitions . . . . . . . . . . . . . . . 16 1.6.1. CDDL Notation . . . . . . . . . . . . . . . . . . . . 16 1.6.2. CBOR Encoding . . . . . . . . . . . . . . . . . . . . 16 1.6.3. COSE Signatures . . . . . . . . . . . . . . . . . . . 16 1.6.4. EAT Tokens . . . . . . . . . . . . . . . . . . . . . 17 1.6.5. Hash Function Notation . . . . . . . . . . . . . . . 17 2. Evidence Model . . . . . . . . . . . . . . . . . . . . . . . 17 2.1. RATS Architecture Mapping . . . . . . . . . . . . . . . . 17 2.2. Two Complementary Formats . . . . . . . . . . . . . . . . 18 2.2.1. Evidence Packet (.pop) . . . . . . . . . . . . . . . 18 2.2.2. Attestation Result (.war) . . . . . . . . . . . . . . 18 2.2.3. Format Relationship . . . . . . . . . . . . . . . . . 19 2.3. Evidence Packet Structure . . . . . . . . . . . . . . . . 19 2.3.1. Required Fields . . . . . . . . . . . . . . . . . . . 20 2.3.2. Tiered Optional Sections . . . . . . . . . . . . . . 20 2.3.3. Extensibility . . . . . . . . . . . . . . . . . . . . 21 2.4. Checkpoint Chain . . . . . . . . . . . . . . . . . . . . 21 2.4.1. Checkpoint Structure . . . . . . . . . . . . . . . . 21 2.4.2. Hash Chain Construction . . . . . . . . . . . . . . . 23 2.4.3. MMR Compatibility . . . . . . . . . . . . . . . . . . 23 2.5. Document Binding . . . . . . . . . . . . . . . . . . . . 24 2.5.1. Content Hash Binding . . . . . . . . . . . . . . . . 24 2.5.2. Salt Modes for Privacy . . . . . . . . . . . . . . . 24 2.6. Evidence Tiers . . . . . . . . . . . . . . . . . . . . . 25 2.6.1. Basic Tier . . . . . . . . . . . . . . . . . . . . . 25 2.6.2. Standard Tier . . . . . . . . . . . . . . . . . . . . 26 2.6.3. Enhanced Tier . . . . . . . . . . . . . . . . . . . . 26 2.6.4. Maximum Tier . . . . . . . . . . . . . . . . . . . . 27 2.6.5. Tier Selection Guidance . . . . . . . . . . . . . . . 27 2.7. Attestation Result Structure . . . . . . . . . . . . . . 28 2.7.1. Verdict Field . . . . . . . . . . . . . . . . . . . . 28 2.7.2. Confidence Score . . . . . . . . . . . . . . . . . . 29 2.7.3. Verified Claims . . . . . . . . . . . . . . . . . . . 30 2.7.4. Verifier Signature . . . . . . . . . . . . . . . . . 30 2.7.5. Caveats . . . . . . . . . . . . . . . . . . . . . . . 30 2.8. CBOR Encoding . . . . . . . . . . . . . . . . . . . . . . 31 2.8.1. Semantic Tags . . . . . . . . . . . . . . . . . . . . 31 2.8.2. Key Encoding Strategy . . . . . . . . . . . . . . . . 31 2.8.3. Deterministic Encoding . . . . . . . . . . . . . . . 31 2.9. EAT Profile . . . . . . . . . . . . . . . . . . . . . . . 32 2.9.1. Custom EAT Claims . . . . . . . . . . . . . . . . . . 32 2.9.2. AR4SI Trustworthiness Extension . . . . . . . . . . . 32 2.10. Security Considerations . . . . . . . . . . . . . . . . . 33 2.10.1. Tamper-Evidence vs. Tamper-Proof . . . . . . . . . . 33 2.10.2. Independent Verification . . . . . . . . . . . . . . 33 2.10.3. Privacy by Construction . . . . . . . . . . . . . . 34 2.10.4. Attesting Environment Trust . . . . . . . . . . . . 34 Condrey Expires 10 August 2026 [Page 3] Internet-Draft Proof of Process February 2026 3. Jitter Seal: Captured Behavioral Entropy . . . . . . . . . . 34 3.1. Design Principles . . . . . . . . . . . . . . . . . . . . 35 3.2. Jitter Binding Structure . . . . . . . . . . . . . . . . 35 3.2.1. Entropy Commitment (Key 1) . . . . . . . . . . . . . 35 3.2.2. Entropy Sources (Key 2) . . . . . . . . . . . . . . . 36 3.2.3. Jitter Summary (Key 3) . . . . . . . . . . . . . . . 36 3.2.4. Binding MAC (Key 4) . . . . . . . . . . . . . . . . . 37 3.2.5. Raw Intervals (Key 5, Optional) . . . . . . . . . . . 38 3.3. VDF Entanglement . . . . . . . . . . . . . . . . . . . . 38 3.4. Verification Procedure . . . . . . . . . . . . . . . . . 38 3.5. Anomaly Detection . . . . . . . . . . . . . . . . . . . . 40 3.6. Relationship to RATS Evidence . . . . . . . . . . . . . . 40 3.7. Privacy Considerations . . . . . . . . . . . . . . . . . 41 3.7.1. Mitigation Measures . . . . . . . . . . . . . . . . . 41 3.7.2. Disclosure Recommendations . . . . . . . . . . . . . 41 3.8. Security Considerations . . . . . . . . . . . . . . . . . 42 3.8.1. Replay Attacks . . . . . . . . . . . . . . . . . . . 42 3.8.2. Simulation Attacks . . . . . . . . . . . . . . . . . 42 3.8.3. Attesting Environment Trust . . . . . . . . . . . . . 43 4. Verifiable Delay Functions . . . . . . . . . . . . . . . . . 43 4.1. VDF Construction . . . . . . . . . . . . . . . . . . . . 43 4.1.1. Algorithm Registry . . . . . . . . . . . . . . . . . 44 4.1.2. Iterated Hash Construction . . . . . . . . . . . . . 44 4.1.3. Succinct VDF Construction . . . . . . . . . . . . . . 45 4.2. Causality Property . . . . . . . . . . . . . . . . . . . 46 4.2.1. Checkpoint Entanglement . . . . . . . . . . . . . . . 46 4.2.2. Temporal Ordering Without Trusted Time . . . . . . . 47 4.2.3. Backdating Resistance . . . . . . . . . . . . . . . . 47 4.3. Calibration Attestation . . . . . . . . . . . . . . . . . 48 4.3.1. Attestation Structure . . . . . . . . . . . . . . . . 48 4.3.2. Calibration Procedure . . . . . . . . . . . . . . . . 48 4.3.3. Calibration Verification . . . . . . . . . . . . . . 49 4.3.4. Trust Model . . . . . . . . . . . . . . . . . . . . . 50 4.4. Verification Procedure . . . . . . . . . . . . . . . . . 50 4.4.1. Iterated Hash Verification . . . . . . . . . . . . . 50 4.4.2. Succinct VDF Verification . . . . . . . . . . . . . . 51 4.5. Algorithm Agility . . . . . . . . . . . . . . . . . . . . 51 4.5.1. Migration Path . . . . . . . . . . . . . . . . . . . 51 4.5.2. Post-Quantum Considerations . . . . . . . . . . . . . 52 4.6. Security Considerations . . . . . . . . . . . . . . . . . 52 4.6.1. Hardware Acceleration Attacks . . . . . . . . . . . . 52 4.6.2. Parallelization Resistance . . . . . . . . . . . . . 53 4.6.3. Time-Memory Tradeoffs . . . . . . . . . . . . . . . . 53 4.6.4. Calibration Attacks . . . . . . . . . . . . . . . . . 53 4.6.5. Timing Side Channels . . . . . . . . . . . . . . . . 54 5. Absence Proofs: Negative Evidence . . . . . . . . . . . . . . 54 5.1. Design Philosophy . . . . . . . . . . . . . . . . . . . . 55 5.1.1. The Value of Bounded Claims . . . . . . . . . . . . . 55 Condrey Expires 10 August 2026 [Page 4] Internet-Draft Proof of Process February 2026 5.1.2. Inherent Limits of Negative Evidence . . . . . . . . 55 5.2. Trust Boundary: Chain-Verifiable vs. Monitoring-Dependent . . . . . . . . . . . . . . . . . . 56 5.2.1. Chain-Verifiable Claims (1-15) . . . . . . . . . . . 56 5.2.2. Monitoring-Dependent Claims (16-63) . . . . . . . . . 56 5.2.3. Trust Model Comparison . . . . . . . . . . . . . . . 57 5.3. Chain-Verifiable Claims (Types 1-15) . . . . . . . . . . 57 5.3.1. Verification Details . . . . . . . . . . . . . . . . 58 5.4. Monitoring-Dependent Claims (Types 16-63) . . . . . . . . 59 5.4.1. Trust Basis Documentation . . . . . . . . . . . . . . 60 5.5. Monitoring Coverage . . . . . . . . . . . . . . . . . . . 61 5.5.1. Coverage Fields . . . . . . . . . . . . . . . . . . . 62 5.5.2. Gap Semantics . . . . . . . . . . . . . . . . . . . . 62 5.6. Absence Section Structure . . . . . . . . . . . . . . . . 63 5.6.1. Confidence Levels . . . . . . . . . . . . . . . . . . 64 5.7. Verification Procedure . . . . . . . . . . . . . . . . . 64 5.7.1. Step 1: Verify Chain-Verifiable Claims . . . . . . . 65 5.7.2. Step 2: Appraise Monitoring-Dependent Claims . . . . 65 5.7.3. Step 3: Produce Verification Summary . . . . . . . . 66 5.8. RATS Architecture Mapping . . . . . . . . . . . . . . . . 66 5.8.1. Role Distribution . . . . . . . . . . . . . . . . . . 66 5.8.2. Evidence Model Extension . . . . . . . . . . . . . . 67 5.8.3. Appraisal Policy Integration . . . . . . . . . . . . 67 5.9. Security Considerations . . . . . . . . . . . . . . . . . 68 5.9.1. What Absence Claims Do NOT Prove . . . . . . . . . . 68 5.9.2. Attesting Environment Compromise . . . . . . . . . . 68 5.9.3. Monitoring Evasion . . . . . . . . . . . . . . . . . 69 5.9.4. Statistical Claim Limitations . . . . . . . . . . . . 69 5.10. Privacy Considerations . . . . . . . . . . . . . . . . . 69 6. Forgery Cost Bounds (Quantified Security) . . . . . . . . . . 70 6.1. Design Philosophy . . . . . . . . . . . . . . . . . . . . 70 6.1.1. Cost-Asymmetric Forgery . . . . . . . . . . . . . . . 71 6.1.2. What Forgery Cost Bounds Do NOT Claim . . . . . . . . 71 6.2. Forgery Cost Section Structure . . . . . . . . . . . . . 71 6.3. Time Bound . . . . . . . . . . . . . . . . . . . . . . . 72 6.3.1. Field Definitions . . . . . . . . . . . . . . . . . . 72 6.3.2. Time Bound Verification . . . . . . . . . . . . . . . 73 6.3.3. Parallelization Resistance . . . . . . . . . . . . . 73 6.4. Entropy Bound . . . . . . . . . . . . . . . . . . . . . . 74 6.4.1. Field Definitions . . . . . . . . . . . . . . . . . . 74 6.4.2. Entropy Bound Verification . . . . . . . . . . . . . 75 6.4.3. Minimum Entropy Requirements . . . . . . . . . . . . 75 6.5. Economic Bound . . . . . . . . . . . . . . . . . . . . . 76 6.5.1. Field Definitions . . . . . . . . . . . . . . . . . . 76 6.5.2. Cost Estimate Structure . . . . . . . . . . . . . . . 77 6.5.3. Cost Computation . . . . . . . . . . . . . . . . . . 77 6.5.4. Cost Model Depreciation . . . . . . . . . . . . . . . 78 6.6. Security Statement . . . . . . . . . . . . . . . . . . . 78 Condrey Expires 10 August 2026 [Page 5] Internet-Draft Proof of Process February 2026 6.6.1. Field Definitions . . . . . . . . . . . . . . . . . . 79 6.6.2. Formal Security Bound . . . . . . . . . . . . . . . . 80 6.7. Verification Procedure . . . . . . . . . . . . . . . . . 80 6.8. Security Considerations . . . . . . . . . . . . . . . . . 81 6.8.1. Assumed Adversary Capabilities . . . . . . . . . . . 81 6.8.2. Limitations of Cost Bounds . . . . . . . . . . . . . 82 6.8.3. What Bounds Do NOT Guarantee . . . . . . . . . . . . 82 6.8.4. Policy Guidance for Relying Parties . . . . . . . . . 82 7. Cross-Document Provenance Links . . . . . . . . . . . . . . . 83 7.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 83 7.2. Provenance Section Structure . . . . . . . . . . . . . . 84 7.3. Verification of Provenance Links . . . . . . . . . . . . 85 7.3.1. Parent Chain Hash Verification . . . . . . . . . . . 85 7.3.2. Cross-Packet Attestation . . . . . . . . . . . . . . 85 7.4. Privacy Considerations for Provenance . . . . . . . . . . 86 7.5. Provenance Link Examples . . . . . . . . . . . . . . . . 86 7.5.1. Continuation Example . . . . . . . . . . . . . . . . 86 7.5.2. Merge Example . . . . . . . . . . . . . . . . . . . . 87 8. Incremental Evidence with Continuation Tokens . . . . . . . . 88 8.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 88 8.2. Continuation Token Structure . . . . . . . . . . . . . . 89 8.3. Chain Integrity Across Packets . . . . . . . . . . . . . 90 8.4. Verification of Continuation Chains . . . . . . . . . . . 90 8.4.1. Single Packet Verification . . . . . . . . . . . . . 91 8.4.2. Full Series Verification . . . . . . . . . . . . . . 91 8.5. Series Binding Signature . . . . . . . . . . . . . . . . 91 8.6. Practical Considerations . . . . . . . . . . . . . . . . 92 8.6.1. When to Export a Continuation Packet . . . . . . . . 92 8.6.2. Handling Gaps in Series . . . . . . . . . . . . . . . 92 8.7. Continuation Token Example . . . . . . . . . . . . . . . 93 9. Quantified Trust Policies . . . . . . . . . . . . . . . . . . 93 9.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 93 9.2. Trust Policy Structure . . . . . . . . . . . . . . . . . 94 9.3. Trust Computation Models . . . . . . . . . . . . . . . . 96 9.3.1. Weighted Average Model . . . . . . . . . . . . . . . 96 9.3.2. Minimum-of-Factors Model . . . . . . . . . . . . . . 96 9.3.3. Geometric Mean Model . . . . . . . . . . . . . . . . 97 9.4. Factor Normalization . . . . . . . . . . . . . . . . . . 97 9.4.1. Threshold Normalization . . . . . . . . . . . . . . . 97 9.4.2. Range Normalization . . . . . . . . . . . . . . . . . 97 9.4.3. Binary Normalization . . . . . . . . . . . . . . . . 98 9.5. Predefined Policy Profiles . . . . . . . . . . . . . . . 98 9.6. Trust Policy Example . . . . . . . . . . . . . . . . . . 99 10. Compact Evidence References . . . . . . . . . . . . . . . . . 100 10.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 100 10.2. Compact Reference Structure . . . . . . . . . . . . . . 101 10.3. Compact Reference Signature . . . . . . . . . . . . . . 102 10.4. Verification of Compact References . . . . . . . . . . . 102 Condrey Expires 10 August 2026 [Page 6] Internet-Draft Proof of Process February 2026 10.4.1. Reference-Only Verification . . . . . . . . . . . . 102 10.4.2. Full Verification via URI . . . . . . . . . . . . . 102 10.5. Encoding Formats . . . . . . . . . . . . . . . . . . . . 103 10.5.1. CBOR Encoding . . . . . . . . . . . . . . . . . . . 103 10.5.2. Base64 Encoding . . . . . . . . . . . . . . . . . . 103 10.5.3. URI Encoding . . . . . . . . . . . . . . . . . . . . 103 10.5.4. QR Code Encoding . . . . . . . . . . . . . . . . . . 104 10.6. Embedding Guidelines . . . . . . . . . . . . . . . . . . 104 10.6.1. PDF Documents . . . . . . . . . . . . . . . . . . . 104 10.6.2. Git Commits . . . . . . . . . . . . . . . . . . . . 104 10.6.3. Image Files . . . . . . . . . . . . . . . . . . . . 104 10.7. Compact Reference Example . . . . . . . . . . . . . . . 105 11. Security Considerations . . . . . . . . . . . . . . . . . . . 105 11.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 106 11.1.1. Adversary Goals . . . . . . . . . . . . . . . . . . 106 11.1.2. Assumed Adversary Capabilities . . . . . . . . . . . 106 11.1.3. Out-of-Scope Adversaries . . . . . . . . . . . . . . 107 11.2. Cryptographic Security . . . . . . . . . . . . . . . . . 108 11.2.1. Hash Function Security . . . . . . . . . . . . . . . 108 11.2.2. Signature Security . . . . . . . . . . . . . . . . . 109 11.2.3. VDF Security . . . . . . . . . . . . . . . . . . . . 109 11.2.4. Key Management . . . . . . . . . . . . . . . . . . . 110 11.3. Attesting Environment Trust . . . . . . . . . . . . . . 111 11.3.1. What the AE Is Trusted For . . . . . . . . . . . . . 111 11.3.2. What the AE Is NOT Trusted For . . . . . . . . . . . 111 11.3.3. Hardware Attestation Role . . . . . . . . . . . . . 112 11.3.4. Compromised AE Scenarios . . . . . . . . . . . . . . 112 11.4. Verification Security . . . . . . . . . . . . . . . . . 113 11.4.1. Verifier Independence . . . . . . . . . . . . . . . 113 11.4.2. Sampling Strategies for Large Evidence Packets . . . 114 11.4.3. External Anchor Verification . . . . . . . . . . . . 114 11.5. Protocol Security . . . . . . . . . . . . . . . . . . . 115 11.5.1. Replay Attack Prevention . . . . . . . . . . . . . . 115 11.5.2. Transplant Attack Prevention . . . . . . . . . . . . 115 11.5.3. Backdating Attack Costs . . . . . . . . . . . . . . 116 11.5.4. Omission Attack Prevention . . . . . . . . . . . . . 117 11.6. Operational Security . . . . . . . . . . . . . . . . . . 117 11.6.1. Key Lifecycle Management . . . . . . . . . . . . . . 117 11.6.2. Evidence Packet Storage and Transmission . . . . . . 118 11.6.3. Verifier Policy Considerations . . . . . . . . . . . 118 11.7. Limitations and Non-Goals . . . . . . . . . . . . . . . 119 11.7.1. Attacks Not Protected Against . . . . . . . . . . . 119 11.7.2. The Honest Author Assumption . . . . . . . . . . . . 119 11.7.3. Content-Agnostic By Design . . . . . . . . . . . . . 120 11.8. Comparison to Related Work . . . . . . . . . . . . . . . 120 11.8.1. Comparison to Traditional Timestamping . . . . . . . 120 11.8.2. Comparison to Code Signing . . . . . . . . . . . . . 121 11.8.3. Relationship to RATS Security Model . . . . . . . . 122 Condrey Expires 10 August 2026 [Page 7] Internet-Draft Proof of Process February 2026 11.9. Security Properties Summary . . . . . . . . . . . . . . 122 11.9.1. Properties Provided . . . . . . . . . . . . . . . . 122 11.9.2. Properties NOT Provided . . . . . . . . . . . . . . 123 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 123 12.1. Privacy by Construction . . . . . . . . . . . . . . . . 124 12.1.1. No Document Content Storage . . . . . . . . . . . . 124 12.1.2. No Keystroke Capture . . . . . . . . . . . . . . . . 124 12.1.3. No Screenshots or Screen Recording . . . . . . . . . 125 12.1.4. Local Evidence Generation . . . . . . . . . . . . . 125 12.2. Data Minimization . . . . . . . . . . . . . . . . . . . 126 12.2.1. Data Collected . . . . . . . . . . . . . . . . . . . 126 12.2.2. Data NOT Collected . . . . . . . . . . . . . . . . . 127 12.2.3. Disclosure Levels . . . . . . . . . . . . . . . . . 127 12.3. Biometric-Adjacent Data . . . . . . . . . . . . . . . . 128 12.3.1. Identification Risks . . . . . . . . . . . . . . . . 128 12.3.2. Mitigation Measures . . . . . . . . . . . . . . . . 128 12.3.3. Regulatory Considerations . . . . . . . . . . . . . 129 12.3.4. User Disclosure Requirements . . . . . . . . . . . . 129 12.4. Salt Modes for Content Privacy . . . . . . . . . . . . . 130 12.4.1. Unsalted Mode (Value 0) . . . . . . . . . . . . . . 130 12.4.2. Author-Salted Mode (Value 1) . . . . . . . . . . . . 130 12.4.3. Third-Party Escrowed Mode (Value 2) . . . . . . . . 131 12.4.4. Salt Security Considerations . . . . . . . . . . . . 132 12.5. Identity and Pseudonymity . . . . . . . . . . . . . . . 132 12.5.1. Anonymous Evidence Generation . . . . . . . . . . . 132 12.5.2. Pseudonymous Evidence . . . . . . . . . . . . . . . 132 12.5.3. Identified Evidence . . . . . . . . . . . . . . . . 133 12.5.4. Device Binding Without User Identification . . . . . 133 12.6. Data Retention and Deletion . . . . . . . . . . . . . . 133 12.6.1. Evidence Packet Lifecycle . . . . . . . . . . . . . 133 12.6.2. User Rights to Deletion . . . . . . . . . . . . . . 134 12.6.3. External Anchor Permanence . . . . . . . . . . . . . 134 12.7. Third-Party Disclosure . . . . . . . . . . . . . . . . . 135 12.7.1. Information Disclosed to Verifiers . . . . . . . . . 135 12.7.2. Information Disclosed to Relying Parties . . . . . . 136 12.7.3. Minimizing Disclosure . . . . . . . . . . . . . . . 136 12.8. Cross-Session Correlation . . . . . . . . . . . . . . . 136 12.8.1. Correlation Risks . . . . . . . . . . . . . . . . . 137 12.8.2. Device Key Rotation . . . . . . . . . . . . . . . . 137 12.8.3. Session Isolation Properties . . . . . . . . . . . . 137 12.8.4. Additional Mitigations . . . . . . . . . . . . . . . 138 12.9. Privacy Threat Analysis . . . . . . . . . . . . . . . . 138 12.9.1. Surveillance . . . . . . . . . . . . . . . . . . . . 138 12.9.2. Stored Data Compromise . . . . . . . . . . . . . . . 138 12.9.3. Correlation . . . . . . . . . . . . . . . . . . . . 139 12.9.4. Identification . . . . . . . . . . . . . . . . . . . 139 12.9.5. Secondary Use . . . . . . . . . . . . . . . . . . . 139 12.9.6. Disclosure . . . . . . . . . . . . . . . . . . . . . 139 Condrey Expires 10 August 2026 [Page 8] Internet-Draft Proof of Process February 2026 12.9.7. Exclusion . . . . . . . . . . . . . . . . . . . . . 140 12.10. Privacy Properties Summary . . . . . . . . . . . . . . . 140 12.10.1. Privacy Properties Provided . . . . . . . . . . . . 140 12.10.2. Privacy Limitations . . . . . . . . . . . . . . . . 141 12.10.3. Recommendations for Privacy-Sensitive Deployments . . . . . . . . . . . . . . . . . . . . . 141 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 142 13.1. CBOR Tags Registry . . . . . . . . . . . . . . . . . . . 142 13.1.1. Tag for Proof of Process Packet (0x50505020) . . . . 142 13.1.2. Tag for Writers Authenticity Report (0x57415220) . . 143 13.1.3. Tag for Compact Evidence Reference (0x50505021) . . 143 13.1.4. Justification for Dedicated Tags . . . . . . . . . . 143 13.2. Entity Attestation Token Profiles Registry . . . . . . . 144 13.3. CBOR Web Token Claims Registry . . . . . . . . . . . . . 145 13.4. New Registries . . . . . . . . . . . . . . . . . . . . . 147 13.4.1. Proof of Process Claim Types Registry . . . . . . . 147 13.4.2. Proof of Process VDF Algorithms Registry . . . . . . 152 13.4.3. Proof of Process Entropy Sources Registry . . . . . 153 13.5. Media Types Registry . . . . . . . . . . . . . . . . . . 155 13.5.1. application/vnd.example-pop+cbor Media Type . . . . 155 13.5.2. application/vnd.example-war+cbor Media Type . . . . 156 13.6. Designated Expert Instructions . . . . . . . . . . . . . 157 13.6.1. Proof of Process Claim Types Registry . . . . . . . 158 13.6.2. Proof of Process VDF Algorithms Registry . . . . . . 158 13.6.3. Proof of Process Entropy Sources Registry . . . . . 158 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 159 14.1. Normative References . . . . . . . . . . . . . . . . . . 159 14.2. Informative References . . . . . . . . . . . . . . . . . 160 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 161 Document History . . . . . . . . . . . . . . . . . . . . . . . . 161 draft-condrey-rats-pop-00 . . . . . . . . . . . . . . . . . . . 161 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 162 1. Introduction This document specifies Proof of Process, an evidence framework for digital authorship attestation. The framework produces tamper- evident, independently verifiable process evidence describing how documents evolve over time. 1.1. Problem Statement Digital documents lack provenance information about their creation process. While cryptographic signatures prove key possession and timestamps prove existence at a point in time, neither addresses a fundamental question: how did this document come to exist? Condrey Expires 10 August 2026 [Page 9] Internet-Draft Proof of Process February 2026 Existing approaches to authorship verification fall into two categories, each with significant limitations: Surveillance-Based Systems: Screen recording, keystroke logging, and continuous monitoring capture detailed process information but fundamentally violate author privacy. Such systems require trust in the monitoring infrastructure and create risks of data exfiltration or misuse. The evidence they produce is not independently verifiable without access to surveillance archives controlled by third parties. Content Analysis Systems: Stylometric analysis, AI detection tools, and linguistic forensics attempt to infer process from product. These approaches make probabilistic claims about authorship based on content patterns but cannot provide verifiable evidence of the creation process. They are vulnerable to false positives, false negatives, and adversarial manipulation. Neither approach produces evidence that is simultaneously: * Privacy-preserving (no content capture or transmission) * Independently verifiable (no trust in monitoring infrastructure) * Tamper-evident (modifications are detectable) * Process-documenting (captures how, not just what) The need for such evidence is growing across multiple domains: * Academic integrity: Institutions require process evidence for submissions, particularly as AI-generated content becomes indistinguishable from human writing. * Legal documentation: Courts and regulatory bodies require provenance evidence for documents submitted as evidence. * Creative works: Authors and creators seek to document their creative process for copyright, attribution, and authenticity purposes. * Professional certification: Regulated professions may require evidence that work product was created through specified processes. Condrey Expires 10 August 2026 [Page 10] Internet-Draft Proof of Process February 2026 1.2. Scope 1.2.1. What This Specification Defines This specification defines: * Evidence format: The structure of Evidence Packets (.pop files) containing checkpoint chains, behavioral entropy bindings, and cryptographic proofs. * Attestation result format: The structure of Attestation Results (.war files) produced by Verifiers after appraising Evidence. * Checkpoint structure: The cryptographic construction binding document states, timing proofs, and behavioral evidence. * Verification procedures: Algorithms for independent verification of Evidence Packets without access to the original Attesting Environment. * Claim taxonomy: Classification of claims into chain-verifiable and monitoring-dependent categories with explicit trust requirements. 1.2.2. What This Specification Does NOT Define This specification explicitly excludes: * Content analysis: No examination of document content for stylometric patterns, linguistic features, or semantic meaning. * Authorship determination: No claims about the identity of the author beyond cryptographic key binding. The specification documents process, not persons. * Intent inference: No claims about the cognitive state, creative intent, or mental processes of the author. * AI detection: No classification of content as "human-written" or "AI-generated." The specification provides evidence about process; interpretation is left to Relying Parties. * Surveillance mechanisms: No screen capture, keystroke content logging, or continuous monitoring. Behavioral signals are captured as timing entropy, not content. Condrey Expires 10 August 2026 [Page 11] Internet-Draft Proof of Process February 2026 1.2.3. Relationship to RATS Architecture This specification implements a specialized profile of the Remote ATtestation procedureS (RATS) architecture [RFC9334] with domain- specific extensions for behavioral evidence and process documentation. The RATS role mappings are: Attester: The witnessd-core library running on the author's device, producing Evidence Packets (.pop files). Verifier: Any implementation capable of parsing and appraising Evidence Packets, producing Attestation Results (.war files). Relying Party: The entity consuming Attestation Results for trust decisions (e.g., academic institutions, publishers, legal systems). The Evidence produced by this specification extends standard RATS evidence with behavioral entropy bindings and Verifiable Delay Function proofs for temporal ordering. 1.3. Design Goals The Proof of Process framework is designed around four core principles: 1.3.1. Privacy by Construction The framework enforces privacy through structural constraints, not policy promises: * No document content is stored in Evidence Packets. Content is represented only by cryptographic hashes. * No characters typed are captured. Keystroke timing is recorded without association to specific characters. * No screenshots or screen recordings are taken. Visual content is never captured by the Attesting Environment. * Behavioral data is aggregated into statistical summaries before inclusion in Evidence, preventing reconstruction of input sequences. Condrey Expires 10 August 2026 [Page 12] Internet-Draft Proof of Process February 2026 1.3.2. Zero Trust: Locally Generated, Independently Verifiable Evidence generation and verification are fully decoupled: * Evidence is generated entirely on the Attester device with no network dependency during creation. * Verification requires only the Evidence Packet itself; no access to the original device, the document content, or external services (except for optional external anchor validation). * Multiple independent Verifiers can appraise the same Evidence, enabling adversarial review. * No trusted third party is required for basic verification. 1.3.3. Evidence Over Inference The framework provides observable evidence, not conclusions: * Claims are classified as chain-verifiable (provable from Evidence alone) or monitoring-dependent (requiring Attesting Environment trust). * Attestation Results document what was verified, not what should be believed. * Confidence scores and caveats accompany all assessments, enabling informed Relying Party decisions. * The specification makes no absolute claims about authorship, intent, or authenticity. 1.3.4. Cost-Asymmetric Forgery The framework makes forgery expensive relative to genuine creation: * Verifiable Delay Functions (VDFs) establish minimum elapsed time that cannot be circumvented through parallelization. * Captured behavioral entropy commits to timing measurements that cannot be regenerated without access to the original input stream. * Hash chain construction ensures any modification invalidates all subsequent evidence. * The forgery-cost-section quantifies attack costs, enabling risk assessment by Relying Parties. Condrey Expires 10 August 2026 [Page 13] Internet-Draft Proof of Process February 2026 IMPORTANT: This framework does not claim to make forgery impossible. It raises the cost of forgery relative to honest participation and provides quantified bounds on attack economics. 1.4. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. This document uses the following terms: Evidence Packet (.pop): The primary evidence artifact produced by the Attester, containing checkpoint chains, behavioral entropy bindings, VDF proofs, and optional attestations. The file extension ".pop" derives from "Proof of Process." Evidence Packets are CBOR-encoded with semantic tag 1347571280 (0x50505020, ASCII "PPP "). Attestation Result (.war): The verification certificate produced by a Verifier after appraising an Evidence Packet. Contains the verification verdict, verified claims, confidence score, and Verifier signature. The file extension ".war" derives from "Writers Authenticity Report." Attestation Results are CBOR- encoded with semantic tag 1463894560 (0x57415220, ASCII "WAR "). Checkpoint: A cryptographic snapshot of document state at a point in time, including content hash, timing proof, and behavioral entropy binding. Checkpoints form a hash chain where each checkpoint references its predecessor. Jitter Seal: Captured behavioral entropy from human input events, bound to the checkpoint chain. Unlike injected entropy (random delays added by software), captured entropy commits to actual measured timing that existed only at the moment of observation. See Section 3 for detailed specification. Verifiable Delay Function (VDF): A cryptographic primitive that requires sequential computation and cannot be parallelized, used to establish minimum elapsed time between checkpoints. The VDF output for each checkpoint is entangled with the previous checkpoint and behavioral entropy, preventing precomputation. See Section 4 for detailed specification. Chain-verifiable Claim: A claim that can be verified from the Condrey Expires 10 August 2026 [Page 14] Internet-Draft Proof of Process February 2026 Evidence Packet alone, without trusting the Attesting Environment beyond basic data integrity. Examples include checkpoint chain integrity, VDF proof validity, and minimum elapsed time bounds. Monitoring-dependent Claim: A claim that requires trust in the Attesting Environment's accurate reporting of monitored events. Examples include behavioral anomaly detection and input source attribution. Such claims explicitly document their trust requirements. Attesting Environment (AE): The software and hardware environment where Evidence is generated. Per the RATS architecture [RFC9334], the AE produces claims about its own state and the processes it observes. Evidence Tier: A classification of Evidence Packets based on which optional sections are present. Tiers range from Basic (checkpoint chain only) to Maximum (hardware attestation, external anchors, forgery cost analysis). See Section 2.6 for tier definitions. 1.5. Document Structure This specification is organized as follows: * Section 2: Defines the overall architecture, RATS role mappings, and the two complementary formats (Evidence Packets and Attestation Results). * Section 3: Specifies the Jitter Seal mechanism for capturing and binding behavioral entropy to the checkpoint chain. * Section 4: Specifies Verifiable Delay Function constructions for temporal ordering and minimum elapsed time proofs. * Section 5: Defines the taxonomy of absence claims and the trust requirements for each claim type. * Section 6: Specifies the methodology for quantifying forgery costs and attack economics. * Section 11: Analyzes security properties, threat models, and attack mitigations. * Section 12: Documents privacy properties and data handling requirements. * Section 13: Requests IANA registrations for CBOR tags, EAT claims, and media types. Condrey Expires 10 August 2026 [Page 15] Internet-Draft Proof of Process February 2026 Appendices provide CDDL schemas, test vectors, and implementation guidance. 1.6. Conventions and Definitions 1.6.1. CDDL Notation Data structures in this document are specified using the Concise Data Definition Language (CDDL) [RFC8610]. CDDL provides a notation for expressing CBOR and JSON data structures. The normative CDDL definitions appear inline in the relevant sections. 1.6.2. CBOR Encoding Both Evidence Packets and Attestation Results use CBOR (Concise Binary Object Representation) encoding per [RFC8949]. CBOR provides efficient binary encoding with support for semantic tags and extensibility. This specification uses: * Semantic tags for type identification (Evidence Packet: 1347571280, Attestation Result: 1463894560) * Integer keys (1-99) for core protocol fields to minimize encoding size * String keys for vendor extensions and application-specific fields * Deterministic encoding (RFC 8949 Section 4.2) RECOMMENDED for signature verification 1.6.3. COSE Signatures Cryptographic signatures use COSE ([IANA.cose], CBOR Object Signing and Encryption) [RFC9052]. The COSE_Sign1 structure provides single- signer signatures suitable for Evidence and Attestation Result authentication. Recommended algorithms: * EdDSA with Ed25519 (RECOMMENDED for new implementations) * ECDSA with P-256 (for compatibility with existing PKI) Condrey Expires 10 August 2026 [Page 16] Internet-Draft Proof of Process February 2026 1.6.4. EAT Tokens This specification defines an Entity Attestation Token (EAT) profile per [RFC9711]. EAT provides a framework for attestation claims with support for custom claim types. The EAT profile URI for Proof of Process evidence is: https://example.com/rats/eat/profile/pop/1.0 Custom EAT claims proposed for IANA registration are defined in Section 13. 1.6.5. Hash Function Notation This document uses the following notation for cryptographic hash functions: * H(x): SHA-256 hash of input x (default) * H^n(x): n iterations of hash function H * HMAC(k, m): HMAC-SHA256 with key k and message m SHA-256 is the RECOMMENDED hash algorithm. Implementations MAY support SHA3-256 for algorithm agility. 2. Evidence Model This section defines the top-level architecture of the witnessd Proof of Process evidence model. The design follows the RATS (Remote ATtestation procedureS) architecture [RFC9334] while introducing domain-specific extensions for behavioral evidence and process documentation. 2.1. RATS Architecture Mapping This specification implements a RATS [RFC9334] profile with these role mappings: the witnessd-core library acts as Attester, producing Evidence Packets (.pop files); verification implementations act as Verifiers, producing Attestation Results (.war files); and consuming entities (institutions, publishers) act as Relying Parties. Key properties: Evidence is generated locally on the Attester device without network dependency; verification requires only the Evidence packet; Evidence contains cryptographic hashes, not content; behavioral signals are aggregated into statistical summaries. Condrey Expires 10 August 2026 [Page 17] Internet-Draft Proof of Process February 2026 2.2. Two Complementary Formats The witnessd protocol defines two file formats that serve distinct roles in the attestation workflow: 2.2.1. Evidence Packet (.pop) The .pop (Proof of Process) file is the primary Evidence artifact produced by the Attester. It contains all cryptographic proofs and behavioral evidence accumulated during document authorship. CBOR encoding with semantic tag: Tag: 1347571280 (0x50505020, ASCII "PPP ") Type: tagged-evidence-packet The Evidence packet is the authoritative record of the authoring process. It may be: * Submitted to a Verifier for appraisal * Archived alongside the document for future verification * Shared with Relying Parties who perform their own verification The .pop file is typically larger than the .war file because it contains complete checkpoint chains, VDF proofs, and behavioral evidence. 2.2.2. Attestation Result (.war) The .war (Writers Authenticity Report) file is the Attestation Result produced by a Verifier after appraising an Evidence packet. It serves as a portable verification certificate. CBOR encoding with semantic tag: Tag: 1463894560 (0x57415220, ASCII "WAR ") Type: tagged-attestation-result The Attestation Result is designed for distribution alongside published documents. It provides: * A signed verdict from a trusted Verifier * Summary of verified claims without full evidence * Confidence score for Relying Party decision-making Condrey Expires 10 August 2026 [Page 18] Internet-Draft Proof of Process February 2026 * Caveats documenting verification limitations Relying Parties may trust the .war file based on the Verifier's reputation, or they may request the original .pop file for independent verification. 2.2.3. Format Relationship The two formats are linked by the reference-packet-id field in the Attestation Result, which matches the packet-id of the appraised Evidence packet: Evidence Packet (.pop) Attestation Result (.war) +-------------------+ +------------------------+ | packet-id: UUID |<----------| reference-packet-id: | | | | UUID (same value) | +-------------------+ +------------------------+ This binding ensures that each Attestation Result is unambiguously tied to a specific Evidence packet. 2.3. Evidence Packet Structure The evidence-packet structure contains the complete attestation evidence produced by the Attester. The normative CDDL definition is provided in the schema appendix; this section describes the semantic meaning of each component. evidence-packet = { 1 => uint, ; version 2 => tstr, ; profile (EAT profile URI) 3 => uuid, ; packet-id 4 => pop-timestamp, ; created 5 => document-ref, ; document 6 => [+ checkpoint], ; checkpoints ; Tiered optional sections ? 10 => presence-section, ; presence ? 11 => forensics-section, ; forensics ? 12 => keystroke-section, ; keystroke ? 13 => hardware-section, ; hardware ? 14 => external-section, ; external ? 15 => absence-section, ; absence ? 16 => forgery-cost-section, ; forgery-cost ? 17 => declaration, ; declaration * tstr => any, ; extensions } Condrey Expires 10 August 2026 [Page 19] Internet-Draft Proof of Process February 2026 2.3.1. Required Fields version (key 1): Schema version number. Currently 1. Implementations MUST reject packets with unrecognized major versions. profile (key 2): EAT profile URI identifying this specification: https://example.com/rats/eat/profile/pop/1.0 IANA registration to be requested upon working group adoption. packet-id (key 3): UUID ([RFC9562]) uniquely identifying this Evidence packet. Generated by the Attester at packet creation time. created (key 4): Timestamp when this packet was finalized. CBOR tag 1 (epoch-based date/time). document (key 5): Reference to the documented artifact. See Section 2.5. checkpoints (key 6): Ordered array of checkpoint structures forming the evidence chain. See Section 2.4. 2.3.2. Tiered Optional Sections The optional sections (keys 10-17) correspond to evidence tiers. Their presence determines the evidence strength: Condrey Expires 10 August 2026 [Page 20] Internet-Draft Proof of Process February 2026 +=====+======================+===================+===========+ | Key | Section | Tier Contribution | Reference | +=====+======================+===================+===========+ | 10 | presence-section | Standard (+) | - | +-----+----------------------+-------------------+-----------+ | 11 | forensics-section | Enhanced (+) | - | +-----+----------------------+-------------------+-----------+ | 12 | keystroke-section | Enhanced (+) | Section 3 | +-----+----------------------+-------------------+-----------+ | 13 | hardware-section | Maximum (+) | - | +-----+----------------------+-------------------+-----------+ | 14 | external-section | Maximum (+) | - | +-----+----------------------+-------------------+-----------+ | 15 | absence-section | Maximum (+) | Section 5 | +-----+----------------------+-------------------+-----------+ | 16 | forgery-cost-section | Maximum (+) | Section 6 | +-----+----------------------+-------------------+-----------+ | 17 | declaration | All tiers | - | +-----+----------------------+-------------------+-----------+ Table 1 2.3.3. Extensibility The evidence-packet structure supports forward-compatible extensions through string-keyed fields: * Integer keys 1-99 are reserved for this specification * String keys MAY be used for vendor or application-specific extensions * Verifiers MUST ignore unrecognized string-keyed fields * Verifiers MUST reject packets containing unrecognized integer keys in the reserved range 2.4. Checkpoint Chain The checkpoint chain is the core evidentiary structure. Each checkpoint represents a witnessed document state, cryptographically linked to its predecessor. 2.4.1. Checkpoint Structure Condrey Expires 10 August 2026 [Page 21] Internet-Draft Proof of Process February 2026 checkpoint = { 1 => uint, ; sequence 2 => uuid, ; checkpoint-id 3 => pop-timestamp, ; timestamp 4 => hash-value, ; content-hash 5 => uint, ; char-count 6 => uint, ; word-count 7 => edit-delta, ; delta 8 => hash-value, ; prev-hash 9 => hash-value, ; checkpoint-hash 10 => vdf-proof, ; vdf-proof 11 => jitter-binding, ; jitter-binding 12 => bstr .size 32, ; chain-mac * tstr => any, ; extensions } sequence (key 1): Zero-indexed ordinal position in the checkpoint chain. MUST be strictly monotonically increasing. checkpoint-id (key 2): UUID uniquely identifying this checkpoint within the packet. timestamp (key 3): Local timestamp when the checkpoint was created. Note that local timestamps are untrusted; temporal ordering is established by VDF causality. content-hash (key 4): Cryptographic hash of the document content at this checkpoint. SHA-256 RECOMMENDED. char-count (key 5), word-count (key 6): Document statistics at this checkpoint. Informational only; not cryptographically bound. delta (key 7): Edit delta since previous checkpoint. Contains character counts for additions, deletions, and edit operations. No content is included. prev-hash (key 8): Hash of the previous checkpoint (checkpoint- hash{N-1}). For the genesis checkpoint (sequence = 0), this MUST be 32 zero bytes. checkpoint-hash (key 9): Binding hash computed over all checkpoint fields, creating the hash chain. vdf-proof (key 10): Verifiable Delay Function proof establishing minimum elapsed time. See Section 4. jitter-binding (key 11): Captured behavioral entropy binding. See Condrey Expires 10 August 2026 [Page 22] Internet-Draft Proof of Process February 2026 Section 3. chain-mac (key 12): HMAC-SHA256 binding the checkpoint to the chain key, preventing transplantation of checkpoints between sessions. 2.4.2. Hash Chain Construction The checkpoint chain forms a cryptographic hash chain through the prev-hash linkage: +---------------+ +---------------+ +---------------+ | Checkpoint 0 | | Checkpoint 1 | | Checkpoint 2 | |---------------| |---------------| |---------------| | prev-hash: |<----| prev-hash: |<----| prev-hash: | | (32 zeros) | H | H(CP_0) | H | H(CP_1) | | checkpoint- |---->| checkpoint- |---->| checkpoint- | | hash: H_0 | | hash: H_1 | | hash: H_2 | +---------------+ +---------------+ +---------------+ The checkpoint-hash is computed as: checkpoint-hash = H( "witnessd-checkpoint-v1" || sequence || checkpoint-id || timestamp || content-hash || char-count || word-count || CBOR(delta) || prev-hash || CBOR(vdf-proof) || CBOR(jitter-binding) ) This construction ensures that any modification to any field in any checkpoint invalidates all subsequent checkpoint hashes, providing tamper-evidence for the entire chain. 2.4.3. MMR Compatibility The checkpoint chain is designed for compatibility with Merkle Mountain Range ([MMR]) structures, enabling efficient inclusion proofs for subsets of checkpoints: * Each checkpoint-hash serves as a leaf in the MMR Condrey Expires 10 August 2026 [Page 23] Internet-Draft Proof of Process February 2026 * Verifiers can request inclusion proofs for specific checkpoints without receiving the entire chain * External anchors can commit to MMR roots, enabling efficient batch timestamping MMR proofs are optional and may be included in the external-section when third-party verification services provide them. 2.5. Document Binding The document-ref structure binds the Evidence packet to a specific document without including the document content. document-ref = { 1 => hash-value, ; content-hash 2 => tstr, ; filename (optional) 3 => uint, ; byte-length 4 => uint, ; char-count ? 5 => hash-salt-mode, ; salt mode ? 6 => bstr, ; salt-commitment } 2.5.1. Content Hash Binding The content-hash (key 1) is the cryptographic hash of the final document state. This is the same value as the content-hash in the final checkpoint. To verify document binding: 1. Compute H(document-content) 2. Compare with document-ref.content-hash 3. Compare with checkpoints{-1}.content-hash 4. All three values MUST match 2.5.2. Salt Modes for Privacy The hash-salt-mode field controls how the content hash is computed, enabling privacy-preserving verification scenarios: Condrey Expires 10 August 2026 [Page 24] Internet-Draft Proof of Process February 2026 +=======+======================+=============+======================+ | Value | Mode | Hash | Verification | | | | Computation | | +=======+======================+=============+======================+ | 0 | unsalted | H(content) | Anyone with | | | | | document can verify | +-------+----------------------+-------------+----------------------+ | 1 | author-salted | H(salt || | Author reveals salt | | | | content) | to chosen verifiers | +-------+----------------------+-------------+----------------------+ | 2 | third-party-escrowed | H(salt || | Escrow releases | | | | content) | salt under | | | | | conditions | +-------+----------------------+-------------+----------------------+ Table 2 When salted modes are used: * The salt-commitment field contains H(salt), not the salt itself * The author or escrow provides the salt out-of-band for verification * Verifiers confirm H(provided-salt) matches salt-commitment before using it Salted modes enable scenarios where the document binding should not be globally verifiable (e.g., unpublished manuscripts, confidential documents). 2.6. Evidence Tiers Evidence packets are classified into tiers based on which optional sections are present. Higher tiers provide stronger evidence at the cost of more extensive data collection and larger packet sizes. 2.6.1. Basic Tier The Basic tier contains only the required checkpoint chain and document reference: * Checkpoints with VDF proofs and jitter bindings * Document reference with content hash * Optional declaration (author attestation) Condrey Expires 10 August 2026 [Page 25] Internet-Draft Proof of Process February 2026 Basic tier evidence proves: * A sequence of document states was created over time * Minimum elapsed time between states (via VDF) * Behavioral entropy was captured at each checkpoint Basic tier is suitable for low-stakes documentation, personal records, or contexts where the author's attestation is generally trusted. 2.6.2. Standard Tier The Standard tier adds presence verification to the Basic tier: * All Basic tier components * presence-section: Human presence challenges and responses Standard tier evidence additionally proves: * A human responded to interactive challenges during authorship * Response timing is consistent with human reaction times Standard tier is suitable for academic submissions, professional reports, and contexts requiring reasonable assurance of human involvement. 2.6.3. Enhanced Tier The Enhanced tier adds forensic analysis to the Standard tier: * All Standard tier components * forensics-section: Edit topology, AI indicators, metrics * keystroke-section: Detailed jitter samples Enhanced tier evidence additionally provides: * Statistical analysis of editing patterns * Edit topology showing where changes occurred (not what) * AI indicator scores for forensic assessment Condrey Expires 10 August 2026 [Page 26] Internet-Draft Proof of Process February 2026 * Detailed keystroke timing for entropy verification Enhanced tier is suitable for legal documents, regulatory compliance, and high-value intellectual property. 2.6.4. Maximum Tier The Maximum tier adds hardware binding, external anchors, absence proofs, and forgery cost analysis: * All Enhanced tier components * hardware-section: TPM/Secure Enclave attestation * external-section: RFC 3161, blockchain timestamps * absence-section: Negative evidence claims * forgery-cost-section: Economic attack cost analysis Maximum tier evidence additionally provides: * Hardware binding proving evidence was created on a specific device * Third-party timestamps establishing absolute time * Absence proofs for bounded claims (e.g., max paste size) * Quantified forgery cost bounds for risk assessment Maximum tier is suitable for litigation support, forensic investigation, and contexts requiring the strongest available evidence. 2.6.5. Tier Selection Guidance The appropriate tier depends on the trust requirements and privacy constraints of the use case: Condrey Expires 10 August 2026 [Page 27] Internet-Draft Proof of Process February 2026 +==========+=======+===============================+================+ | Tier | Value | Typical Use Cases | Privacy Impact | +==========+=======+===============================+================+ | Basic | 1 | Personal notes, | Minimal | | | | internal docs | | +----------+-------+-------------------------------+----------------+ | Standard | 2 | Academic, | Low | | | | professional | | +----------+-------+-------------------------------+----------------+ | Enhanced | 3 | Legal, regulatory | Moderate | +----------+-------+-------------------------------+----------------+ | Maximum | 4 | Litigation, | Higher | | | | forensic | | +----------+-------+-------------------------------+----------------+ Table 3 Authors SHOULD select the minimum tier that meets their verification requirements. Higher tiers collect more behavioral data and create larger Evidence packets. 2.7. Attestation Result Structure The attestation-result structure contains the Verifier's assessment of an Evidence packet. It implements a witnessd-specific profile of EAR (Entity Attestation Results) as defined in [I-D.ietf-rats-ear]. attestation-result = { 1 => uint, ; version 2 => uuid, ; reference-packet-id 3 => pop-timestamp, ; verified-at 4 => forensic-assessment, ; verdict 5 => float32, ; confidence-score 6 => [+ result-claim], ; verified-claims 7 => cose-signature, ; verifier-signature ? 8 => tstr, ; verifier-identity ? 9 => verifier-metadata, ; additional info ? 10 => [+ tstr], ; caveats * tstr => any, ; extensions } 2.7.1. Verdict Field The verdict (key 4) is the Verifier's overall forensic assessment using the forensic-assessment enumeration: Condrey Expires 10 August 2026 [Page 28] Internet-Draft Proof of Process February 2026 +=======+=======================+============================+ | Value | Assessment | Meaning | +=======+=======================+============================+ | 0 | not-assessed | Verification incomplete or | | | | not attempted | +-------+-----------------------+----------------------------+ | 1 | strongly-human | Evidence strongly | | | | indicates human authorship | +-------+-----------------------+----------------------------+ | 2 | likely-human | Evidence consistent with | | | | human authorship | +-------+-----------------------+----------------------------+ | 3 | inconclusive | Evidence neither confirms | | | | nor refutes claims | +-------+-----------------------+----------------------------+ | 4 | likely-ai-assisted | Evidence suggests AI | | | | assistance | +-------+-----------------------+----------------------------+ | 5 | strongly-ai-generated | Evidence strongly | | | | indicates AI generation | +-------+-----------------------+----------------------------+ Table 4 IMPORTANT: The verdict describes the behavioral evidence, not a claim about the author's intent or the cognitive origin of ideas. It reflects observable patterns in the documented process. 2.7.2. Confidence Score The confidence-score (key 5) is a floating-point value in the range [0.0, 1.0] representing the Verifier's confidence in the verdict: * 0.0 - 0.3: Low confidence (limited evidence) * 0.3 - 0.7: Moderate confidence (typical evidence) * 0.7 - 1.0: High confidence (strong evidence) The confidence score incorporates: * Evidence tier (higher tiers increase confidence ceiling) * Checkpoint chain completeness * Entropy sufficiency in jitter bindings * VDF calibration attestation presence Condrey Expires 10 August 2026 [Page 29] Internet-Draft Proof of Process February 2026 * External anchor confirmations 2.7.3. Verified Claims The verified-claims array (key 6) contains individual claim verification results: result-claim = { 1 => uint, ; claim-type 2 => bool, ; verified ? 3 => tstr, ; detail ? 4 => confidence-level, ; claim-confidence } The claim-type values correspond to the absence-claim-type enumeration, enabling direct mapping between Evidence claims and Attestation Result verification outcomes. 2.7.4. Verifier Signature The verifier-signature (key 7) is a COSE_Sign1 signature over the Attestation Result payload (fields 1-6 plus any optional fields 8-10). This signature: * Authenticates the Verifier identity * Ensures integrity of the Attestation Result * Enables Relying Parties to verify the result came from a trusted Verifier 2.7.5. Caveats The caveats array (key 10) documents limitations and warnings that Relying Parties should consider: * "No hardware attestation available" * "External anchors pending confirmation" * "Jitter entropy below recommended threshold" * "Author declares AI tool usage" Verifiers MUST include appropriate caveats when the Evidence has known limitations. Relying Parties SHOULD review caveats before making trust decisions. Condrey Expires 10 August 2026 [Page 30] Internet-Draft Proof of Process February 2026 2.8. CBOR Encoding Both Evidence packets and Attestation Results use CBOR (Concise Binary Object Representation) encoding per RFC 8949. 2.8.1. Semantic Tags Top-level structures use semantic tags for type identification: +============+============+========+===========================+ | Tag | Hex | ASCII | Structure | +============+============+========+===========================+ | 1347571280 | 0x50505020 | "PPP " | tagged-evidence-packet | +------------+------------+--------+---------------------------+ | 1463894560 | 0x57415220 | "WAR " | tagged-attestation-result | +------------+------------+--------+---------------------------+ Table 5 These tags enable format detection without external metadata. Parsers can identify the packet type by examining the leading tag value. 2.8.2. Key Encoding Strategy The schema uses a dual key encoding strategy for efficiency and extensibility: Integer Keys (1-99): Reserved for core protocol fields defined in this specification. Provides compact encoding and enables efficient parsing. String Keys: Used for vendor extensions, application-specific fields, and future protocol extensions before standardization. Provides self-describing field names at the cost of encoding size. Example size comparison for a field named "forensics": Integer key (11): 1 byte (0x0B) String key ("forensics"): 10 bytes (0x69666F72656E73696373) For a typical Evidence packet with dozens of fields, integer keys reduce packet size by 20-40%. 2.8.3. Deterministic Encoding Evidence packets SHOULD use deterministic CBOR encoding (RFC 8949 Section 4.2) to enable: Condrey Expires 10 August 2026 [Page 31] Internet-Draft Proof of Process February 2026 * Byte-exact reproduction of packets for signature verification * Consistent hashing for cache and deduplication purposes * Simplified debugging and comparison Deterministic encoding requirements: * Map keys sorted in bytewise lexicographic order * Integers encoded in minimal representation * Floating-point values canonicalized 2.9. EAT Profile This specification defines an EAT (Entity Attestation Token) profile for Proof of Process evidence. The profile URI is: https://example.com/rats/eat/profile/pop/1.0 2.9.1. Custom EAT Claims The following custom claims are proposed for IANA registration upon working group adoption: +=========================+=======+========================+ | Claim Name | Type | Description | +=========================+=======+========================+ | pop-forensic-assessment | uint | forensic-assessment | | | | enumeration value | +-------------------------+-------+------------------------+ | pop-presence-score | float | Presence challenge | | | | pass rate (0.0-1.0) | +-------------------------+-------+------------------------+ | pop-evidence-tier | uint | Evidence tier (1-4) | +-------------------------+-------+------------------------+ | pop-ai-composite-score | float | AI indicator composite | | | | score (0.0-1.0) | +-------------------------+-------+------------------------+ Table 6 2.9.2. AR4SI Trustworthiness Extension The Attestation Result includes a proposed extension to the AR4SI ([I-D.ietf-rats-ar4si]) trustworthiness vector: Condrey Expires 10 August 2026 [Page 32] Internet-Draft Proof of Process February 2026 behavioral-consistency: -1..3 -1 = no claim 0 = behavioral evidence inconsistent with human authorship 1 = behavioral evidence inconclusive 2 = behavioral evidence consistent with human authorship 3 = behavioral evidence strongly indicates human authorship This extension enables integration of witnessd Attestation Results with broader trustworthiness assessment frameworks. 2.10. Security Considerations 2.10.1. Tamper-Evidence vs. Tamper-Proof The evidence model provides tamper-EVIDENCE, not tamper-PROOF: * Tamper-evident: Modifications to Evidence packets are detectable through cryptographic verification. The hash chain, VDF entanglement, and HMAC bindings ensure that any alteration invalidates the Evidence. * Not tamper-proof: An adversary with sufficient resources can fabricate Evidence by investing the computational time required by VDF proofs and generating plausible behavioral data. The forgery-cost-section quantifies this investment. Relying Parties should understand this distinction when making trust decisions. 2.10.2. Independent Verification Evidence packets are designed for independent verification: * All cryptographic proofs are included in the packet * Verification requires no access to the original device * Verification requires no network access (except for external anchor validation) * Multiple independent Verifiers can appraise the same Evidence This property enables adversarial verification: a skeptical Relying Party can verify Evidence without trusting the Attester's infrastructure. Condrey Expires 10 August 2026 [Page 33] Internet-Draft Proof of Process February 2026 2.10.3. Privacy by Construction The evidence model enforces privacy through structural constraints: * No content storage: Evidence contains hashes of document states, not content. The document itself is never included in Evidence packets. * No keystroke capture: Individual characters typed are not recorded. Timing intervals are captured without association to specific characters. * Aggregated behavioral data: Raw timing data is aggregated into histograms before inclusion in Evidence. Optional raw interval disclosure is user-controlled. * No screenshots or screen recording: Visual content is never captured by the Attesting Environment. 2.10.4. Attesting Environment Trust The evidence model assumes a minimally trusted Attesting Environment: * Chain-verifiable claims (absence-claim-types 1-15): Can be verified from Evidence alone without trusting the AE beyond basic data integrity. * Monitoring-dependent claims (absence-claim-types 16-63): Require trust that the AE accurately reported monitored events. The ae-trust-basis field documents these assumptions. Hardware attestation (hardware-section) increases AE trust by binding Evidence to verified hardware identities. 3. Jitter Seal: Captured Behavioral Entropy This section defines the Jitter Seal mechanism, a novel contribution to behavioral evidence that binds captured timing entropy to the checkpoint chain. Unlike injected entropy (random delays added by software), captured entropy commits to actual measured timing from human input events. Condrey Expires 10 August 2026 [Page 34] Internet-Draft Proof of Process February 2026 3.1. Design Principles The Jitter Seal addresses a fundamental limitation in existing attestation frameworks: the inability to distinguish evidence generated during genuine human interaction from evidence reconstructed after the fact. Captured vs. Injected Entropy: Injected entropy (e.g., random delays inserted by software) can be regenerated if the random seed is known. Captured entropy commits to timing measurements that existed only at the moment of observation. An adversary cannot regenerate captured entropy without access to the original input stream. Commitment Before Observation: The entropy commitment is computed and bound to the checkpoint chain before the summarized statistics are finalized. This prevents an adversary from crafting statistics that match a predetermined commitment. Privacy-Preserving Aggregation: Raw timing intervals are aggregated into histogram buckets, preserving statistical properties while preventing reconstruction of the original keystroke sequence. The raw intervals MAY be disclosed for enhanced verification but are not required. 3.2. Jitter Binding Structure The jitter-binding structure appears in each checkpoint and contains five fields: jitter-binding = { 1 => hash-value, ; entropy-commitment 2 => [+ entropy-source], ; sources 3 => jitter-summary, ; summary 4 => bstr .size 32, ; binding-mac ? 5 => [+ uint], ; raw-intervals (optional) } 3.2.1. Entropy Commitment (Key 1) The entropy-commitment is a cryptographic hash of the raw timing intervals concatenated in observation order: entropy-commitment = H(interval{0} || interval{1} || ... || interval{n}) where H is the hash algorithm specified in the hash-value structure (SHA-256 RECOMMENDED), and each interval is encoded as a 32-bit unsigned integer representing milliseconds. Condrey Expires 10 August 2026 [Page 35] Internet-Draft Proof of Process February 2026 This commitment is computed BEFORE the histogram summary, ensuring the raw data cannot be manipulated to match a desired statistical profile. 3.2.2. Entropy Sources (Key 2) The sources array identifies which input modalities contributed to the captured entropy: +=======+==================+=======================+ | Value | Source | Description | +=======+==================+=======================+ | 1 | keystroke-timing | Inter-key intervals | | | | from keyboard input | +-------+------------------+-----------------------+ | 2 | pause-patterns | Gaps between editing | | | | bursts (>2 seconds) | +-------+------------------+-----------------------+ | 3 | edit-cadence | Rhythm of insertions/ | | | | deletions over time | +-------+------------------+-----------------------+ | 4 | cursor-movement | Navigation timing | | | | within document | +-------+------------------+-----------------------+ | 5 | scroll-behavior | Document scrolling | | | | patterns | +-------+------------------+-----------------------+ | 6 | focus-changes | Application focus | | | | gain/loss events | +-------+------------------+-----------------------+ Table 7 Implementations MUST include at least one source. The keystroke- timing source (1) provides the highest entropy density and SHOULD be included when keyboard input is available. 3.2.3. Jitter Summary (Key 3) The summary provides verifiable statistics without exposing raw timing data: Condrey Expires 10 August 2026 [Page 36] Internet-Draft Proof of Process February 2026 jitter-summary = { 1 => uint, ; sample-count 2 => [+ histogram-bucket], ; timing-histogram 3 => float32, ; estimated-entropy-bits ? 4 => [+ anomaly-flag], ; anomalies (if detected) } histogram-bucket = { 1 => uint, ; lower-bound-ms 2 => uint, ; upper-bound-ms 3 => uint, ; count } The estimated-entropy-bits field is calculated using Shannon entropy over the histogram distribution: H = -sum(p[i] * log2(p[i])) for all buckets where p[i] > 0 p[i] = count[i] / total_samples RECOMMENDED bucket boundaries (in milliseconds): 0, 50, 100, 200, 500, 1000, 2000, 5000, +infinity. These boundaries capture the typical range of human typing and pause behavior. 3.2.4. Binding MAC (Key 4) The binding-mac cryptographically binds the jitter data to the checkpoint chain: binding-mac = HMAC-SHA256( key = checkpoint-chain-key, message = entropy-commitment || CBOR(sources) || CBOR(summary) || prev-checkpoint-hash ) This binding ensures that: 1. The jitter data cannot be transplanted between checkpoints 2. The jitter data cannot be modified without invalidating the checkpoint chain 3. The temporal ordering of jitter observations is preserved Condrey Expires 10 August 2026 [Page 37] Internet-Draft Proof of Process February 2026 3.2.5. Raw Intervals (Key 5, Optional) The raw-intervals array MAY be included for enhanced verification. When present, verifiers can: * Recompute the entropy-commitment and verify it matches * Recompute the histogram and verify consistency * Perform statistical analysis beyond the histogram Privacy consideration: Raw intervals may constitute biometric- adjacent data. See Section 3.7. 3.3. VDF Entanglement The Jitter Seal achieves temporal binding through entanglement with the VDF proof chain. The VDF input for checkpoint N includes the jitter binding from checkpoint N: VDF_input{N} = H( checkpoint-hash{N-1} || content-hash{N} || jitter-binding{N}.entropy-commitment ) VDF_output{N} = VDF(VDF_input{N}, iterations{N}) This entanglement creates a causal dependency: the VDF output cannot be computed until the jitter entropy is captured and committed. Combined with the VDF's sequential computation requirement, this ensures that: 1. The jitter data existed before the VDF computation began 2. The checkpoint cannot be backdated without recomputing the entire VDF chain from that point forward 3. The minimum time between checkpoints is bounded by VDF computation time plus jitter observation time 3.4. Verification Procedure A Verifier appraises the Jitter Seal through the following procedure: 1. Structural Validation: Condrey Expires 10 August 2026 [Page 38] Internet-Draft Proof of Process February 2026 Verify all required fields are present and correctly typed per the CDDL schema. 2. Binding MAC Verification: Recompute the binding-mac using the checkpoint chain key and verify it matches the provided value. 3. Entropy Commitment Verification (if raw-intervals present): Recompute H(intervals) and verify it matches entropy-commitment. 4. Histogram Consistency (if raw-intervals present): Recompute histogram buckets from raw intervals and verify consistency with the provided summary. 5. Entropy Threshold Check: Verify estimated-entropy-bits meets the minimum threshold for the claimed evidence tier. RECOMMENDED minimum: 32 bits for Standard tier, 64 bits for Enhanced tier. 6. Sample Count Check: Verify sample-count is consistent with the document size and claimed editing duration. Anomalously low sample counts relative to content length indicate potential evidence gaps. 7. Anomaly Assessment: If anomaly-flags are present, incorporate them into the overall forensic assessment. The presence of anomalies does not invalidate the evidence but affects confidence. 8. VDF Entanglement Verification: Verify the entropy-commitment appears in the VDF input computation for this checkpoint. The verification result contributes to the chain-verifiable claims defined in the absence-section: * jitter-entropy-above-threshold (claim type 8): PROVEN if estimated-entropy-bits exceeds threshold * jitter-samples-above-count (claim type 9): PROVEN if sample-count exceeds threshold Condrey Expires 10 August 2026 [Page 39] Internet-Draft Proof of Process February 2026 3.5. Anomaly Detection The Attesting Environment MAY flag anomalies in the captured timing data: +=======+===================+===================================+ | Value | Flag | Indication | +=======+===================+===================================+ | 1 | unusually-regular | Timing distribution has lower | | | | variance than typical human input | | | | (coefficient of variation < 0.1) | +-------+-------------------+-----------------------------------+ | 2 | burst-detected | Sustained high-speed input | | | | exceeding 200 WPM for >30 seconds | +-------+-------------------+-----------------------------------+ | 3 | gap-detected | Significant editing gap (>5 | | | | minutes) within what appears to | | | | be a continuous session | +-------+-------------------+-----------------------------------+ | 4 | paste-heavy | >50% of content added via paste | | | | operations in this checkpoint | | | | interval | +-------+-------------------+-----------------------------------+ Table 8 Anomaly flags are informational and do not constitute claims about authorship or intent. They provide context for Verifier appraisal and Relying Party decision-making. 3.6. Relationship to RATS Evidence The Jitter Seal extends the RATS evidence model [RFC9334] in several ways: Behavioral Evidence: Traditional RATS evidence attests to system state (software versions, configuration, integrity). The Jitter Seal attests to behavioral characteristics of the input stream, capturing properties that emerge only during genuine interaction. Continuous Attestation: Unlike point-in-time attestation, Jitter Seals are accumulated throughout an authoring session. Each checkpoint adds to the behavioral evidence corpus, with earlier seals constraining what later seals can claim. Non-Reproducible Evidence: RATS evidence can typically be Condrey Expires 10 August 2026 [Page 40] Internet-Draft Proof of Process February 2026 regenerated by returning to the same system state. Jitter Seal evidence cannot be regenerated because the timing entropy existed only at the moment of capture. Epoch Marker Compatibility: The VDF-entangled Jitter Seal can function as a local freshness mechanism compatible with the Epoch Markers framework [I-D.ietf-rats-epoch-markers]. The VDF output chain provides relative ordering; external anchors provide absolute time binding. 3.7. Privacy Considerations Keystroke timing data is biometric-adjacent: while not traditionally classified as biometric data, timing patterns can potentially identify individuals or reveal sensitive information about cognitive state or physical condition. 3.7.1. Mitigation Measures * Histogram Aggregation: By default, only aggregated histogram data is included in the evidence packet. Raw intervals are optional and SHOULD only be disclosed when enhanced verification is required. * Bucket Granularity: The RECOMMENDED bucket boundaries (50ms minimum width) prevent reconstruction of exact keystroke sequences while preserving statistically significant patterns. * No Character Mapping: Timing intervals are recorded without association to specific characters or words. The evidence captures rhythm without content. * Session Isolation: Jitter data is bound to a specific evidence packet and checkpoint chain. Cross-session correlation requires access to multiple evidence packets. 3.7.2. Disclosure Recommendations Implementations SHOULD inform users that: Condrey Expires 10 August 2026 [Page 41] Internet-Draft Proof of Process February 2026 1. Typing rhythm information is captured and included in evidence packets 2. Evidence packets may be shared with Verifiers and potentially with Relying Parties 3. Raw timing data (if disclosed) could theoretically be used for behavioral analysis Users SHOULD have the option to: 1. Disable raw-intervals disclosure (histogram-only mode) 2. Request deletion of evidence packets after verification 3. Review captured entropy statistics before packet finalization 3.8. Security Considerations 3.8.1. Replay Attacks An adversary might attempt to replay captured jitter data from a previous session. This attack is mitigated by: 1. VDF entanglement: The jitter commitment is bound to the VDF chain, which includes the previous checkpoint hash 2. Chain MAC: The binding-mac includes the previous checkpoint hash, preventing transplantation 3. Content binding: The jitter data is associated with specific content hashes that change with each edit 3.8.2. Simulation Attacks An adversary might attempt to generate synthetic timing data that mimics human patterns. The cost of this attack is bounded by: 1. Entropy requirement: Meeting the entropy threshold requires sufficient variation in timing. Perfectly regular synthetic input will fail the entropy check. 2. Real-time constraint: Condrey Expires 10 August 2026 [Page 42] Internet-Draft Proof of Process February 2026 The VDF entanglement requires that jitter data be captured before VDF computation. Generating synthetic timing that passes statistical tests while maintaining real-time constraints is non- trivial. 3. Statistical consistency: Synthetic timing must be consistent across all checkpoints. Anomaly detection may flag statistically improbable patterns. The Jitter Seal does not claim to make simulation impossible, only to make it costly relative to genuine interaction. The forgery-cost- section provides quantified bounds on attack costs. 3.8.3. Attesting Environment Trust The Jitter Seal relies on the Attesting Environment to accurately capture and report timing data. A compromised AE could fabricate jitter data. This is addressed by: 1. Hardware binding (hardware-section) for AE integrity 2. Calibration attestation for VDF speed verification 3. Clear documentation of AE trust assumptions in absence-claim structures (ae-trust-basis field) Chain-verifiable claims (1-15) do not depend on AE trust beyond basic data integrity. Monitoring-dependent claims (16-63) explicitly document their AE trust requirements. 4. Verifiable Delay Functions This section specifies the Verifiable Delay Function (VDF) mechanisms used to establish temporal ordering and minimum elapsed time between checkpoints. The design is algorithm-agile, supporting both iterated hash constructions and succinct VDF schemes. 4.1. VDF Construction A VDF proof appears in each checkpoint and contains the following fields: Condrey Expires 10 August 2026 [Page 43] Internet-Draft Proof of Process February 2026 vdf-proof = { 1 => vdf-algorithm, ; algorithm 2 => vdf-params, ; params 3 => bstr, ; input 4 => bstr, ; output 5 => bstr, ; proof 6 => duration, ; claimed-duration 7 => uint, ; iterations ? 8 => calibration-attestation, ; calibration (RECOMMENDED) } 4.1.1. Algorithm Registry The following VDF algorithms are defined: +=======+========================+================+==============+ | Value | Algorithm | Status | Proof Size | +=======+========================+================+==============+ | 1 | iterated-sha256 | MUST support | 0 (implicit) | +-------+------------------------+----------------+--------------+ | 2 | iterated-sha3-256 | SHOULD support | 0 (implicit) | +-------+------------------------+----------------+--------------+ | 16 | pietrzak-rsa2048 | MAY support | ~1 KB | +-------+------------------------+----------------+--------------+ | 17 | wesolowski-rsa2048 | MAY support | ~256 bytes | +-------+------------------------+----------------+--------------+ | 18 | pietrzak-class-group | MAY support | ~2 KB | +-------+------------------------+----------------+--------------+ | 19 | wesolowski-class-group | MAY support | ~512 bytes | +-------+------------------------+----------------+--------------+ Table 9 Algorithm values 1-15 are reserved for iterated hash constructions. Values 16-31 are reserved for succinct VDF schemes. Values 32+ are available for future allocation. 4.1.2. Iterated Hash Construction The iterated hash VDF computes: output = H^n(input) where H^n denotes n iterations of hash function H: H^0(x) = x H^n(x) = H(H^(n-1)(x)) Parameters for iterated hash VDFs: Condrey Expires 10 August 2026 [Page 44] Internet-Draft Proof of Process February 2026 iterated-hash-params = { 1 => hash-algorithm, ; hash-function 2 => uint, ; iterations-per-second } The iterations-per-second field records the calibrated performance of the Attesting Environment, enabling Verifiers to assess whether the claimed-duration is plausible for the iteration count. Properties of iterated hash VDFs: Verification Cost: O(n) -- Verifier must recompute all iterations. This is acceptable for the iteration counts typical in authoring scenarios (10^6 to 10^9 iterations). Parallelization Resistance: Inherently sequential. Each iteration depends on the previous output. No known parallelization attack. Hardware Acceleration: SHA-256 acceleration (e.g., Intel SHA Extensions, ARM Cryptography Extensions) provides ~3-5x speedup over software. This is accounted for in calibration. 4.1.3. Succinct VDF Construction Succinct VDFs ([Pietrzak2019], [Wesolowski2019]) provide O(log n) or O(1) verification time at the cost of larger proof size and more complex computation. succinct-vdf-params = { 10 => uint, ; modulus-bits (e.g., 2048) ? 11 => uint, ; security-parameter } Key set 10-19 disambiguates succinct params from iterated hash params (key set 1-9) without requiring a type tag. Succinct VDFs are OPTIONAL and intended for scenarios where: * Verification must complete in bounded time regardless of delay duration * Evidence packets may contain very long VDF chains (millions of checkpoints) * Third-party Verifiers cannot afford O(n) recomputation Condrey Expires 10 August 2026 [Page 45] Internet-Draft Proof of Process February 2026 When using succinct VDFs, the proof field contains the cryptographic proof of correct computation. For iterated hash VDFs, the proof field is empty (verification is by recomputation). 4.2. Causality Property The VDF chain establishes unforgeable temporal ordering through structural causality. This is a key novel contribution of the Proof of Process framework. 4.2.1. Checkpoint Entanglement The VDF input for checkpoint N is computed as: VDF_input{N} = H( VDF_output{N-1} || ; Previous VDF output content-hash{N} || ; Current document state jitter-commitment{N} || ; Captured behavioral entropy sequence{N} ; Checkpoint sequence number ) For the genesis checkpoint (N = 0): VDF_input{0} = H( session-entropy || ; Random 256-bit session seed content-hash{0} || ; Initial document state jitter-commitment{0} || 0x00000000 ; Sequence zero ) This construction ensures that: 1. Sequential Dependency: VDF_output{N} cannot be computed without VDF_output{N-1}. The chain is inherently sequential. 2. Content Binding: Each VDF output is bound to a specific document state. Changing the content invalidates all subsequent VDF proofs. 3. Jitter Binding: The behavioral entropy commitment is entangled with the VDF, as detailed in Section 3.3. 4. No Precomputation: Condrey Expires 10 August 2026 [Page 46] Internet-Draft Proof of Process February 2026 The adversary cannot precompute VDF outputs because the input depends on runtime values (content, jitter) that are unknown until the checkpoint is created. 4.2.2. Temporal Ordering Without Trusted Time The causality property provides relative temporal ordering without relying on trusted timestamps: Relative Ordering: Checkpoint N necessarily occurred after checkpoint N-1, because VDF_input{N} requires VDF_output{N-1}. Minimum Elapsed Time: The time between checkpoints N-1 and N is at least: min_elapsed{N} = iterations{N} / calibration_rate where calibration_rate is the attested iterations-per-second for the device. Cumulative Time Bound: The total minimum time to produce the evidence packet is: min_total = sum(iterations[i] / calibration_rate) for i = 0..N Absolute Time Binding: External anchors (RFC 3161 timestamps, blockchain proofs) bind the checkpoint chain to absolute time. The VDF provides the ordering; anchors provide the epoch. 4.2.3. Backdating Resistance An adversary attempting to backdate evidence must: 1. Generate content that produces the desired content-hash 2. Generate jitter data that produces valid entropy-commitment 3. Compute the VDF chain from the backdated checkpoint forward 4. Complete all of the above before any external anchor confirms a later checkpoint The cost of step 3 grows linearly with the number of subsequent checkpoints and the iteration count per checkpoint. This cost is quantified in the forgery-cost-section. Condrey Expires 10 August 2026 [Page 47] Internet-Draft Proof of Process February 2026 Crucially, the adversary cannot parallelize step 3: VDF computation is inherently sequential. Even with unlimited computational resources, the adversary must wait for each VDF to complete before starting the next. 4.3. Calibration Attestation Calibration attestation addresses the verification problem: how does a Verifier know whether the claimed iterations could have been computed in the claimed duration on the Attester's hardware? 4.3.1. Attestation Structure calibration-attestation = { 1 => uint, ; calibration-iterations 2 => pop-timestamp, ; calibration-time 3 => cose-signature, ; hw-signature 4 => bstr, ; device-nonce ? 5 => tstr, ; device-model } calibration-iterations (key 1): The number of VDF iterations completed in a 1-second calibration burst at session start. calibration-time (key 2): Timestamp when calibration was performed. SHOULD be within 24 hours of the first checkpoint. hardware-signed attestation (key 3): COSE_Sign1 signature over the calibration data, produced by hardware-bound keys (Secure Enclave, TPM, etc.). device-nonce (key 4): Random 256-bit value generated at calibration time. Prevents replay of calibration attestations across sessions. device-model (key 5, optional): Human-readable device identifier for reference purposes. Not used in verification. 4.3.2. Calibration Procedure The Attesting Environment performs calibration as follows: 1. Generate Nonce: Generate a cryptographically random 256-bit device-nonce. 2. Initialize Timer: Condrey Expires 10 August 2026 [Page 48] Internet-Draft Proof of Process February 2026 Record high-resolution start time T_start. 3. Execute Calibration Burst: Compute VDF iterations using the session's VDF algorithm, starting from H(device-nonce), until 1 second has elapsed. 4. Record Result: calibration-iterations = number of iterations completed. 5. Generate Attestation: Construct the attestation payload and sign with hardware-bound key. The attestation payload for signing: attestation-payload = CBOR({ "alg": vdf-algorithm, "iter": calibration-iterations, "nonce": device-nonce, "time": calibration-time }) 4.3.3. Calibration Verification A Verifier validates calibration attestation as follows: 1. Signature Verification: Verify the COSE_Sign1 signature using the device's public key (from hardware-section or certificate chain). 2. Nonce Uniqueness: Verify the device-nonce has not been seen in other sessions (optional, requires Verifier state). 3. Plausibility Check: Verify calibration-iterations falls within expected range for the device class: * Mobile devices: 10^5 - 10^7 iterations/second * Desktop/laptop: 10^6 - 10^8 iterations/second Condrey Expires 10 August 2026 [Page 49] Internet-Draft Proof of Process February 2026 * Server-class: 10^7 - 10^9 iterations/second 4. Consistency Check: For each checkpoint, verify: claimed-duration >= iterations / (calibration-iterations * tolerance) where tolerance accounts for measurement variance (RECOMMENDED: 1.1, i.e., 10% margin). 4.3.4. Trust Model Calibration attestation relies on hardware-bound key integrity: * With hardware attestation: The calibration rate is trustworthy to the extent that the hardware security module is trustworthy. An adversary cannot claim faster-than-actual calibration without compromising the HSM. * Without hardware attestation: The calibration rate is self-reported by the Attesting Environment. The Verifier should apply conservative assumptions and may require external anchors for time verification. The hardware-section documents whether hardware attestation is available and which platform is used. 4.4. Verification Procedure A Verifier appraises VDF proofs through the following procedure: 4.4.1. Iterated Hash Verification For iterated hash VDFs, verification requires recomputation: 1. Reconstruct Input: Compute VDF_input{N} from the checkpoint data using the entanglement formula in Section 4.2.1. 2. Recompute VDF: Execute iterations{N} hash iterations starting from VDF_input{N}. 3. Compare Output: Condrey Expires 10 August 2026 [Page 50] Internet-Draft Proof of Process February 2026 Verify the computed output matches the claimed VDF_output{N}. 4. Verify Duration (if calibration present): Apply the consistency check from Section 4.3.3. For large evidence packets, Verifiers MAY use sampling strategies: * Verify first and last checkpoints fully * Randomly sample intermediate checkpoints * Verify chain linkage (prev-hash) for all checkpoints 4.4.2. Succinct VDF Verification For succinct VDFs, verification uses the cryptographic proof: 1. Reconstruct Input: Compute VDF_input{N} as above. 2. Parse Proof: Decode the proof field according to the algorithm specification. 3. Verify Proof: Execute the algorithm-specific verification procedure ([Pietrzak2019] or [Wesolowski2019]). 4. Verify Duration: Apply calibration consistency check. 4.5. Algorithm Agility 4.5.1. Migration Path Evidence packets MAY contain checkpoints using different VDF algorithms. This enables migration scenarios: * Upgrading from iterated-sha256 to iterated-sha3-256 * Transitioning from iterated hash to succinct VDF * Adopting post-quantum secure constructions Condrey Expires 10 August 2026 [Page 51] Internet-Draft Proof of Process February 2026 Algorithm changes SHOULD occur at session boundaries. Within a session, algorithm consistency is RECOMMENDED for simplicity. 4.5.2. Post-Quantum Considerations Current VDF constructions have varying post-quantum security: Iterated Hash (SHA-256, SHA3-256): Grover's algorithm provides quadratic speedup for preimage attacks. This affects collision resistance but not the sequential computation property. The VDF remains secure with doubled iteration counts. RSA-based ([Pietrzak2019], [Wesolowski2019]): Vulnerable to Shor's algorithm. Not recommended for long-term evidence that must remain verifiable in a post-quantum era. Class-group based: Based on class group computations in imaginary quadratic fields. Quantum security is less well understood but believed to be stronger than RSA. For evidence intended to remain valid for decades, iterated hash VDFs are RECOMMENDED. 4.6. Security Considerations 4.6.1. Hardware Acceleration Attacks An adversary with specialized hardware (ASICs, FPGAs) may compute VDF iterations faster than the calibrated rate. Mitigations: * Calibration Reflects Actual Hardware: Calibration is performed on the actual device, so the calibration rate already accounts for any acceleration available to the Attester. * Asymmetric Advantage Limited: SHA-256 is widely optimized. The speedup from custom hardware over commodity CPUs with SHA extensions is typically less than 10x. * Economic Analysis: The forgery-cost-section quantifies the cost of acceleration attacks in terms of hardware investment and time. Condrey Expires 10 August 2026 [Page 52] Internet-Draft Proof of Process February 2026 4.6.2. Parallelization Resistance VDFs are designed to resist parallelization: Iterated Hash: Each iteration depends on the previous output. No parallelization is possible without breaking the hash function's preimage resistance. Succinct VDFs: Based on repeated squaring in groups with unknown order. Parallelization would require factoring the modulus (RSA- based) or solving the class group order problem (class-group based). The key insight: an adversary with P processors cannot compute the VDF P times faster. The best known attacks provide negligible parallelization advantage. 4.6.3. Time-Memory Tradeoffs For iterated hash VDFs, an adversary might attempt to precompute and store intermediate values: * Rainbow Tables: Precomputing H^n(x) for many x values. Mitigated by the unpredictable VDF input (includes content hash and jitter commitment). * Checkpoint Tables: Storing every k-th intermediate value during legitimate computation. Enables faster recomputation from nearby checkpoints but does not help with backdating attacks (which require computing from a specific starting point). No practical time-memory tradeoff significantly reduces the sequential computation requirement. 4.6.4. Calibration Attacks Attacks on the calibration system: Throttled Calibration: Adversary intentionally slows device during calibration to report lower iterations-per-second, then computes VDFs faster than claimed. Condrey Expires 10 August 2026 [Page 53] Internet-Draft Proof of Process February 2026 Mitigation: Plausibility checks based on device class. Anomalously slow calibration for a known device model triggers Verifier skepticism. Calibration Replay: Adversary reuses calibration attestation from a slower device. Mitigation: Device-nonce binds calibration to session. Hardware signature binds to specific device key. Device Key Compromise: Adversary extracts hardware-bound signing key. Mitigation: Hardware security modules are designed to resist key extraction. This attack requires physical access and significant resources. 4.6.5. Timing Side Channels VDF computation timing may leak information: * Iteration Count Inference: Network observers may infer iteration counts from checkpoint timing. This reveals only what is already public in the evidence packet. * Content Inference: VDF computation time is independent of content (fixed iteration count per checkpoint). No content leakage through timing. VDF implementations SHOULD use constant-time hash operations where available, though timing variations in VDF computation itself do not compromise security. 5. Absence Proofs: Negative Evidence This section defines the Absence Proofs mechanism, which enables bounded claims about what did NOT occur during document creation. Unlike positive evidence (proving something happened), absence proofs provide negative evidence (proving something did not happen, within defined bounds and trust assumptions). Condrey Expires 10 August 2026 [Page 54] Internet-Draft Proof of Process February 2026 5.1. Design Philosophy Absence proofs address a fundamental question in process attestation: can we make meaningful claims about events that did not occur? The answer is nuanced and depends on carefully articulated trust boundaries. 5.1.1. The Value of Bounded Claims Traditional evidence systems focus on positive claims: "X happened at time T." Absence proofs extend this to negative claims: "X did not exceed threshold Y during interval (T1, T2)." The value of bounded claims lies in their falsifiability: Positive Claim: "The author typed this document" -- difficult to verify, requires trust in the entire authoring environment. Bounded Negative Claim: "No single edit added more than 500 characters" -- verifiable directly from the checkpoint chain without additional trust assumptions. Bounded claims shift the burden of proof: instead of claiming what DID happen (which requires comprehensive monitoring), we claim what did NOT happen (which can be bounded by observable evidence). 5.1.2. Inherent Limits of Negative Evidence Absence proofs have fundamental limitations that MUST be clearly communicated: * Monitoring Gaps: Absence claims are valid only during monitored intervals. Gaps in monitoring create gaps in absence guarantees. * Trust Boundaries: Some absence claims require trust in the Attesting Environment (AE). This trust must be explicitly documented. * Threshold Semantics: "No paste above 500 characters" does not imply "no paste." Claims are bounded, not absolute. * Behavioral Consistency, Not Authorship: Condrey Expires 10 August 2026 [Page 55] Internet-Draft Proof of Process February 2026 Absence claims describe observable behavioral patterns, NOT authorship, intent, or cognitive processes. They document consistency between declared process and observable evidence. 5.2. Trust Boundary: Chain-Verifiable vs. Monitoring-Dependent The critical architectural distinction in absence proofs is between claims verifiable from the Evidence alone (trustless) and claims that require trust in the Attesting Environment's monitoring capabilities. 5.2.1. Chain-Verifiable Claims (1-15) Chain-verifiable claims can be verified by any party with access to the Evidence packet. No trust in the Attesting Environment is required beyond basic data integrity. These claims are derived purely from the checkpoint chain structure. A Verifier can independently confirm these claims by: 1. Parsing the checkpoint chain 2. Verifying chain integrity (hashes, MACs, VDF linkage) 3. Computing the relevant metrics from checkpoint data 4. Comparing against the claimed thresholds No interaction with the Attester or trust in its monitoring capabilities is needed. 5.2.2. Monitoring-Dependent Claims (16-63) Monitoring-dependent claims require trust that the Attesting Environment correctly observed and reported specific events. These claims cannot be verified from the checkpoint chain alone because they depend on real-time monitoring of events external to the document state. For monitoring-dependent claims, the Verifier must assess: 1. Whether the AE had the capability to observe the relevant events (clipboard access, process enumeration, etc.) 2. Whether the AE was operating with integrity during the monitoring period 3. Whether monitoring was continuous or had gaps Condrey Expires 10 August 2026 [Page 56] Internet-Draft Proof of Process February 2026 4. What attestation (if any) supports the AE integrity claim The ae-trust-basis structure documents these trust assumptions explicitly, enabling informed Relying Party decisions. 5.2.3. Trust Model Comparison +==============+========================+======================+ | Aspect | Chain-Verifiable | Monitoring-Dependent | +==============+========================+======================+ | Verification | Independent, trustless | Requires AE trust | +--------------+------------------------+----------------------+ | Data Source | Checkpoint chain only | Real-time event | | | | monitoring | +--------------+------------------------+----------------------+ | Confidence | Cryptographic proof | AE integrity | | Basis | | attestation | +--------------+------------------------+----------------------+ | Forgery | Requires VDF | Requires AE | | Resistance | recomputation | compromise | +--------------+------------------------+----------------------+ | Claim Types | 1-15 | 16-63 | +--------------+------------------------+----------------------+ Table 10 5.3. Chain-Verifiable Claims (Types 1-15) The following claims can be verified directly from the Evidence packet without trusting the Attesting Environment's monitoring capabilities: +======+=============+======================+=====================+ | Type | Claim | Proves | Verification Method | +======+=============+======================+=====================+ | 1 | max-single- | No single checkpoint | max(delta.chars- | | | delta-chars | added more than N | added) across all | | | | characters | checkpoints | +------+-------------+----------------------+---------------------+ | 2 | max-single- | No single checkpoint | Derived from char | | | delta-bytes | added more than N | counts with | | | | bytes | encoding factor | +------+-------------+----------------------+---------------------+ | 3 | max-net- | No single checkpoint | max(|chars-added - | | | delta-chars | had net change | chars-deleted|) per | | | | exceeding N chars | checkpoint | +------+-------------+----------------------+---------------------+ | 4 | min-vdf- | Total VDF time | sum(claimed- | Condrey Expires 10 August 2026 [Page 57] Internet-Draft Proof of Process February 2026 | | duration- | exceeds N seconds | duration) across | | | seconds | | checkpoints | +------+-------------+----------------------+---------------------+ | 5 | min-vdf- | At least N seconds | total_vdf_seconds / | | | duration- | of VDF time per 1000 | (final_char_count / | | | per-kchar | characters | 1000) | +------+-------------+----------------------+---------------------+ | 6 | checkpoint- | No gaps in | Verify sequence | | | chain- | checkpoint sequence | numbers are | | | complete | | consecutive | +------+-------------+----------------------+---------------------+ | 7 | checkpoint- | All prev-hash values | Verify hash chain | | | chain- | match prior | linkage | | | consistent | checkpoint-hash | | +------+-------------+----------------------+---------------------+ | 8 | jitter- | Captured entropy | sum(estimated- | | | entropy- | exceeds N bits | entropy-bits) from | | | above- | | jitter-binding | | | threshold | | | +------+-------------+----------------------+---------------------+ | 9 | jitter- | Jitter sample count | sum(sample-count) | | | samples- | exceeds N | from jitter-summary | | | above-count | | | +------+-------------+----------------------+---------------------+ | 10 | revision- | Document had at | Count checkpoints | | | points- | least N revision | where chars-deleted | | | above-count | points | > 0 | +------+-------------+----------------------+---------------------+ | 11 | session- | Evidence spans at | Count distinct | | | count- | least N sessions | session boundaries | | | above- | | in chain | | | threshold | | | +------+-------------+----------------------+---------------------+ Table 11 5.3.1. Verification Details For each chain-verifiable claim, the Verifier performs: Condrey Expires 10 August 2026 [Page 58] Internet-Draft Proof of Process February 2026 verify_chain_claim(evidence, claim): (1) Verify chain integrity first if not verify_chain_hashes(evidence.checkpoints): return INVALID("Chain integrity failure") if not verify_vdf_linkage(evidence.checkpoints): return INVALID("VDF linkage failure") (2) Compute the metric from checkpoint data observed_value = compute_metric(evidence.checkpoints, claim.type) (3) Compare against threshold match claim.type: case MAX_SINGLE_DELTA_CHARS: passes = (observed_value <= claim.threshold) case MIN_VDF_DURATION_SECONDS: passes = (observed_value >= claim.threshold) (4) Return verification result if passes: return PROVEN(observed_value, claim.threshold) else: return FAILED(observed_value, claim.threshold) The key property: verification depends ONLY on cryptographically verifiable checkpoint data, not on any external monitoring claims by the AE. 5.4. Monitoring-Dependent Claims (Types 16-63) The following claims require trust in the Attesting Environment's monitoring capabilities. Each claim documents the specific AE capability required and the basis for trusting that capability. +====+=============================+==============+=================+ |Type| Claim |AE Capability |Trust Basis | | | |Required | | +====+=============================+==============+=================+ |16 | max-paste-event-chars |Clipboard |OS-reported paste| | | |monitoring |events | +----+-----------------------------+--------------+-----------------+ |17 | max-clipboard-access-chars |Clipboard |Application-level| | | |content |clipboard hooks | | | |access | | +----+-----------------------------+--------------+-----------------+ |18 | no-paste-from-ai-tool |Clipboard |OS process | | | |source |enumeration + | | | |attribution |clipboard | +----+-----------------------------+--------------+-----------------+ Condrey Expires 10 August 2026 [Page 59] Internet-Draft Proof of Process February 2026 |20 | max-insertion-rate-wpm |Real-time |Input event | | | |keystroke |stream timing | | | |monitoring | | +----+-----------------------------+--------------+-----------------+ |21 | no-automated-input-pattern |Input timing |Statistical | | | |analysis |pattern | | | | |recognition | +----+-----------------------------+--------------+-----------------+ |22 | no-macro-replay-detected |Input source |OS input | | | |verification |subsystem | | | | |attestation | +----+-----------------------------+--------------+-----------------+ |32 | no-file-import-above-bytes |File |Application file | | | |operation |access hooks | | | |monitoring | | +----+-----------------------------+--------------+-----------------+ |33 | no-external-file-open |File system |OS file access | | | |monitoring |events | +----+-----------------------------+--------------+-----------------+ |40 | no-concurrent-ai-tool |Process |OS process list | | | |enumeration |attestation | +----+-----------------------------+--------------+-----------------+ |41 | no-llm-api-traffic |Network |Network stack | | | |traffic |inspection | | | |monitoring | | +----+-----------------------------+--------------+-----------------+ |48 | max-idle-gap-seconds |Continuous |Input event | | | |activity |stream continuity| | | |monitoring | | +----+-----------------------------+--------------+-----------------+ |49 | active-time-above-threshold |Active time |Input event | | | |measurement |correlation | +----+-----------------------------+--------------+-----------------+ Table 12 5.4.1. Trust Basis Documentation Each monitoring-dependent claim MUST include an ae-trust-basis structure that documents the trust assumptions: Condrey Expires 10 August 2026 [Page 60] Internet-Draft Proof of Process February 2026 ae-trust-basis = { 1 => ae-trust-target, ; trust-target 2 => tstr, ; justification 3 => bool, ; verified } ae-trust-target = &( witnessd-software-integrity: 1, os-reported-events: 2, application-reported-events: 3, tpm-attested-elsewhere: 16, se-attested-elsewhere: 17, unverified-assumption: 32, ) witnessd-software-integrity (1): Trust that the witnessd software itself is unmodified and correctly implements monitoring. Requires software attestation or code signing verification. os-reported-events (2): Trust that the operating system correctly reports events (clipboard, process list, file access). Requires OS integrity. application-reported-events (3): Trust that the authoring application correctly reports events. Weakest trust level; application may be compromised. tpm-attested-elsewhere (16): TPM attestation of the AE state exists in the hardware-section. Cross-reference for verification. se-attested-elsewhere (17): Secure Enclave attestation of the AE state exists in the hardware-section. Cross-reference for verification. unverified-assumption (32): The claim is based on assumptions that cannot be verified. Relying Party must decide whether to accept based on context. The justification field provides human-readable explanation of why the trust basis is believed adequate. The verified field indicates whether the trust basis was cryptographically verified (true) or merely assumed (false). 5.5. Monitoring Coverage Honest documentation of monitoring gaps is essential for meaningful absence claims. The monitoring-coverage structure captures the scope and limitations of AE monitoring. Condrey Expires 10 August 2026 [Page 61] Internet-Draft Proof of Process February 2026 monitoring-coverage = { 1 => bool, ; keyboard-monitored 2 => bool, ; clipboard-monitored 3 => [+ time-interval], ; monitoring-intervals 4 => float32, ; coverage-fraction ? 5 => hardware-attestation, ; monitoring-attestation } time-interval = { 1 => pop-timestamp, ; start 2 => pop-timestamp, ; end } 5.5.1. Coverage Fields keyboard-monitored (key 1): Boolean indicating whether keyboard input events were monitored during the session. If false, claims about typing patterns (20-22) cannot be made. clipboard-monitored (key 2): Boolean indicating whether clipboard operations were monitored. If false, claims about paste events (16-18) cannot be made. monitoring-intervals (key 3): Array of time intervals during which monitoring was active. Gaps between intervals represent periods where monitoring was suspended (application backgrounded, system sleep, etc.). coverage-fraction (key 4): Fraction of total session time covered by monitoring, calculated as sum(interval_duration) / total_session_duration. Values below 0.95 indicate significant monitoring gaps that may affect absence claim confidence. monitoring-attestation (key 5, optional): Hardware attestation that monitoring was active during the claimed intervals. Provides stronger assurance than self-reported coverage. 5.5.2. Gap Semantics Monitoring gaps have explicit semantic impact on absence claims: * Covered Intervals: Absence claims apply fully during covered intervals. "No paste above 500 chars during (T1, T2)" means the AE would have detected any such paste. * Gap Intervals: Condrey Expires 10 August 2026 [Page 62] Internet-Draft Proof of Process February 2026 During gaps, monitoring-dependent claims cannot be made. An event could have occurred unobserved. * Gap-Aware Claims: If coverage-fraction is below 1.0, absence claims SHOULD include a caveat noting the monitoring gap percentage. Chain-verifiable claims (1-15) are NOT affected by monitoring gaps because they are derived from the checkpoint chain, which has no gaps (checkpoint-chain-complete verifies this). 5.6. Absence Section Structure The absence-section appears as an optional field (key 15) in the evidence-packet: absence-section = { 1 => monitoring-coverage, ; monitoring-coverage 2 => [+ absence-claim], ; claims ? 3 => claim-summary, ; claim-summary } claim-summary = { 1 => uint, ; chain-verifiable-count 2 => uint, ; monitoring-dependent-count 3 => bool, ; all-claims-attested } absence-claim = { 1 => absence-claim-type, ; claim-type 2 => absence-threshold, ; threshold 3 => absence-proof, ; proof 4 => absence-confidence, ; confidence ? 5 => ae-trust-basis, ; ae-trust-basis (monitoring) } absence-threshold = { 1 => uint / float32 / null, ; value } absence-proof = { 1 => absence-proof-method, ; proof-method 2 => absence-evidence, ; evidence } absence-proof-method = &( checkpoint-chain-analysis: 1, Condrey Expires 10 August 2026 [Page 63] Internet-Draft Proof of Process February 2026 keystroke-analysis: 2, platform-attestation: 3, network-attestation: 4, statistical-inference: 5, ) absence-evidence = { ? 1 => [uint, uint], ; checkpoint-range ? 2 => uint, ; max-observed-value ? 3 => float32, ; max-observed-rate ? 4 => tstr, ; statistical-test ? 5 => float32, ; p-value ? 6 => bstr, ; attestation-ref } absence-confidence = { 1 => confidence-level, ; level 2 => [* tstr], ; caveats } confidence-level = &( proven: 1, high: 2, medium: 3, low: 4, ) 5.6.1. Confidence Levels proven (1): The claim is cryptographically provable from the Evidence. Only chain-verifiable claims (1-15) can achieve this level. high (2): Strong evidence supports the claim. For monitoring- dependent claims, requires hardware attestation of AE integrity and high monitoring coverage (>95%). medium (3): Reasonable evidence supports the claim. AE integrity is assumed but not hardware-attested. Monitoring coverage is acceptable (>80%). low (4): Weak evidence supports the claim. Significant caveats apply. Monitoring gaps exist or AE trust basis is unverified. 5.7. Verification Procedure A Verifier appraises absence claims through a structured procedure that distinguishes chain-verifiable from monitoring-dependent claims: Condrey Expires 10 August 2026 [Page 64] Internet-Draft Proof of Process February 2026 5.7.1. Step 1: Verify Chain-Verifiable Claims For claims with type 1-15: 1. Verify Evidence Integrity: Verify checkpoint chain hashes, VDF linkage, and structural validity per the base protocol. 2. Extract Metrics: Compute the relevant metric from checkpoint data (e.g., max delta chars, total VDF duration). 3. Compare Threshold: Verify the computed metric satisfies the claimed threshold. 4. Assign Confidence: Chain-verifiable claims that pass receive confidence level "proven" (1). 5.7.2. Step 2: Appraise Monitoring-Dependent Claims For claims with type 16-63: 1. Assess AE Trust Basis: Examine the ae-trust-basis for each claim. Determine whether the trust target is appropriate for the claim type and whether it was verified. 2. Evaluate Monitoring Coverage: Check monitoring-coverage to determine whether the relevant monitoring was active. Verify coverage-fraction is adequate for the confidence level claimed. 3. Cross-Reference Hardware Attestation: If ae-trust-target is tpm-attested-elsewhere (16) or se-attested- elsewhere (17), verify the corresponding attestation exists in hardware-section. 4. Evaluate Evidence: Condrey Expires 10 August 2026 [Page 65] Internet-Draft Proof of Process February 2026 Examine the absence-evidence for supporting data. Statistical tests should have appropriate p-values; attestation references should be verifiable. 5. Assign Confidence: Based on the above factors, assign confidence level (2-4). Level 1 (proven) is NOT available for monitoring-dependent claims. 6. Document Caveats: Record any limitations or assumptions in the caveats array of the verification result. 5.7.3. Step 3: Produce Verification Summary The Verifier produces a result-claim for each absence-claim examined: result-claim = { 1 => uint, ; claim-type 2 => bool, ; verified (claim holds) ? 3 => tstr, ; detail (reasoning) ? 4 => confidence-level, ; claim-confidence } The aggregated results appear in the attestation-result (.war file) as the verified-claims array. 5.8. RATS Architecture Mapping Absence proofs extend the RATS (Remote ATtestation procedureS) evidence model [RFC9334] in several ways: 5.8.1. Role Distribution Attester Responsibility: The Attester (witnessd AE) generates absence claims based on its monitoring observations. For chain- verifiable claims, the Attester merely assembles checkpoint data in a format that enables Verifier computation. For monitoring- dependent claims, the Attester makes assertions about events it observed (or did not observe). Verifier Responsibility: The Verifier independently verifies chain- verifiable claims by recomputing metrics from Evidence. For monitoring-dependent claims, the Verifier appraises the trust basis and determines whether to accept the Attester's monitoring assertions. Condrey Expires 10 August 2026 [Page 66] Internet-Draft Proof of Process February 2026 Relying Party Responsibility: The Relying Party consumes the attestation-result (.war file) and decides whether the verified claims meet their requirements. Different use cases may require different confidence levels or claim types. 5.8.2. Evidence Model Extension Standard RATS evidence attests to system state (software versions, configuration). Absence proofs add a new category: State Evidence (traditional RATS): "The system was in configuration C at time T." Behavioral Consistency Evidence (absence proofs): "Observable behavior during interval (T1, T2) was consistent with constraint X." This extension enables attestation about processes, not just states. The checkpoint chain provides the evidentiary basis for process claims that would otherwise require continuous trusted monitoring. 5.8.3. Appraisal Policy Integration Verifiers MAY define appraisal policies that specify: * Which absence claim types are required for acceptance * Minimum confidence levels for each claim type * Required trust basis for monitoring-dependent claims * Minimum monitoring coverage thresholds Example policy (informative): policy: required_claims: - type: 1 # max-single-delta-chars threshold: 500 min_confidence: proven - type: 4 # min-vdf-duration-seconds threshold: 3600 min_confidence: proven - type: 16 # max-paste-event-chars threshold: 200 min_confidence: high required_trust_basis: (1, 16, 17) (SE or TPM attested) min_monitoring_coverage: 0.95 Condrey Expires 10 August 2026 [Page 67] Internet-Draft Proof of Process February 2026 5.9. Security Considerations 5.9.1. What Absence Claims Do NOT Prove Absence claims have explicit limits that MUST be understood by all parties: Absence claims do NOT prove authorship: "No single edit added more than 500 characters" does not prove who performed the edits. It proves only that the observable edit pattern had this property. Absence claims do NOT prove intent: "No paste from AI tool detected" does not prove the author intended to write without AI assistance. The author may have used AI tools in ways that evade detection. Absence claims do NOT prove cognitive process: Behavioral patterns consistent with human typing do not prove human cognition produced the content. The claims describe observable behavior, not mental states. Absence claims do NOT prove completeness: Claims apply only to monitored intervals. Events during monitoring gaps are not covered by absence claims. Framing claims as "behavioral consistency" rather than "human authorship" avoids overclaiming and maintains intellectual honesty about what the evidence actually shows. 5.9.2. Attesting Environment Compromise Monitoring-dependent claims are only as trustworthy as the Attesting Environment: * Software Compromise: Modified witnessd software could fabricate monitoring observations. Mitigated by code signing and software attestation. * OS Compromise: Compromised OS could report false clipboard contents or process lists. Mitigated by hardware attestation of OS integrity. * Hardware Compromise: Physical access to device could enable hardware-level attacks. This is outside the threat model for most use cases. Condrey Expires 10 August 2026 [Page 68] Internet-Draft Proof of Process February 2026 The ae-trust-basis structure explicitly documents which trust assumptions apply, enabling Relying Parties to make informed decisions about acceptable risk. 5.9.3. Monitoring Evasion Sophisticated adversaries may attempt to evade monitoring: Timing-Based Evasion: Performing prohibited actions during monitoring gaps. Mitigated by high coverage requirements and gap documentation. Tool-Based Evasion: Using tools not in the detection list (e.g., novel AI tools). The claim "no-concurrent-ai-tool" refers to known tools; unknown tools may evade detection. Channel-Based Evasion: Using alternative input channels (screen readers, accessibility features) not monitored by the AE. Mitigated by comprehensive input monitoring. Simulation: Generating input patterns that mimic human behavior. The jitter-seal and VDF mechanisms make this costly but not impossible. See forgery-cost-section. Absence proofs do not claim to make evasion impossible, only to make it costly and to document the monitoring coverage that was actually achieved. 5.9.4. Statistical Claim Limitations Claims based on statistical inference (proof-method 5) have inherent uncertainty: * p-values indicate probability, not certainty * Multiple testing increases false positive risk * Adversarial inputs may exploit statistical assumptions Statistical claims SHOULD be assigned confidence level "medium" (3) or "low" (4) unless supported by additional evidence. 5.10. Privacy Considerations Absence claims may reveal information about the authoring process: * Edit Pattern Disclosure: Condrey Expires 10 August 2026 [Page 69] Internet-Draft Proof of Process February 2026 Chain-verifiable claims reveal aggregate statistics about edit sizes and frequencies. This is inherent in the checkpoint chain and cannot be hidden without removing the evidentiary basis for claims. * Tool Usage Disclosure: Claims like "no-concurrent-ai-tool" implicitly reveal that the AE was monitoring for AI tool usage. Users should be informed of this monitoring. * Behavioral Fingerprinting: Detailed jitter data and monitoring observations could theoretically enable behavioral fingerprinting. The histogram aggregation in jitter-binding mitigates this for timing data. Users SHOULD be informed which absence claims will be generated and have the option to disable specific monitoring capabilities if privacy concerns outweigh the value of those claims. 6. Forgery Cost Bounds (Quantified Security) This section defines the forgery cost bounds mechanism, which provides quantified security analysis for Proof of Process evidence. Rather than claiming evidence is "secure" or "insecure" in absolute terms, this framework expresses security as minimum resource costs that an adversary must expend to produce counterfeit evidence. 6.1. Design Philosophy Traditional security claims are often binary: a system is either "secure" or "broken." This framing poorly serves attestation scenarios where: * Adversary capabilities vary across resource levels * Evidence value degrades gracefully rather than failing completely * Relying Parties have different risk tolerances * Hardware costs and computational speeds change over time The Proof of Process framework adopts quantified security: expressing security guarantees in terms of measurable costs (time, entropy, economic resources) that bound adversary capabilities. Condrey Expires 10 August 2026 [Page 70] Internet-Draft Proof of Process February 2026 6.1.1. Cost-Asymmetric Forgery The design goal is cost asymmetry: producing genuine evidence should be inexpensive (a natural byproduct of authoring), while producing counterfeit evidence should require resources disproportionate to any benefit gained. Cost asymmetry is achieved through three mechanisms: Time Asymmetry (VDF): Genuine evidence accumulates VDF proofs during natural authoring time. Forgery requires recomputing the VDF chain, which cannot be parallelized. The adversary must spend wall-clock time proportional to the claimed authoring duration. Entropy Asymmetry (Jitter Seal): Genuine evidence captures behavioral entropy that exists only at the moment of observation. Forgery requires either guessing the entropy commitment (computationally infeasible) or simulating human input patterns in real time (bounded by the same VDF constraints). Economic Asymmetry (Resource Cost): The combined time and entropy requirements translate to economic costs. Forging evidence for a 10-hour authoring session requires at minimum 10 hours of compute time plus specialized resources, making mass forgery economically impractical. 6.1.2. What Forgery Cost Bounds Do NOT Claim Forgery cost bounds explicitly avoid claims that evidence is: * *Unforgeable:* Given sufficient resources, any evidence can be forged. The bounds quantify "sufficient." * *Guaranteed authentic:* Bounds express minimum forgery costs, not maximum. Cheaper attacks may exist that have not been discovered. * *Irrefutable proof:* Evidence supports claims with quantified confidence, not mathematical certainty. * *Permanent:* Cost bounds depreciate as hardware improves. Evidence verified today may have different bounds when re- evaluated in the future. 6.2. Forgery Cost Section Structure The forgery-cost-section appears in each evidence packet and contains four required components: Condrey Expires 10 August 2026 [Page 71] Internet-Draft Proof of Process February 2026 forgery-cost-section = { 1 => time-bound, ; time-bound 2 => entropy-bound, ; entropy-bound 3 => economic-bound, ; economic-bound 4 => security-statement, ; security-statement } These components represent orthogonal dimensions of forgery cost. A complete security assessment considers all four dimensions. 6.3. Time Bound The time-bound quantifies the minimum wall-clock time required to recompute the VDF chain, establishing a lower bound on forgery duration. time-bound = { 1 => uint, ; total-iterations 2 => uint, ; calibration-rate 3 => tstr, ; reference-hardware 4 => float32, ; min-recompute-seconds 5 => bool, ; parallelizable ? 6 => uint, ; max-parallelism } 6.3.1. Field Definitions total-iterations (key 1): Sum of all VDF iterations across all checkpoints in the evidence packet, computed as sum(checkpoint{i}.vdf-proof.iterations) for all i. calibration-rate (key 2): The attested iterations-per-second from the calibration attestation. This represents the maximum VDF computation speed on the Attesting Environment's hardware. reference-hardware (key 3): Human-readable description of the hardware used for calibration (e.g., "Apple M2 Pro", "Intel i9-13900K"). Used for plausibility assessment, not verification. min-recompute-seconds (key 4): Minimum wall-clock seconds required to recompute the VDF chain on reference hardware, calculated as total-iterations / calibration-rate. This is a lower bound: actual recomputation on slower hardware takes longer. parallelizable (key 5): Boolean indicating whether the VDF algorithm permits parallelization. For iterated hash VDFs (algorithms 1-15), this is always false. For certain succinct VDF constructions, limited parallelization may be possible. Condrey Expires 10 August 2026 [Page 72] Internet-Draft Proof of Process February 2026 max-parallelism (key 6, optional): If parallelizable is true, the maximum parallel speedup factor. For iterated hash VDFs, this field is absent. 6.3.2. Time Bound Verification A Verifier computes and validates the time bound as follows: 1. Sum Iterations: Traverse all checkpoints and sum the iterations field from each VDF proof. 2. Verify Calibration: If calibration attestation is present, verify the hardware signature and check that calibration-rate matches the attested iterations-per-second. 3. Compute Minimum Time: Divide total-iterations by calibration-rate. Verify the result matches min-recompute-seconds within floating-point tolerance. 4. Plausibility Check: Verify min-recompute-seconds is consistent with the claimed authoring duration. Significant discrepancy (e.g., 10-hour claimed session with 1-minute VDF time) indicates either misconfiguration or potential manipulation. 6.3.3. Parallelization Resistance The security of time bounds depends on VDF parallelization resistance. For iterated hash VDFs: * Each iteration depends on the previous output * No known technique computes H^n(x) faster than n sequential hash operations * An adversary with P processors cannot compute the chain P times faster This property ensures that time bounds reflect wall-clock time, not aggregate compute time. An adversary with a data center cannot forge 10 hours of evidence in 10 minutes by using 60x more processors. Condrey Expires 10 August 2026 [Page 73] Internet-Draft Proof of Process February 2026 See Section 4.6.2 for detailed analysis of parallelization resistance in each VDF algorithm. 6.4. Entropy Bound The entropy-bound quantifies the unpredictability in the evidence chain, establishing a lower bound on the probability of guessing or replaying entropy commitments. entropy-bound = { 1 => float32, ; total-entropy-bits 2 => uint, ; sample-count 3 => float32, ; entropy-per-sample 4 => float32, ; brute-force-probability 5 => bool, ; replay-possible ? 6 => tstr, ; replay-prevention } 6.4.1. Field Definitions total-entropy-bits (key 1): Aggregate entropy across all Jitter Seals in the evidence packet, expressed in bits. Computed as sum(jitter-summary[i].estimated-entropy-bits) for all i. sample-count (key 2): Total number of timing samples captured across all Jitter Seals. Higher sample counts increase confidence in the entropy estimate. entropy-per-sample (key 3): Average entropy contribution per timing sample, calculated as total-entropy-bits / sample-count. Typical human typing contributes 2-4 bits per inter-key interval. brute-force-probability (key 4): Probability of successfully guessing the entropy commitment by brute force, calculated as 2^(- total-entropy-bits). For 64 bits of entropy, this is approximately 5.4 x 10^-20. replay-possible (key 5): Boolean indicating whether Jitter Seal replay is theoretically possible. This is false when VDF entanglement is properly configured (entropy commitment appears in VDF input). replay-prevention (key 6, optional): Human-readable description of replay prevention mechanisms. Typical value: "VDF entanglement with prev-checkpoint binding". Condrey Expires 10 August 2026 [Page 74] Internet-Draft Proof of Process February 2026 6.4.2. Entropy Bound Verification A Verifier computes and validates the entropy bound as follows: 1. Aggregate Entropy: Sum estimated-entropy-bits from each checkpoint's jitter-summary. Verify the total matches total-entropy-bits. 2. Count Samples: Sum sample-count from each jitter-summary. Verify consistency with the claimed sample-count. 3. Verify Entropy Estimates: If raw-intervals are disclosed, recompute the histogram and Shannon entropy. Verify consistency with the claimed entropy estimate. 4. Check Replay Prevention: Verify each entropy-commitment appears in the corresponding VDF input. If VDF entanglement is absent, set replay-possible to true. 5. Compute Brute-Force Probability: Calculate 2^(-total-entropy-bits) and verify it matches the claimed brute-force-probability within floating-point tolerance. 6.4.3. Minimum Entropy Requirements RECOMMENDED minimum entropy thresholds by evidence tier: +==========+===================+=========================+ | Tier | Min Total Entropy | Brute-Force Probability | +==========+===================+=========================+ | Basic | 32 bits | < 2.3 x 10^-10 | +----------+-------------------+-------------------------+ | Standard | 64 bits | < 5.4 x 10^-20 | +----------+-------------------+-------------------------+ | Enhanced | 128 bits | < 2.9 x 10^-39 | +----------+-------------------+-------------------------+ Table 13 Condrey Expires 10 August 2026 [Page 75] Internet-Draft Proof of Process February 2026 Evidence packets failing to meet minimum entropy thresholds SHOULD be flagged in the security-statement caveats. 6.5. Economic Bound The economic-bound translates time and entropy requirements into monetary costs, enabling Relying Parties to assess forgery feasibility in economic terms. economic-bound = { 1 => tstr, ; cost-model-version 2 => pop-timestamp, ; cost-model-date 3 => cost-estimate, ; compute-cost 4 => cost-estimate, ; time-cost 5 => cost-estimate, ; total-min-cost 6 => cost-estimate, ; cost-per-hour-claimed } cost-estimate = { 1 => float32, ; usd 2 => float32, ; usd-low 3 => float32, ; usd-high 4 => tstr, ; basis } 6.5.1. Field Definitions cost-model-version (key 1): Identifier for the cost model used (e.g., "witnessd-cost-2025Q1"). Cost models are versioned because hardware prices and computational costs change over time. cost-model-date (key 2): Timestamp when the cost model was established. Cost estimates should be re-evaluated if the model is more than 12 months old. compute-cost (key 3): Cost of computational resources required to recompute the VDF chain. Includes: * Cloud compute instance cost for min-recompute-seconds * Electricity cost for sustained computation * Amortized hardware cost if using dedicated equipment time-cost (key 4): Opportunity cost of the wall-clock time required for forgery. An adversary attempting to forge 10-hour evidence cannot use that time for other purposes. This is modeled as the economic value of the adversary's time. Condrey Expires 10 August 2026 [Page 76] Internet-Draft Proof of Process February 2026 total-min-cost (key 5): Minimum total cost to forge the evidence, combining compute and time costs. This is the primary metric for cost-benefit analysis. cost-per-hour-claimed (key 6): Forgery cost normalized by claimed authoring duration, calculated as total-min-cost / claimed- duration-hours. This metric enables comparison across evidence packets of different lengths. 6.5.2. Cost Estimate Structure Each cost-estimate includes a point estimate and confidence range: usd (key 1): Point estimate in US dollars. This is the expected cost under typical assumptions. usd-low (key 2): Lower bound of 90% confidence interval. Represents cost assuming adversary has access to discounted resources. usd-high (key 3): Upper bound of 90% confidence interval. Represents cost assuming adversary must acquire resources at market rates. basis (key 4): Human-readable description of the cost calculation basis (e.g., "AWS c7i.large @ $0.085/hr + $0.10/kWh electricity"). 6.5.3. Cost Computation Reference cost computation for compute-cost: Compute cost model: hourly_rate = cloud_rate + elec_rate * power compute_hours = min_recompute_seconds / 3600 compute_cost_usd = hourly_rate * compute_hours Confidence interval (assumes 50% rate variance): compute_cost_low = compute_cost_usd * 0.5 compute_cost_high = compute_cost_usd * 1.5 Reference cost computation for time-cost: Time cost model (opportunity cost, skilled labor rate): hourly_value = 50.0 time_cost_usd = hourly_value * (min_recompute_seconds / 3600) Confidence interval (labor rate variance): time_cost_low = time_cost_usd * 0.2 time_cost_high = time_cost_usd * 4.0 Condrey Expires 10 August 2026 [Page 77] Internet-Draft Proof of Process February 2026 These are reference calculations. Implementations MAY use different cost models appropriate to their deployment context. 6.5.4. Cost Model Depreciation Hardware costs decrease and computational speeds increase over time. Cost estimates depreciate accordingly: * Moore's Law Effect: Compute cost per operation halves approximately every 2 years. A cost model from 2023 overestimates 2025 forgery costs by roughly 2x. * Hardware Acceleration: New hardware (GPUs, ASICs) may provide step-function improvements for specific algorithms. Cost models should be updated when significant new hardware becomes available. * Cloud Pricing: Cloud compute costs generally decrease over time. Cost models should reference current pricing. Verifiers SHOULD apply a depreciation adjustment when evaluating cost bounds with cost-model-date more than 12 months in the past: years_elapsed = (current_date - cost_model_date) / 365 depreciation_factor = 0.7 ^ years_elapsed # ~30% annual decrease adjusted_cost = original_cost * depreciation_factor 6.6. Security Statement The security-statement provides a formal claim about the evidence security, including explicit assumptions and caveats. Condrey Expires 10 August 2026 [Page 78] Internet-Draft Proof of Process February 2026 security-statement = { 1 => tstr, ; claim 2 => formal-security-bound, ; formal 3 => [+ tstr], ; assumptions 4 => [* tstr], ; caveats } formal-security-bound = { 1 => float32, ; min-seconds 2 => float32, ; min-entropy-bits 3 => float32, ; min-cost-usd } 6.6.1. Field Definitions claim (key 1): Human-readable security claim. MUST be phrased as a minimum bound, not an absolute guarantee. Example: "Forging this evidence requires at minimum 8.3 hours of sequential computation, 67 bits of entropy prediction, and an estimated $42-$126 in resources." formal (key 2): Machine-readable security bounds for automated policy evaluation. assumptions (key 3): List of assumptions under which the security claim holds. MUST include at minimum: * Cryptographic assumption (e.g., "SHA-256 preimage resistance") * Hardware assumption (e.g., "Calibration attestation is accurate") * Adversary model (e.g., "Adversary cannot parallelize VDF computation") caveats (key 4): List of limitations or warnings about the security claim. Examples: * "Cost estimates based on 2024Q4 cloud pricing" * "Entropy estimate assumes timing samples are independent" * "Does not protect against Attesting Environment compromise" Condrey Expires 10 August 2026 [Page 79] Internet-Draft Proof of Process February 2026 6.6.2. Formal Security Bound The formal-security-bound provides three orthogonal minimum requirements for forgery: min-seconds (key 1): Minimum wall-clock seconds to forge the evidence. Derived from time-bound.min-recompute-seconds. min-entropy-bits (key 2): Minimum entropy bits an adversary must predict or generate. Derived from entropy-bound.total-entropy- bits. min-cost-usd (key 3): Minimum cost in USD to forge the evidence. Derived from economic-bound_total-min-cost_usd-low (conservative estimate). Relying Parties can evaluate these bounds against their risk tolerance. For example, a policy might require: Example Relying Party policy: accept_evidence if: min-seconds >= 3600 AND (At least 1 hour) min-entropy-bits >= 64 AND (At least 64 bits) min-cost-usd >= 100 (At least $100) 6.7. Verification Procedure A Verifier computes and validates forgery cost bounds through the following procedure: 1. Compute Time Bound: Sum VDF iterations across all checkpoints. Retrieve calibration- rate from calibration attestation. Compute min-recompute-seconds = total-iterations / calibration-rate. 2. Compute Entropy Bound: Aggregate entropy estimates from all Jitter Seals. Verify VDF entanglement for each seal. Compute brute-force probability. 3. Compute Economic Bound: Apply cost model to time bound. Compute confidence intervals. Normalize by claimed duration. 4. Construct Security Statement: Condrey Expires 10 August 2026 [Page 80] Internet-Draft Proof of Process February 2026 Generate human-readable claim. Populate formal bounds. List applicable assumptions. Add any relevant caveats. 5. Validate Claimed Bounds: Compare computed bounds against those claimed in the evidence packet. Flag discrepancies exceeding tolerance. 6. Apply Depreciation: If cost-model-date is stale, apply depreciation adjustment to economic bounds. The Verifier MAY recompute bounds using its own cost model rather than accepting the Attester's claimed bounds. Independent recomputation is RECOMMENDED for high-stakes verification. 6.8. Security Considerations 6.8.1. Assumed Adversary Capabilities Forgery cost bounds assume an adversary with: * Access to commodity hardware at market prices * Ability to execute VDF algorithms correctly * No ability to parallelize inherently sequential VDFs * No ability to predict behavioral entropy in advance * No compromise of the Attesting Environment during evidence generation Bounds may not hold against adversaries who: * Have access to specialized hardware (ASICs) at below-market cost * Can compromise the Attesting Environment * Discover novel attacks on VDF or hash function constructions * Have access to quantum computers capable of breaking cryptographic assumptions Condrey Expires 10 August 2026 [Page 81] Internet-Draft Proof of Process February 2026 6.8.2. Limitations of Cost Bounds Forgery cost bounds provide lower bounds, not guarantees: Unknown Attacks: The bounds assume current best-known attacks. Future cryptanalytic advances may reduce actual forgery costs. Cost Model Accuracy: Economic estimates depend on cost model assumptions. Actual adversary costs may differ based on resource access. Entropy Estimation: Shannon entropy estimates assume independent samples. Correlations in timing data may reduce effective entropy. Calibration Trust: Time bounds depend on calibration accuracy. Without hardware attestation, calibration is self-reported and may be manipulated. 6.8.3. What Bounds Do NOT Guarantee Forgery cost bounds explicitly do NOT provide: * Authenticity Proof: Evidence meeting cost thresholds is not proven authentic. It is proven expensive to forge. These are distinct claims. * Content Verification: Bounds say nothing about document content, quality, or accuracy. Only the process evidence is bounded. * Intent Attribution: Bounds do not prove who created the evidence or why. Identity and intent are outside the scope of cost analysis. * Long-Term Security: Bounds depreciate over time. Evidence considered secure today may have insufficient bounds in 10 years. 6.8.4. Policy Guidance for Relying Parties Relying Parties should establish policies based on: 1. Risk Assessment: Condrey Expires 10 August 2026 [Page 82] Internet-Draft Proof of Process February 2026 What is the cost of accepting forged evidence? High-stakes decisions require higher cost thresholds. 2. Adversary Economics: Would forgery be economically rational? If forgery costs exceed potential gain, rational adversaries will not attempt it. 3. Time Sensitivity: How quickly must evidence be verified? Long verification delays may reduce the utility of cost bounds. 4. Corroborating Evidence: Cost bounds are one factor among many. External anchors, hardware attestation, and contextual information all contribute to overall confidence. 7. Cross-Document Provenance Links This section defines a mechanism for establishing cryptographic relationships between Evidence packets. Provenance links enable authors to prove that one document evolved from, merged with, or was derived from other documented works. 7.1. Motivation Real-world authorship rarely occurs in isolation. Documents evolve through multiple stages: * Research notes become draft papers become published articles * Multiple contributors merge their sections into a collaborative work * A thesis chapter is extracted and expanded into a standalone paper * A codebase is forked, modified, and the changes documented Without provenance links, each Evidence packet is cryptographically isolated. An author cannot prove that their final manuscript evolved from the lab notes they documented six months earlier. Provenance links provide this capability while maintaining the privacy and security properties of witnessd Evidence. Condrey Expires 10 August 2026 [Page 83] Internet-Draft Proof of Process February 2026 7.2. Provenance Section Structure The provenance section is an optional component of the Evidence packet, identified by integer key 20. When present, it documents the relationship between the current Evidence packet and one or more parent packets. ; Provenance section for cross-document linking ; Key 20 in evidence-packet provenance-section = { ? 1 => [+ provenance-link], ; parent-links ? 2 => [+ derivation-claim], ; derivation-claims ? 3 => provenance-metadata, ; metadata } ; Link to a parent Evidence packet provenance-link = { 1 => uuid, ; parent-packet-id 2 => hash-value, ; parent-chain-hash 3 => derivation-type, ; how this document relates 4 => pop-timestamp, ; when derivation occurred ? 5 => tstr, ; relationship-description ? 6 => [+ uint], ; inherited-checkpoints ? 7 => cose-signature, ; cross-packet-attestation } ; Type of derivation relationship derivation-type = &( continuation: 1, ; same work, new packet merge: 2, ; from multiple sources split: 3, ; Extracted from larger work rewrite: 4, ; Substantial revision translation: 5, ; Language translation fork: 6, ; independent branch citation-only: 7, ; references only ) ; Claims about what was derived and how derivation-claim = { 1 => derivation-aspect, ; what-derived 2 => derivation-extent, ; extent ? 3 => tstr, ; description ? 4 => float32, ; estimated-percentage } derivation-aspect = &( structure: 1, ; Document organization content: 2, ; Textual content Condrey Expires 10 August 2026 [Page 84] Internet-Draft Proof of Process February 2026 ideas: 3, ; Conceptual elements data: 4, ; Data or results methodology: 5, ; Methods or approach code: 6, ; Source code ) derivation-extent = &( none: 0, ; Not derived minimal: 1, ; Less than 10% partial: 2, ; 10-50% substantial: 3, ; 50-90% complete: 4, ; More than 90% ) ; Optional metadata about provenance provenance-metadata = { ? 1 => tstr, ; provenance-statement ? 2 => bool, ; all-parents-available ? 3 => [+ tstr], ; missing-parent-reasons } 7.3. Verification of Provenance Links Verifiers MUST perform the following checks when provenance links are present: 7.3.1. Parent Chain Hash Verification For each provenance-link, if the parent Evidence packet is available: 1. Verify that parent-packet-id matches the packet-id field of the parent Evidence packet. 2. Verify that parent-chain-hash matches the checkpoint-hash of the final checkpoint in the parent Evidence packet. 3. Verify that the derivation timestamp is not earlier than the created timestamp of the parent packet. If the parent Evidence packet is not available, the Verifier SHOULD note this limitation in the Attestation Result caveats. The provenance link remains valid but unverified. 7.3.2. Cross-Packet Attestation When cross-packet-attestation is present, it provides cryptographic proof that the author of the current packet had access to the parent packet at the time of derivation: Condrey Expires 10 August 2026 [Page 85] Internet-Draft Proof of Process February 2026 cross-packet-attestation = COSE_Sign1( payload = CBOR_encode({ 1: current-packet-id, 2: parent-packet-id, 3: parent-chain-hash, 4: derivation-timestamp, }), key = author-signing-key ) This attestation prevents retroactive provenance claims where an author discovers an existing Evidence packet and falsely claims derivation after the fact. 7.4. Privacy Considerations for Provenance Provenance links may reveal information about the author's creative process and document history. Authors SHOULD consider: * Parent packet IDs are disclosed to anyone with access to the child packet. * If parent packets use the author-salted hash mode, the salt MUST be shared for full verification. * Derivation claims may reveal collaboration patterns or research relationships. Authors MAY choose to omit provenance links for privacy while still maintaining independent Evidence for each document. 7.5. Provenance Link Examples 7.5.1. Continuation Example A dissertation written over 18 months with monthly Evidence exports: Condrey Expires 10 August 2026 [Page 86] Internet-Draft Proof of Process February 2026 provenance-section = { 1: [ / parent-links / { 1: h'550e8400e29b41d4a716446655440000', / parent-packet-id / 2: {1: 1, 2: h'abcd1234...'}, / parent-chain-hash / 3: 1, / type: continuation / 4: 1(1709251200), / Feb 2024 / 5: "Continued from January 2024 export" } ], 3: { / metadata / 1: "This is month 2 of an ongoing dissertation project", 2: true / all-parents-available / } } 7.5.2. Merge Example A collaborative paper merging contributions from three authors: Condrey Expires 10 August 2026 [Page 87] Internet-Draft Proof of Process February 2026 provenance-section = { 1: [ / parent-links / { 1: h'author1-packet-uuid...', 2: {1: 1, 2: h'hash1...'}, 3: 2, / merge / 4: 1(1709337600), 5: "Alice's methodology section" }, { 1: h'author2-packet-uuid...', 2: {1: 1, 2: h'hash2...'}, 3: 2, / merge / 4: 1(1709337600), 5: "Bob's results section" }, { 1: h'author3-packet-uuid...', 2: {1: 1, 2: h'hash3...'}, 3: 2, / merge / 4: 1(1709337600), 5: "Carol's introduction and discussion" } ], 2: [ / derivation-claims / {1: 1, 2: 3, 3: "Structure from Alice's draft"}, {1: 2, 2: 2, 3: "Content merged from all three"}, {1: 4, 2: 4, 3: "Data primarily from Bob"} ] } 8. Incremental Evidence with Continuation Tokens This section defines a mechanism for producing Evidence packets incrementally over extended authoring periods. Continuation tokens allow a single logical authorship effort to be documented across multiple Evidence packets without losing cryptographic continuity. 8.1. Motivation Long-form works such as novels, dissertations, or technical books may span months or years of active authorship. Capturing all Evidence in a single packet presents practical challenges: * Unbounded checkpoint chains consume storage and increase verification time. Condrey Expires 10 August 2026 [Page 88] Internet-Draft Proof of Process February 2026 * Authors may need to share partial Evidence before work completion (e.g., chapter submissions, progress reports). * System failures or device changes could result in loss of accumulated Evidence. * Privacy requirements may dictate periodic Evidence export and local data deletion. Continuation tokens address these challenges by enabling cryptographically-linked Evidence packet chains while preserving independent verifiability of each packet. 8.2. Continuation Token Structure The continuation token is an optional component of the Evidence packet, identified by integer key 21. It establishes the packet's position within a multi-packet Evidence series. ; Continuation token for multi-packet Evidence series ; Key 21 in evidence-packet continuation-section = { 1 => uuid, ; series-id 2 => uint, ; packet-sequence ? 3 => hash-value, ; prev-packet-chain-hash ? 4 => uuid, ; prev-packet-id 5 => continuation-summary, ; cumulative-summary ? 6 => cose-signature, ; series-binding-signature } ; Cumulative statistics across the series continuation-summary = { 1 => uint, ; total-checkpoints-so-far 2 => uint, ; total-chars-so-far 3 => duration, ; total-vdf-time-so-far 4 => float32, ; total-entropy-bits-so-far 5 => uint, ; packets-in-series ? 6 => pop-timestamp, ; series-started-at ? 7 => duration, ; total-elapsed-time } Key semantics: series-id: A UUID that remains constant across all packets in the series. Generated when the first packet in the series is created. packet-sequence: Zero-indexed sequence number. The first packet in a series has packet-sequence = 0. Condrey Expires 10 August 2026 [Page 89] Internet-Draft Proof of Process February 2026 prev-packet-chain-hash: The checkpoint-hash of the final checkpoint in the previous packet. MUST be present for packet-sequence > 0. MUST NOT be present for packet-sequence = 0. prev-packet-id: The packet-id of the previous packet in the series. SHOULD be present for packet-sequence > 0 to enable packet retrieval. cumulative-summary: Running totals across all packets in the series, enabling Verifiers to assess the full authorship effort without accessing all prior packets. 8.3. Chain Integrity Across Packets When a new packet continues from a previous packet, the VDF chain MUST maintain cryptographic continuity: Packet N (final checkpoint): checkpoint-hash[last] = H(checkpoint-data) VDF_output{last} = computed VDF result Packet N+1 (first checkpoint): prev-packet-chain-hash = checkpoint-hash[last] from Packet N VDF_input{0} = H( VDF_output{last} from Packet N || content-hash{0} || jitter-commitment{0} || series-id || packet-sequence ) This construction ensures: 1. The new packet cannot be created without knowledge of the previous packet's final VDF output. 2. Backdating the new packet requires recomputing all VDF proofs in both the current and all subsequent packets. 3. The series-id and packet-sequence are bound into the VDF chain, preventing packets from being reordered or reassigned to different series. 8.4. Verification of Continuation Chains Condrey Expires 10 August 2026 [Page 90] Internet-Draft Proof of Process February 2026 8.4.1. Single Packet Verification Each packet in a continuation series MUST be independently verifiable. A Verifier with access only to packet N can: * Verify all checkpoint chain integrity within the packet. * Verify all VDF proofs within the packet. * Verify jitter bindings within the packet. * Report the cumulative-summary as claimed (not proven without prior packets). The Attestation Result SHOULD note that the packet is part of a series and whether prior packets were verified. 8.4.2. Full Series Verification When all packets in a series are available, a Verifier MUST: 1. Verify each packet independently. 2. Verify that series-id is consistent across all packets. 3. Verify that packet-sequence values are consecutive starting from 0. 4. For each packet N > 0, verify that prev-packet-chain-hash matches the final checkpoint-hash of packet N-1. 5. For each packet N > 0, verify that the first checkpoint's VDF_input incorporates the previous packet's final VDF_output. 6. Verify that cumulative-summary values are consistent with the sum of individual packet statistics. 8.5. Series Binding Signature The optional series-binding-signature provides cryptographic proof that all packets in a series were produced by the same author: Condrey Expires 10 August 2026 [Page 91] Internet-Draft Proof of Process February 2026 series-binding-signature = COSE_Sign1( payload = CBOR_encode({ 1: series-id, 2: packet-sequence, 3: packet-id, 4: prev-packet-chain-hash, / if present / 5: cumulative-summary, }), key = author-signing-key ) When present, Verifiers can confirm that the signing key is consistent across all packets in the series, providing additional assurance of authorship continuity. 8.6. Practical Considerations 8.6.1. When to Export a Continuation Packet Implementations SHOULD support configurable triggers for continuation packet export: * *Checkpoint count threshold:* Export after N checkpoints (e.g., 1000). * *Time interval:* Export weekly or monthly. * *Document size threshold:* Export when document exceeds N characters. * *Manual trigger:* User-initiated export. * *Milestone events:* Export at chapter completion or version milestones. 8.6.2. Handling Gaps in Series If a packet in a series is lost or unavailable: * Subsequent packets remain independently verifiable. * The cumulative-summary provides claimed totals but cannot be proven without all packets. * Verifiers MUST note the gap in Attestation Results. * Chain continuity verification fails at the gap but resumes for subsequent contiguous packets. Condrey Expires 10 August 2026 [Page 92] Internet-Draft Proof of Process February 2026 8.7. Continuation Token Example Third monthly export of a dissertation in progress: continuation-section = { 1: h'dissertation-series-uuid...', / series-id / 2: 2, / packet-sequence (3rd) / 3: { / prev-packet-chain-hash / 1: 1, 2: h'feb-packet-final-hash...' }, 4: h'feb-packet-uuid...', / prev-packet-id / 5: { / cumulative-summary / 1: 847, / total-checkpoints-so-far / 2: 45230, / total-chars-so-far / 3: 12600.0, / total-vdf-time: ~3.5 hours / 4: 156.7, / total-entropy-bits / 5: 3, / packets-in-series / 6: 1(1704067200), / series-started-at / 7: 7776000.0 / total-elapsed: 90 days / }, 6: h'D28441A0...' / series-binding-signature / } 9. Quantified Trust Policies This section defines a framework for expressing and computing trust scores in Attestation Results. Trust policies enable Relying Parties to customize how Evidence is evaluated and to understand the basis for confidence scores. 9.1. Motivation The base attestation-result structure provides a confidence-score (0.0-1.0) and a verdict enumeration, but does not explain how these values were computed. Different Relying Parties have different trust requirements: * An academic journal may weight presence challenges heavily. * A legal proceeding may require hardware attestation. * A publishing platform may prioritize VDF duration. * An enterprise may have compliance-specific criteria. Without explicit trust policies, Relying Parties cannot: Condrey Expires 10 August 2026 [Page 93] Internet-Draft Proof of Process February 2026 * Understand why a particular confidence score was assigned. * Compare scores from different Verifiers. * Customize evaluation criteria for their domain. * Audit the verification process. The trust policy framework addresses these limitations by making confidence computation transparent and configurable. 9.2. Trust Policy Structure The appraisal-policy extension is added to verifier-metadata, identified by integer key 5. ; Extended verifier-metadata with trust policy verifier-metadata = { ? 1 => tstr, ; verifier-version ? 2 => tstr, ; verifier-uri ? 3 => [+ bstr], ; verifier-cert-chain ? 4 => tstr, ; policy-id ? 5 => appraisal-policy, ; policy details } ; Complete appraisal policy specification appraisal-policy = { 1 => tstr, ; policy-uri 2 => tstr, ; policy-version 3 => trust-computation, ; computation-model 4 => [+ trust-factor], ; factors ? 5 => [+ trust-threshold], ; thresholds ? 6 => policy-metadata, ; metadata } ; How the final score is computed trust-computation = &( weighted-average: 1, ; Sum of (factor * weight) minimum-of-factors: 2, ; Min across all factors geometric-mean: 3, ; Nth root of product custom-formula: 4, ; Described in policy-uri ) ; Individual factor in trust computation trust-factor = { 1 => tstr, ; factor-name 2 => factor-type, ; type 3 => float32, ; weight (0.0-1.0) Condrey Expires 10 August 2026 [Page 94] Internet-Draft Proof of Process February 2026 4 => float32, ; observed-value 5 => float32, ; normalized-score (0.0-1.0) 6 => float32, ; contribution ? 7 => factor-evidence, ; supporting-evidence } factor-type = &( ; Chain-verifiable factors vdf-duration: 1, checkpoint-count: 2, jitter-entropy: 3, chain-integrity: 4, revision-depth: 5, ; Presence factors presence-rate: 10, presence-response-time: 11, ; Hardware factors hardware-attestation: 20, calibration-attestation: 21, ; Behavioral factors edit-entropy: 30, monotonic-ratio: 31, typing-rate-consistency: 32, ; External factors anchor-confirmation: 40, anchor-count: 41, ; Collaboration factors collaborator-attestations: 50, contribution-consistency: 51, ) ; Evidence supporting a factor score factor-evidence = { ? 1 => float32, ; raw-value ? 2 => float32, ; threshold-value ? 3 => tstr, ; computation-notes ? 4 => [uint, uint], ; checkpoint-range } ; Threshold requirements for pass/fail determination trust-threshold = { 1 => tstr, ; threshold-name 2 => threshold-type, ; type Condrey Expires 10 August 2026 [Page 95] Internet-Draft Proof of Process February 2026 3 => float32, ; required-value 4 => bool, ; met ? 5 => tstr, ; failure-reason } threshold-type = &( minimum-score: 1, ; Score must be >= value minimum-factor: 2, ; factor >= value required-factor: 3, ; factor present maximum-caveats: 4, ; caveats <= value ) policy-metadata = { ? 1 => tstr, ; policy-name ? 2 => tstr, ; policy-description ? 3 => tstr, ; policy-authority ? 4 => pop-timestamp, ; policy-effective-date ? 5 => [+ tstr], ; applicable-domains } 9.3. Trust Computation Models 9.3.1. Weighted Average Model The most common computation model, where each factor contributes proportionally to its weight: confidence-score = sum(factor[i].weight * factor[i].normalized-score) / sum(factor[i].weight) Constraints: - sum(weights) SHOULD equal 1.0 for clarity - All normalized-scores are in [0.0, 1.0] - Resulting confidence-score is in [0.0, 1.0] Example: vdf-duration: weight=0.30, score=0.95, contribution=0.285 jitter-entropy: weight=0.25, score=0.80, contribution=0.200 presence-rate: weight=0.20, score=1.00, contribution=0.200 chain-integrity: weight=0.15, score=1.00, contribution=0.150 hardware-attest: weight=0.10, score=0.00, contribution=0.000 confidence-score = 0.285 + 0.200 + 0.200 + 0.150 + 0.000 = 0.835 9.3.2. Minimum-of-Factors Model A conservative model where the overall score is limited by the weakest factor: Condrey Expires 10 August 2026 [Page 96] Internet-Draft Proof of Process February 2026 confidence-score = min(factor[i].normalized-score for all i) Use case: High-security contexts where all factors must be strong. Example: vdf-duration: score=0.95 jitter-entropy: score=0.80 presence-rate: score=1.00 chain-integrity: score=1.00 hardware-attest: score=0.00 <-- limiting factor confidence-score = 0.00 This model is appropriate when any weakness should disqualify the Evidence, such as forensic or legal contexts. 9.3.3. Geometric Mean Model A balanced model that penalizes outliers more than weighted average but less than minimum: confidence-score = (product(factor[i].normalized-score))^(1/n) Example with 5 factors: scores = [0.95, 0.80, 1.00, 1.00, 0.60] product = 0.95 * 0.80 * 1.00 * 1.00 * 0.60 = 0.456 confidence-score = 0.456^(1/5) = 0.838 9.4. Factor Normalization Raw factor values must be normalized to the [0.0, 1.0] range for consistent computation. Normalization functions depend on the factor type: 9.4.1. Threshold Normalization For factors with a minimum threshold: if raw_value >= threshold: normalized = 1.0 else: normalized = raw_value / threshold Example: vdf-duration with 3600s threshold raw_value = 2700s normalized = 2700 / 3600 = 0.75 9.4.2. Range Normalization Condrey Expires 10 August 2026 [Page 97] Internet-Draft Proof of Process February 2026 For factors with min/max range: normalized = (raw_value - min) / (max - min) normalized = clamp(normalized, 0.0, 1.0) Example: typing-rate with acceptable range 20-200 WPM raw_value = 75 WPM normalized = (75 - 20) / (200 - 20) = 0.306 9.4.3. Binary Normalization For pass/fail factors: normalized = 1.0 if present/valid else 0.0 Example: hardware-attestation TPM attestation present and valid: normalized = 1.0 No hardware attestation: normalized = 0.0 9.5. Predefined Policy Profiles This specification defines several policy profiles for common use cases. Implementations MAY support these profiles by URI: +=====================================+============+===============+ |Profile URI |Description |Key | | | |Characteristics| +=====================================+============+===============+ |urn:ietf:params:pop:policy:basic |Basic |Chain integrity| | |verification|only | +-------------------------------------+------------+---------------+ |urn:ietf:params:pop:policy:academic |Academic |Weighted | | |submission |average, | | | |presence | | | |required | +-------------------------------------+------------+---------------+ |urn:ietf:params:pop:policy:legal |Legal |Minimum model, | | |proceedings |hardware | | | |required | +-------------------------------------+------------+---------------+ |urn:ietf:params:pop:policy:publishing|Publishing |Weighted | | |workflow |average, VDF | | | |emphasized | +-------------------------------------+------------+---------------+ Table 14: Predefined Policy Profiles Condrey Expires 10 August 2026 [Page 98] Internet-Draft Proof of Process February 2026 9.6. Trust Policy Example Academic policy applied to a Standard tier Evidence packet: verifier-metadata = { 1: "witnessd-verifier-2.0", 2: "https://verify.example.com", 4: "academic-v1", 5: { / appraisal-policy / 1: "urn:ietf:params:pop:policy:academic", 2: "1.0.0", 3: 1, / computation: weighted-average / 4: [ / factors / { 1: "vdf-duration", 2: 1, 3: 0.25, / weight / 4: 5400.0, / observed: 90 minutes / 5: 1.0, / normalized (threshold: 3600) / 6: 0.25, / contribution / 7: {1: 5400.0, 2: 3600.0} }, { 1: "jitter-entropy", 2: 3, 3: 0.20, 4: 45.7, / observed: 45.7 bits / 5: 1.0, / normalized (threshold: 32) / 6: 0.20 }, { 1: "presence-rate", 2: 10, 3: 0.25, 4: 0.917, / observed: 11/12 challenges / 5: 0.917, / direct ratio / 6: 0.229 }, { 1: "chain-integrity", 2: 4, 3: 0.20, 4: 1.0, / binary: valid / 5: 1.0, 6: 0.20 }, { 1: "edit-entropy", Condrey Expires 10 August 2026 [Page 99] Internet-Draft Proof of Process February 2026 2: 30, 3: 0.10, 4: 3.45, / observed / 5: 0.863, / normalized (range 0-4) / 6: 0.086 } ], 5: [ / thresholds / { 1: "minimum-overall", 2: 1, 3: 0.70, 4: true }, { 1: "presence-required", 2: 3, 3: 0.0, 4: true } ], 6: { / metadata / 1: "Academic Submission Policy", 3: "WritersLogic Academic Integrity", 5: ["academic", "education", "research"] } } } / confidence: 0.25 + 0.20 + 0.229 + 0.20 + 0.086 = 0.965 / 10. Compact Evidence References This section defines a compact representation of Evidence that can be embedded in metadata fields, QR codes, or other space-constrained contexts. Compact Evidence References provide a cryptographic link to full Evidence packets without requiring the full packet to be transmitted. 10.1. Motivation Full Evidence packets can be large (kilobytes to megabytes), making them unsuitable for embedding in: * Document metadata (PDF XMP, EXIF, Office custom properties) * Version control commit messages Condrey Expires 10 August 2026 [Page 100] Internet-Draft Proof of Process February 2026 * QR codes or NFC tags * Social media posts or profile fields * DNS TXT records or other protocol headers A Compact Evidence Reference provides "proof at a glance" that links to the full Evidence packet for complete verification. The reference is cryptographically bound to the Evidence, preventing tampering without detection. 10.2. Compact Reference Structure The Compact Evidence Reference uses a dedicated CBOR tag to distinguish it from full Evidence packets. ; Compact Evidence Reference ; Tag 1347571281 = 0x50505021 = "PPP!" tagged-compact-ref = #6.1347571281(compact-evidence-ref) compact-evidence-ref = { 1 => uuid, ; packet-id 2 => hash-value, ; chain-hash 3 => hash-value, ; document-hash 4 => compact-summary, ; summary 5 => tstr, ; evidence-uri 6 => cose-signature, ; compact-signature ? 7 => compact-metadata, ; metadata } compact-summary = { 1 => uint, ; checkpoint-count 2 => uint, ; total-chars 3 => duration, ; total-vdf-time 4 => uint, ; evidence-tier (1-4) ? 5 => forensic-assessment, ; verdict (if available) ? 6 => float32, ; confidence-score } compact-metadata = { ? 1 => tstr, ; author-name ? 2 => pop-timestamp, ; created ? 3 => tstr, ; verifier-name ? 4 => pop-timestamp, ; verified-at } Condrey Expires 10 August 2026 [Page 101] Internet-Draft Proof of Process February 2026 10.3. Compact Reference Signature The compact-signature binds all reference fields to prevent tampering: compact-signature = COSE_Sign1( payload = CBOR_encode({ 1: packet-id, 2: chain-hash, 3: document-hash, 4: compact-summary, 5: evidence-uri, }), key = signing-key ) Signing key may be: - Author's signing key (self-attestation) - Verifier's signing key (third-party attestation) - Evidence service's key (hosting attestation) The signature type SHOULD be indicated by the key identifier or by the evidence-uri domain. 10.4. Verification of Compact References 10.4.1. Reference-Only Verification Without fetching the full Evidence packet, a verifier can: 1. Verify the compact-signature is valid. 2. Identify the signer (author, verifier, or service). 3. Check that evidence-uri is from a trusted source. 4. Display the compact-summary to the user. This provides basic assurance that Evidence exists and was attested by a known party, without full verification. 10.4.2. Full Verification via URI For complete verification: 1. Fetch the Evidence packet from evidence-uri. 2. Verify that packet-id matches. Condrey Expires 10 August 2026 [Page 102] Internet-Draft Proof of Process February 2026 3. Verify that chain-hash matches the final checkpoint-hash. 4. Verify that document-hash matches the document-ref content-hash. 5. Perform full Evidence verification per this specification. 6. Verify that compact-summary values match the actual Evidence. Discrepancies between the compact reference and the fetched Evidence MUST cause verification to fail. 10.5. Encoding Formats Compact Evidence References may be encoded in several formats depending on the embedding context: 10.5.1. CBOR Encoding The native format is CBOR with the 0x50505021 tag. This is the most compact binary representation, suitable for: * Binary metadata fields * Protocol messages * Database storage Typical size: 150-250 bytes. 10.5.2. Base64 Encoding For text-only contexts, the CBOR bytes are base64url-encoded: pop-ref:2nQAAZD1UPAgowGQA...base64url... The "pop-ref:" prefix enables detection and parsing. Typical size: 200-350 characters. 10.5.3. URI Encoding A URI scheme for direct linking: pop://verify.example.com/ref/2nQAAZD1UPAgowGQA... Scheme: pop Host: verification service Path: /ref/{base64url-encoded-compact-ref} Condrey Expires 10 August 2026 [Page 103] Internet-Draft Proof of Process February 2026 Clicking/scanning the URI opens the verification service with the compact reference pre-loaded. 10.5.4. QR Code Encoding For physical media, the URI or base64 encoding can be represented as a QR code: * Version 6 QR (41x41): Sufficient for ~150 byte references * Version 10 QR (57x57): Sufficient for ~300 byte references * Error correction level M recommended for print durability 10.6. Embedding Guidelines 10.6.1. PDF Documents XMP Metadata location: /x:xmpmeta/rdf:RDF/rdf:Description[@xmlns:pop] Custom namespace: xmlns:pop="http://example.com/ns/pop/1.0/" Properties: pop:evidenceRef = base64url-encoded compact reference pop:evidenceURI = full Evidence packet URI pop:verificationURI = verification service URI 10.6.2. Git Commits Commit message footer: Pop-Evidence-Ref: pop-ref:2nQAAZD1UPAgowGQA... Pop-Evidence-URI: https://evidence.example.com/packets/abc123.pop Git notes (alternative): git notes --ref=pop-evidence add -m "pop-ref:2nQAAZD1..." 10.6.3. Image Files EXIF UserComment tag (0x9286): pop-ref:2nQAAZD1UPAgowGQA... XMP (for formats supporting it): Same structure as PDF XMP Condrey Expires 10 August 2026 [Page 104] Internet-Draft Proof of Process February 2026 10.7. Compact Reference Example / Tagged Compact Evidence Reference (0x50505021 = "PPP!") / 1347571281({ 1: h'550e8400e29b41d4a716446655440000', / packet-id / 2: { / chain-hash / 1: 1, 2: h'a7ffc6f8bf1ed76651c14756a061d662 f580ff4de43b49fa82d80a4b80f8434a' }, 3: { / document-hash / 1: 1, 2: h'e3b0c44298fc1c149afbf4c8996fb924 27ae41e4649b934ca495991b7852b855' }, 4: { / compact-summary / 1: 47, / checkpoints / 2: 12500, / chars / 3: 5400.0, / VDF time: 90 min / 4: 2, / tier: Standard / 5: 2, / verdict: likely-human / 6: 0.87 / confidence / }, 5: "https://evidence.example.com/p/"\ "550e8400e29b41d4a716446655440000.pop", 6: h'D28441A0A201260442...', / compact-signature / 7: { / metadata / 1: "Jane Author", 2: 1(1706745600), / created / 3: "WritersLogic Verification Service", 4: 1(1706832000) / verified / } }) Encoded size: approximately 220 bytes (CBOR), 295 characters (base64url). 11. Security Considerations This section consolidates security analysis for the witnessd Proof of Process specification. It references and extends the per-section security considerations defined in Section 3.8, Section 4.6, Section 5.9, Section 6.8, and Section 2.10. The specification adopts a quantified security approach: rather than claiming evidence is "secure" or "insecure" in absolute terms, security is expressed as cost asymmetries and tamper-evidence properties. This framing reflects the fundamental reality that Condrey Expires 10 August 2026 [Page 105] Internet-Draft Proof of Process February 2026 sufficiently resourced adversaries can eventually forge any evidence; the goal is to make forgery economically irrational for most scenarios. 11.1. Threat Model The witnessd threat model defines three categories: adversary goals, assumed adversary capabilities, and explicitly out-of-scope adversaries. 11.1.1. Adversary Goals The specification defends against adversaries pursuing the following objectives: Backdating Evidence: Creating evidence that claims to document a process occurring earlier than it actually did. This attack is relevant when priority or timeline claims matter (e.g., intellectual property disputes, academic submissions with deadlines). Fabricating Process: Creating evidence for a document that was not actually authored through the claimed process. This includes generating evidence for documents created entirely by automated means, or evidence claiming gradual authorship for content that was produced in a single operation (paste, import, generation). Transplanting Evidence: Taking legitimate evidence from one authoring session and associating it with a different document. This attack attempts to transfer the credibility of genuine evidence to unrelated content. Selective Disclosure: Omitting checkpoints or evidence sections that would reveal unfavorable information (e.g., large paste operations, gaps in activity). This attack attempts to present a misleadingly favorable subset of the actual process. 11.1.2. Assumed Adversary Capabilities The specification assumes adversaries have the following capabilities: Software Control: The adversary has full control over software running on their device, including the ability to modify or replace the Attesting Environment. They can intercept, modify, or fabricate any software-generated data. Commodity Hardware Access: The adversary can acquire commodity Condrey Expires 10 August 2026 [Page 106] Internet-Draft Proof of Process February 2026 computing hardware at market prices. They may have access to cloud computing resources and can rent substantial computational capacity. Bounded Compute Resources: The adversary's computational resources are bounded by economic constraints. They cannot instantaneously compute arbitrarily large numbers of VDF iterations. The time required for sequential computation cannot be circumvented with additional resources. Algorithm Knowledge: The adversary has complete knowledge of all algorithms and protocols used by the specification. Security does not depend on obscurity; the specification is public. Statistical Sophistication: The adversary can perform statistical analysis and may attempt to generate synthetic behavioral data that passes statistical tests. 11.1.3. Out-of-Scope Adversaries The specification explicitly does NOT defend against: Nation-State Adversaries with HSM Compromise: Adversaries capable of extracting keys from hardware security modules (TPM, Secure Enclave) through sophisticated physical attacks, side-channel analysis, or manufacturer compromise. Hardware attestation assumes HSM integrity. Cryptographic Breakthrough: Adversaries with access to novel cryptanalytic techniques that break SHA-256 collision resistance, ECDSA signature security, or other standard cryptographic primitives. The specification relies on established cryptographic assumptions. Quantum Adversaries: Adversaries with access to fault-tolerant quantum computers capable of executing Shor's algorithm (breaking RSA/ECDSA) or providing significant Grover speedups. Post-quantum considerations are noted in Section 4.5.2 but full quantum resistance is not claimed. Time Travel: Adversaries capable of creating evidence at one point in time and presenting it as if created earlier, where external anchors are not available or have been compromised. External timestamp authorities are trusted for absolute time claims. Coerced Authors: Adversaries who coerce legitimate authors into producing evidence under duress. The specification documents process, not intent or consent. Condrey Expires 10 August 2026 [Page 107] Internet-Draft Proof of Process February 2026 The exclusion of these adversaries is not a weakness but a recognition of practical threat modeling. Evidence systems appropriate for defending against nation-state actors would impose costs and constraints unsuitable for general authoring scenarios. 11.2. Cryptographic Security The specification relies on established cryptographic primitives with well-understood security properties. This section documents the security assumptions and requirements for each cryptographic component. 11.2.1. Hash Function Security Hash functions are used throughout the specification for content binding, chain construction, entropy commitment, and VDF computation. Required Properties: * Collision Resistance: It must be computationally infeasible to find two distinct inputs that produce the same hash output. This property ensures that different document states produce different content-hash values. * Preimage Resistance: Given a hash output, it must be computationally infeasible to find any input that produces that output. This property prevents adversaries from constructing documents that match a predetermined hash. * Second Preimage Resistance: Given an input and its hash, it must be computationally infeasible to find a different input with the same hash. This property prevents document substitution attacks. Algorithm Requirements: SHA-256 is RECOMMENDED and MUST be supported by all implementations. SHA-3-256 SHOULD be supported for algorithm agility. Hash functions with known weaknesses (MD5, SHA-1) MUST NOT be used. Security Margin: SHA-256 provides 128-bit security against collision attacks and 256-bit security against preimage attacks under classical assumptions. Grover's algorithm reduces these to 85-bit and 128-bit respectively under quantum assumptions. This margin is considered adequate for the specification's threat model. Condrey Expires 10 August 2026 [Page 108] Internet-Draft Proof of Process February 2026 11.2.2. Signature Security Digital signatures are used for checkpoint chain authentication, hardware attestation, calibration binding, and Attestation Result integrity. COSE Algorithm Requirements: Implementations MUST support COSE algorithm identifiers: * ES256 (ECDSA with P-256 and SHA-256): MUST support * ES384 (ECDSA with P-384 and SHA-384): SHOULD support * EdDSA (Ed25519): SHOULD support RSA-based algorithms (PS256, RS256) MAY be supported for compatibility with legacy systems but are not recommended for new implementations due to larger signature sizes and post-quantum vulnerability. Key Size Requirements: Minimum key sizes for 128-bit security: * ECDSA: P-256 curve or larger * EdDSA: Ed25519 or Ed448 * RSA: 3072 bits or larger Signature Binding: Signatures MUST bind to the complete payload being signed. Partial payload signatures (signing a subset of fields) create opportunities for field substitution attacks. The chain-mac field provides additional binding beyond the checkpoint signature. 11.2.3. VDF Security Verifiable Delay Functions provide the temporal security foundation of the specification. VDF security rests on the sequential computation requirement. Sequential Computation: The VDF output cannot be computed significantly faster than the specified number of sequential operations. For iterated hash VDFs, this reduces to the assumption that no algorithm computes H^n(x) faster than n sequential hash evaluations. No such algorithm is known for cryptographic hash functions. Parallelization Resistance: Additional computational resources (more Condrey Expires 10 August 2026 [Page 109] Internet-Draft Proof of Process February 2026 processors, GPUs, ASICs) cannot reduce the wall-clock time required for VDF computation. The iterated hash construction is inherently sequential: each iteration depends on the previous output. See Section 4.6.2 for detailed analysis. Verification Soundness: For iterated hash VDFs, verification is by recomputation. The Verifier executes the same computation and compares results. This provides perfect soundness: a claimed output that differs from the actual computation will always be detected. For succinct VDFs ([Pietrzak2019], [Wesolowski2019]), verification relies on the cryptographic hardness of the underlying problem (RSA group or class group). Soundness is computational rather than perfect. 11.2.4. Key Management Proper key management is essential for maintaining evidence integrity. Hardware-Bound Keys: When available, signing keys SHOULD be bound to hardware security modules (TPM, Secure Enclave). Hardware binding provides: * Key non-exportability: Private keys cannot be extracted from the device * Device binding: Evidence can be tied to a specific physical device * Tamper resistance: Key compromise requires physical attack Session Keys: The checkpoint-chain-key used for chain-mac computation SHOULD be derived uniquely for each session. Key derivation SHOULD use HKDF (RFC 5869) with domain separation: chain-key = HKDF-SHA256( salt = session-entropy, ikm = device-master-key, info = "witnessd-chain-v1" || session-id ) Key Rotation: Device keys SHOULD be rotated periodically Condrey Expires 10 August 2026 [Page 110] Internet-Draft Proof of Process February 2026 (RECOMMENDED: annually) or upon suspected compromise. Evidence packets created with revoked keys SHOULD be flagged during verification. 11.3. Attesting Environment Trust The Attesting Environment (AE) is the witnessd-core software running on the author's device. Understanding what the AE is trusted for, and what it is NOT trusted for, is essential for correct interpretation of evidence. 11.3.1. What the AE Is Trusted For The AE is trusted to perform accurate observation and honest reporting of the specific data it captures: Accurate Timing Measurement: The AE is trusted to accurately measure inter-keystroke intervals and other timing data. This does not require trusting the content of keystrokes, only the timing between events. Correct Hash Computation: The AE is trusted to correctly compute cryptographic hashes of document content. Verification can detect incorrect hashes, but cannot detect if the AE computed a hash of different content than claimed. VDF Execution: The AE is trusted to actually execute VDF iterations rather than fabricating outputs. This trust is partially verifiable: VDF outputs can be recomputed, but the claimed timing cannot be independently verified without calibration attestation. Monitoring Events (for monitoring-dependent claims): For claims in the monitoring-dependent category (types 16-63), the AE is trusted to have actually observed and reported the events (or non-events) it claims. This trust is documented in the ae-trust-basis field. 11.3.2. What the AE Is NOT Trusted For The specification explicitly does NOT rely on AE trust for the following: Content Judgment: The AE makes no claims about document quality, originality, accuracy, or appropriateness. Evidence documents process, not content merit. Intent Inference: The AE makes no claims about why the author Condrey Expires 10 August 2026 [Page 111] Internet-Draft Proof of Process February 2026 performed specific actions, what the author was thinking, or whether the author intended to deceive. Evidence documents observable behavior, not mental states. Authorship Attribution: The AE makes no claims about who was operating the device. The evidence shows that input events occurred on a device; it does not prove that a specific individual produced those events. Cognitive Process: Behavioral patterns consistent with human typing do not prove human cognition. An adversary could theoretically program input patterns that mimic human timing while the content originates elsewhere. The Jitter Seal makes this costly, not impossible. 11.3.3. Hardware Attestation Role Hardware attestation increases AE trust by binding evidence to verified hardware: [TPM2.0] (Linux, Windows): Provides platform integrity measurement (PCRs), key sealing to platform state, and hardware-bound signing keys. TPM attestation proves that the AE was running on a specific device in a specific configuration. Secure Enclave (macOS, iOS): Provides hardware-bound key generation and signing operations. Keys generated in the Secure Enclave cannot be exported, binding signatures to the specific device. Attestation Limitations: Hardware attestation proves the signing key is hardware-bound; it does not prove the AE software is unmodified. Full AE integrity would require secure boot attestation and runtime integrity measurement, which are platform- specific and not universally available. 11.3.4. Compromised AE Scenarios Understanding the impact of AE compromise is essential for risk assessment: Modified AE Software: An adversary running modified AE software can fabricate any monitoring-dependent claims (types 16-63). Chain- verifiable claims (types 1-15) remain bound by VDF computational requirements even with modified software. Fake Calibration: Modified software could report artificially slow calibration rates, making subsequent VDF computations appear to take longer than they actually did. This attack is mitigated by: Condrey Expires 10 August 2026 [Page 112] Internet-Draft Proof of Process February 2026 * Hardware-signed calibration attestation (when available) * Plausibility checks based on device class * External anchor cross-validation Fabricated Jitter Data: Modified software could generate synthetic timing data that mimics human patterns. The cost of this attack is bounded by: * Real-time generation requirement (VDF entanglement) * Statistical consistency across checkpoints * Entropy threshold requirements See Section 3.8.2 for quantified bounds on simulation attacks. Mitigation Summary: AE compromise cannot reduce the VDF computational requirement or bypass the sequential execution constraint. Compromise enables fabrication of monitoring data but does not eliminate the time cost of forgery. The forgery-cost- section quantifies the minimum resources required even with full software control. 11.4. Verification Security The verification process must be secure against both malicious Evidence and malicious Verifiers. 11.4.1. Verifier Independence Evidence verification is designed to be independent of the Attester: No Shared State: Verification requires no communication with or data from the Attester beyond the Evidence packet itself. A Verifier with only the .pop file can perform complete verification. Adversarial Verification: A skeptical Verifier can appraise Evidence without trusting any claims made by the Attester. All cryptographic proofs are included and can be recomputed independently. Multiple Independent Verifiers: Multiple Verifiers appraising the same Evidence should reach consistent results for chain-verifiable claims. Monitoring- dependent claims may receive different confidence assessments based on Verifier policies. Condrey Expires 10 August 2026 [Page 113] Internet-Draft Proof of Process February 2026 11.4.2. Sampling Strategies for Large Evidence Packets Evidence packets may contain thousands of checkpoints. Full verification of all VDF proofs may be impractical. Verifiers MAY use sampling strategies: Boundary Verification: Always verify the first and last checkpoints fully. This confirms the chain endpoints. Random Sampling: Randomly select checkpoints for full VDF verification. If any sampled checkpoint fails, reject the entire Evidence. Probability of detecting a single invalid checkpoint with k samples from n checkpoints: 1 - (1 - 1/n)^k. Chain Linkage Verification: Verify prev-hash linkage for ALL checkpoints (computationally cheap). This ensures no checkpoints were removed or reordered. Anchor-Bounded Verification: If external anchors are present, prioritize verification of checkpoints adjacent to anchors. External timestamps bound the timeline at anchor points. Sampling Disclosure: Attestation Results SHOULD disclose the sampling strategy used and the number of checkpoints fully verified. Relying Parties can assess whether the sampling provides adequate confidence for their use case. 11.4.3. External Anchor Verification External anchors (RFC 3161 timestamps, blockchain proofs) provide absolute time binding but introduce additional trust requirements: Timestamp Authority Trust: Timestamps per [RFC3161] require trust in the Time Stamping Authority (TSA). Verifiers SHOULD use TSAs with published policies and audit records. Multiple TSAs MAY be used for redundancy. Blockchain Anchor Verification: Blockchain-based anchors require access to blockchain data (directly or via APIs). Verifiers SHOULD verify: * The transaction containing the anchor is confirmed * Sufficient confirmations for the security level required * The anchor commitment matches the expected checkpoint data Anchor Freshness: Anchors prove that Evidence existed at the anchor Condrey Expires 10 August 2026 [Page 114] Internet-Draft Proof of Process February 2026 time; they do not prove Evidence was created at that time. An adversary could create Evidence, wait, then obtain an anchor. This is mitigated by anchor coverage requirements (multiple anchors throughout the session). 11.5. Protocol Security This section addresses protocol-level attacks and mitigations, drawing on the per-section security analyses. 11.5.1. Replay Attack Prevention Replay attacks attempt to reuse valid evidence components in invalid contexts. Multiple mechanisms prevent replay: Nonce Binding: Session entropy (random 256-bit seed) is incorporated into the genesis checkpoint VDF input. This prevents precomputation of VDF outputs before a session begins. Chain Binding: Each checkpoint includes prev-hash, binding it to the specific chain history. Checkpoints cannot be transplanted between chains without invalidating the hash linkage. See Section 3.8.1 for jitter-specific replay prevention. Sequence Binding: Checkpoint sequence numbers MUST be strictly monotonic. Duplicate or out-of-order sequence numbers indicate manipulation. Content Binding: VDF inputs incorporate content-hash, binding temporal proofs to specific document states. Evidence for one document cannot be transferred to another without VDF recomputation. 11.5.2. Transplant Attack Prevention Transplant attacks attempt to associate legitimate evidence from one context with content from another context: Content-VDF Binding: The VDF input includes content-hash: VDF_input{N} = H( VDF_output{N-1} || content-hash{N} || jitter-commitment{N} || sequence{N} ) Condrey Expires 10 August 2026 [Page 115] Internet-Draft Proof of Process February 2026 Changing the document content requires recomputing all subsequent VDF proofs. Jitter-VDF Binding: The jitter-commitment is entangled with VDF input. Transplanting jitter data from another session is infeasible because it would require the original VDF output (which depends on different content) or recomputing the entire VDF chain with new jitter (which requires capturing new behavioral entropy in real time). Chain MAC: The chain-mac field HMAC-binds checkpoints to the session's chain-key: chain-mac = HMAC-SHA256( key = chain-key, message = checkpoint-hash || sequence || session-id ) Without the chain-key, an adversary cannot construct valid chain- mac values for transplanted checkpoints. 11.5.3. Backdating Attack Costs Backdating creates evidence claiming a process occurred earlier than it actually did. The cost of backdating is quantified by the VDF recomputation requirement: VDF Recomputation: To backdate evidence by inserting or modifying checkpoints at position P, the adversary must recompute all VDF proofs from position P forward. This requires: backdate_time >= sum(iterations[i]) / adversary_vdf_rate for i = P to N where N is the final checkpoint. Backdating by a significant amount (hours or days) requires proportional wall-clock time. External Anchor Constraints: If external anchors exist in the chain, backdating is constrained to the interval between anchors. An adversary cannot backdate before an anchor without also forging the external timestamp. Cost Quantification: The forgery-cost-section provides explicit cost bounds for backdating attacks, including compute costs, time costs, and economic estimates. Condrey Expires 10 August 2026 [Page 116] Internet-Draft Proof of Process February 2026 11.5.4. Omission Attack Prevention Omission attacks selectively remove checkpoints to hide unfavorable evidence: Sequence Verification: Checkpoint sequence numbers MUST be consecutive. Missing sequence numbers indicate omission. Verifiers MUST reject chains with non-consecutive sequences. Hash Chain Integrity: Removing a checkpoint breaks the hash chain (subsequent checkpoint's prev-hash will not match). Repairing the chain requires recomputing all subsequent checkpoint hashes and VDF proofs. Completeness Claims: The checkpoint-chain-complete absence claim (type 6) explicitly asserts that no checkpoints were omitted. This claim is chain-verifiable. 11.6. Operational Security Security of the overall system depends on proper operational practices beyond the protocol specification. 11.6.1. Key Lifecycle Management Key Generation: Device keys SHOULD be generated within hardware security modules when available. Software-generated keys MUST use cryptographically secure random number generators. Key Storage: Private keys SHOULD be stored in platform-appropriate secure storage: * macOS: Secure Enclave or Keychain * Linux: TPM or system keyring * Windows: TPM or DPAPI Keys MUST NOT be stored in plaintext in the filesystem. Key Rotation: Organizations SHOULD establish key rotation policies. RECOMMENDED rotation interval: annually or upon personnel changes. Evidence packets created with revoked keys SHOULD receive reduced confidence scores. Key Revocation: Mechanisms for key revocation are outside the scope Condrey Expires 10 August 2026 [Page 117] Internet-Draft Proof of Process February 2026 of this specification but SHOULD be considered for deployment. Certificate revocation lists (CRLs) or OCSP may be appropriate for managed environments. 11.6.2. Evidence Packet Storage and Transmission Integrity Protection: Evidence packets are self-protecting through cryptographic binding. Additional encryption is not required for integrity but MAY be applied for confidentiality. Confidentiality Considerations: Evidence packets contain document hashes and behavioral data. While content is not included, statistical information about the authoring process is present. Transmission over untrusted networks SHOULD use TLS 1.3 or equivalent. Archival Storage: Evidence packets intended for long-term storage SHOULD be: * Stored with redundancy (multiple copies, geographic distribution) * Protected against bit rot (checksums, error-correcting codes) * Associated with necessary verification materials (public keys, anchor confirmations) Retention Policies: Organizations SHOULD establish retention policies balancing evidentiary value against privacy considerations. Jitter data has privacy implications; retention beyond the verification period may not be necessary or desirable. 11.6.3. Verifier Policy Considerations Minimum Requirements: Verifiers SHOULD establish minimum requirements for acceptable Evidence: * Minimum evidence tier (Basic, Standard, Enhanced, Maximum) * Minimum VDF duration relative to claimed authoring time * Minimum entropy threshold * Required absence claims for specific use cases Confidence Thresholds: Verifiers SHOULD define confidence thresholds for acceptance: Condrey Expires 10 August 2026 [Page 118] Internet-Draft Proof of Process February 2026 * Low-stakes: confidence >= 0.3 may be acceptable * Standard: confidence >= 0.5 typical requirement * High-stakes: confidence >= 0.7 recommended * Litigation: confidence >= 0.8 with Maximum tier Caveat Handling: Verifiers SHOULD define how caveats affect acceptance decisions. Some caveats may be disqualifying for specific use cases (e.g., "no hardware attestation" may be unacceptable for high-stakes verification). 11.7. Limitations and Non-Goals This section explicitly documents what the specification does NOT protect against and what it does NOT claim to achieve. 11.7.1. Attacks Not Protected Against Collusion: If the author and a third party collude (e.g., the author provides their device credentials to another person who types while the author is credited), the Evidence will show a legitimate-looking process. The specification documents observable behavior, not identity. Pre-Prepared Content: An author could slowly type pre-prepared content, creating Evidence of a gradual process for content that already existed. The specification documents that typing occurred, not that thinking occurred during typing. External Input Devices: Input from devices not monitored by the AE (e.g., hardware keystroke injectors, remote desktop from unmonitored machines) may not be distinguishable from local input. Hardware-level input verification is outside scope. Social Engineering: Attacks that manipulate Relying Parties into accepting inappropriate Evidence (e.g., convincing a reviewer that weak Evidence is sufficient) are outside scope. 11.7.2. The Honest Author Assumption The specification fundamentally documents PROCESS, not INTENT: Evidence Shows What Happened: Evidence shows that input events occurred with specific timing patterns, that VDF computation required certain time, that document states changed in sequence. Evidence does not show why any of this happened. Condrey Expires 10 August 2026 [Page 119] Internet-Draft Proof of Process February 2026 Process != Cognition: Evidence that an author typed content gradually does not prove the author thought of that content. The author could have been transcribing, copying from memory, or following dictation. Behavioral Consistency: The correct interpretation of Evidence is "behavioral consistency": the observable process was consistent with the claimed process. This is weaker than "authorship proof" but is verifiable and falsifiable. 11.7.3. Content-Agnostic By Design The specification is deliberately content-agnostic: No Semantic Analysis: Evidence contains document hashes, not content. The specification makes no claims about what was written, only how it was written. No Quality Assessment: Evidence does not indicate whether content is good, original, accurate, or valuable. Strong Evidence can accompany poor content; excellent content can have weak Evidence. No AI Detection: The specification explicitly does NOT claim to detect whether content was "written by AI" or "written by a human" in terms of content origin. It documents the observable INPUT process, which is distinct from content generation. Privacy Benefit: Content-agnosticism is a privacy feature. Evidence can be verified without accessing the document content, enabling verification of confidential documents. 11.8. Comparison to Related Work This section compares the security model of witnessd Proof of Process to related attestation and timestamping systems. 11.8.1. Comparison to Traditional Timestamping Traditional timestamping ([RFC3161]) proves that a document existed at a point in time. Proof of Process provides additional properties: Condrey Expires 10 August 2026 [Page 120] Internet-Draft Proof of Process February 2026 +=======================+=====================+==================+ | Property | RFC 3161 | Proof of Process | +=======================+=====================+==================+ | Existence proof | Yes (point in time) | Yes (continuous) | +-----------------------+---------------------+------------------+ | Process documentation | No | Yes | +-----------------------+---------------------+------------------+ | Behavioral evidence | No | Yes (jitter) | +-----------------------+---------------------+------------------+ | Temporal ordering | No (independent | Yes (VDF chain) | | | timestamps) | | +-----------------------+---------------------+------------------+ | Third-party trust | Required (TSA) | Optional | | | | (anchors) | +-----------------------+---------------------+------------------+ | Local generation | No (requires TSA | Yes | | | interaction) | | +-----------------------+---------------------+------------------+ Table 15 Proof of Process is complementary to timestamping. External anchors (including RFC 3161 timestamps) provide absolute time binding that strengthens VDF-based relative ordering. 11.8.2. Comparison to Code Signing Code signing attests to the identity of the signer and integrity of the signed artifact. Proof of Process serves different goals: +=====================+=======================+=====================+ | Property | Code Signing | Proof of Process | +=====================+=======================+=====================+ | Identity binding | Strong (PKI) | Weak (device-bound) | +---------------------+-----------------------+---------------------+ | Artifact integrity | Yes | Yes (hash binding) | +---------------------+-----------------------+---------------------+ | Creation process | No | Yes | +---------------------+-----------------------+---------------------+ | Temporal properties | Timestamp only | Duration, ordering | +---------------------+-----------------------+---------------------+ | Use case | Software | Authoring | | | distribution | documentation | +---------------------+-----------------------+---------------------+ Table 16 Condrey Expires 10 August 2026 [Page 121] Internet-Draft Proof of Process February 2026 Code signing establishes "who signed this"; Proof of Process establishes "how this was created." The two could be combined for comprehensive provenance documentation. 11.8.3. Relationship to RATS Security Model Proof of Process implements an application-specific profile of the RATS architecture [RFC9334]. Key security model alignments: Evidence vs. Attestation Results: The separation between .pop (Evidence) and .war (Attestation Result) files follows the RATS distinction. Evidence is produced by the Attester; Attestation Results by the Verifier. Appraisal Policy: RATS defines Appraisal Policy for Evidence as the Verifier's rules for evaluating Evidence. The absence-claim thresholds and confidence-level requirements serve this role in Proof of Process. Background Check vs. Passport Model: Proof of Process supports both RATS models. The "passport model" applies when the author obtains a .war file and presents it to Relying Parties. The "background check model" applies when the Relying Party verifies the .pop file directly or through a trusted Verifier. Freshness: RATS freshness mechanisms (nonces, timestamps) align with the session-entropy and external-anchor mechanisms in Proof of Process. VDF proofs provide an additional freshness dimension: evidence of elapsed time. Endorsements and Reference Values: Hardware attestation in the hardware-section corresponds to RATS Endorsements. Calibration data serves as Reference Values for VDF timing verification. For RATS-specific security guidance, implementers should also consult the RATS security considerations in [RFC9334] Section 11. 11.9. Security Properties Summary This section summarizes the security properties provided by the specification: 11.9.1. Properties Provided Tamper-Evidence: Modifications to Evidence packets are detectable through cryptographic verification. The hash chain, VDF entanglement, and MAC bindings ensure that alteration invalidates the Evidence. Condrey Expires 10 August 2026 [Page 122] Internet-Draft Proof of Process February 2026 Cost-Asymmetric Forgery: Producing counterfeit Evidence requires resources (time, compute, entropy generation) disproportionate to legitimate Evidence creation. The forgery-cost-section quantifies these requirements. Independent Verifiability: Evidence can be verified by any party without access to the original device, without trust in the Attester's infrastructure, and without network connectivity (except for external anchors). Privacy by Construction: Document content is never stored in Evidence. Behavioral data is aggregated before inclusion. The specification enforces privacy through structural constraints, not policy. Temporal Ordering: VDF chain construction provides unforgeable relative ordering of checkpoints. External anchors provide absolute time binding. Behavioral Binding: Jitter Seal entanglement binds captured behavioral entropy to the checkpoint chain, making Evidence transplantation infeasible. 11.9.2. Properties NOT Provided Tamper-Proof: Evidence CAN be forged given sufficient resources. The specification makes forgery costly, not impossible. Identity Proof: Evidence does NOT prove who operated the device. It proves that input events occurred on a device, not that a specific person produced them. Intent Proof: Evidence does NOT prove why actions occurred. Observable behavior is documented; mental states are not. Content Origin Proof: Evidence does NOT prove where ideas came from. The input process is documented; the cognitive source is not. Absolute Certainty: All security properties are bounded by explicit assumptions. No claim is made to be absolute, irrefutable, or guaranteed. 12. Privacy Considerations This section consolidates privacy analysis for the witnessd Proof of Process specification. It references and extends the per-section privacy considerations defined in Section 3.7, Section 5.10, and Section 2.10.3. Condrey Expires 10 August 2026 [Page 123] Internet-Draft Proof of Process February 2026 Privacy is a core design goal of this specification, not an afterthought. The protocol implements privacy-by-construction: structural constraints that make privacy violations architecturally impossible, rather than relying on policy or trust. This approach follows the guidance of [RFC6973] (Privacy Considerations for Internet Protocols). 12.1. Privacy by Construction The witnessd evidence model enforces privacy through architectural constraints that cannot be circumvented without fundamentally modifying the protocol. 12.1.1. No Document Content Storage Evidence packets contain cryptographic hashes of document states, never the document content itself. This is a structural invariant: * Content Hash Binding: The document-ref structure (CDDL key 5 in evidence-packet) contains only a hash-value of the final document content, the byte-length, and character count. The content itself is never included in the Evidence packet. * Checkpoint Content Hashes: Each checkpoint (key 4: content-hash) contains a hash of the document state at that point. An adversary with the Evidence packet but not the document cannot recover content from these hashes. * Edit Deltas Without Content: The edit-delta structure (key 7 in checkpoint) records chars- added, chars-deleted, insertions, deletions, and replacements as counts only. No information about what characters were added or deleted is included. This design enables verification of process without revealing what was written, supporting confidential document workflows where the evidence must be verifiable but the content must remain private. 12.1.2. No Keystroke Capture The specification captures inter-event timing intervals without recording which keys were pressed: Condrey Expires 10 August 2026 [Page 124] Internet-Draft Proof of Process February 2026 * Timing-Only Measurement: Jitter-binding captures millisecond intervals between input events. The interval "127ms" carries no information about whether the interval was between 'a' and 'b' or between 'x' and 'y'. * No Character Mapping: Timing intervals are stored in observation order without any association to specific characters, words, or semantic content. * No Keyboard Event Codes: Scan codes, virtual key codes, and other keyboard identifiers are not recorded. The specification treats all input events uniformly as timing sources. This architecture ensures that even with complete access to an Evidence packet, no information about what was typed can be reconstructed. 12.1.3. No Screenshots or Screen Recording The specification explicitly excludes visual capture mechanisms: * No screenshot capture at checkpoints or any other time * No screen recording or video capture * No window title or application name logging * No clipboard content capture (only timing of clipboard events for monitoring-dependent absence claims, and only event counts, not content) Visual content capture would fundamentally violate the content- agnostic design and is architecturally excluded. 12.1.4. Local Evidence Generation Evidence is generated entirely on the Attester device with no network dependency: * No Telemetry: The Attesting Environment does not transmit telemetry, analytics, or any behavioral data to external services. Condrey Expires 10 August 2026 [Page 125] Internet-Draft Proof of Process February 2026 * No Cloud Processing: All cryptographic computations (hashing, VDF, signatures) occur locally. No document content or behavioral data is sent to cloud services for processing. * Optional External Anchors: The only network communication is optional: external anchors (RFC 3161, OpenTimestamps, blockchain) transmit only cryptographic hashes, never document content or behavioral data. Users can generate and verify Evidence in fully air-gapped environments. External anchors enhance evidence strength but are not required. 12.2. Data Minimization Following [RFC6973] Section 6.1, the specification minimizes data collection to what is strictly necessary for evidence generation and verification. 12.2.1. Data Collected The following data IS collected and included in Evidence packets: Timing Histograms: Inter-event timing intervals aggregated into histogram buckets (jitter-summary, key 3 in jitter-binding). Bucket boundaries are coarse (RECOMMENDED: 0, 50, 100, 200, 500, 1000, 2000, 5000ms) to prevent precise interval reconstruction. Edit Statistics: Character counts for additions, deletions, and edit operations (edit-delta structure). These are aggregate counts, not positional data. Checkpoint Hashes: Cryptographic hashes of document states at each checkpoint. One-way functions; content cannot be recovered. VDF Proofs: Verifiable Delay Function outputs proving minimum elapsed time. These are computational proofs, not behavioral data. Optional: Raw Timing Intervals: The raw-intervals field (key 5 in jitter-binding) MAY be included for enhanced verification. This is OPTIONAL and user-controlled. When omitted, only histogram aggregates are included. Condrey Expires 10 August 2026 [Page 126] Internet-Draft Proof of Process February 2026 12.2.2. Data NOT Collected The following data is explicitly NOT collected: * Document content (text, images, formatting) * Individual characters or words typed * Keyboard scan codes or key identifiers * Screenshots or visual captures * Screen recordings or video * Clipboard content (only event timing) * Window titles or application names * User names, email addresses, or identifiers (optional: author declaration is user-controlled) * IP addresses or network identifiers * Location data 12.2.3. Disclosure Levels The specification supports tiered disclosure through optional fields: +==========+==========================+================+ | Level | Data Included | Privacy Impact | +==========+==========================+================+ | Minimal | Hashes, VDF proofs, | Lowest | | | histogram summaries only | | +----------+--------------------------+----------------+ | Standard | + Presence challenges, | Low-Moderate | | | forensics section | | +----------+--------------------------+----------------+ | Enhanced | + Raw timing intervals, | Moderate | | | keystroke section | | +----------+--------------------------+----------------+ | Maximum | + Hardware attestation, | Higher | | | absence claims | | +----------+--------------------------+----------------+ Table 17 Condrey Expires 10 August 2026 [Page 127] Internet-Draft Proof of Process February 2026 Users SHOULD select the minimum disclosure level that meets their verification requirements. Higher tiers provide stronger evidence at the cost of revealing more behavioral data. 12.3. Biometric-Adjacent Data Keystroke timing data, while not traditionally classified as biometric, has biometric-adjacent properties that warrant special consideration. This section addresses regulatory considerations and mitigation measures. 12.3.1. Identification Risks Research has demonstrated that keystroke dynamics can serve as a behavioral biometric: * Individual Identification: Detailed timing patterns can theoretically distinguish individuals with high accuracy across sessions. * State Detection: Timing variations may correlate with cognitive state, fatigue, stress, or physical condition. * Re-identification Risk: If an adversary has access to multiple Evidence packets from the same author, timing patterns might enable linkage across sessions even without explicit identity. 12.3.2. Mitigation Measures The specification implements several measures to reduce biometric- adjacent risks: Histogram Aggregation: By default, only histogram-aggregated timing data is included in Evidence packets. The RECOMMENDED bucket width of 50ms minimum significantly reduces the precision available for behavioral fingerprinting. Bucket Granularity: The RECOMMENDED bucket boundaries (0, 50, 100, 200, 500, 1000, 2000, 5000ms) capture statistically relevant patterns while preventing reconstruction of precise keystroke sequences. Implementations MAY use coarser buckets for enhanced privacy. Condrey Expires 10 August 2026 [Page 128] Internet-Draft Proof of Process February 2026 No Character Association: Timing intervals have no mapping to specific characters. The pattern "fast-slow-fast" reveals rhythm without content. Session Isolation: Each Evidence packet is independent. Cross- session linkage requires access to multiple packets. The specification does not provide mechanisms for linking sessions. Optional Raw Disclosure: Raw timing intervals (key 5 in jitter- binding) are optional. Users concerned about biometric exposure can ensure this field is not populated. 12.3.3. Regulatory Considerations Implementations and deployments should consider applicable privacy regulations: GDPR (EU/EEA): Keystroke dynamics may constitute "special categories of personal data" under Article 9 if used for identification purposes. Implementations should document whether timing data is used for identification (prohibited without explicit consent) or solely for process evidence (may fall under different legal basis). CCPA (California): Biometric information is covered under CCPA Section 1798.140(b). Users have rights to know, delete, and opt- out. The local-only processing model simplifies compliance. BIPA (Illinois): Illinois Biometric Information Privacy Act has strict requirements for biometric data collection, including written policies and consent. Deployments in Illinois should consult legal counsel. The specification's local-only processing model and user control over data disclosure support compliance, but legal interpretation varies by jurisdiction. 12.3.4. User Disclosure Requirements Implementations MUST inform users about behavioral data collection: 1. Clear notification that timing data is captured during authoring 2. Explanation of what timing data reveals and does not reveal 3. Disclosure of where Evidence packets may be transmitted 4. User control over disclosure levels (histogram-only vs. raw) Condrey Expires 10 August 2026 [Page 129] Internet-Draft Proof of Process February 2026 5. Instructions for disabling timing capture if desired 6. Process for reviewing and deleting captured data These disclosures SHOULD be presented before Evidence generation begins, not buried in terms of service. 12.4. Salt Modes for Content Privacy The hash-salt-mode field (CDDL lines 164-168) enables privacy- preserving verification scenarios where document binding should not be globally verifiable. 12.4.1. Unsalted Mode (Value 0) content-hash = H(document-content) Properties: * Anyone with the document can verify the binding * No additional secret required for verification * Document existence can be confirmed by any party with content Use cases: * Public documents where verification should be open * Academic submissions where verifiers have document access * Published works where authorship claims should be checkable Privacy implications: Anyone who obtains both the document and the Evidence packet can confirm the binding. If document confidentiality matters, consider salted modes. 12.4.2. Author-Salted Mode (Value 1) content-hash = H(salt || document-content) salt-commitment = H(salt) Properties: * Author generates and retains the salt * Evidence packet contains salt-commitment, not salt Condrey Expires 10 August 2026 [Page 130] Internet-Draft Proof of Process February 2026 * Author selectively reveals salt to chosen verifiers * Without salt, document-hash relationship cannot be verified Use cases: * Confidential documents where author controls verification * Selective disclosure to specific reviewers or institutions * Manuscripts under review before publication Privacy implications: The author has exclusive control over who can verify the document binding. The salt should be stored securely; loss of salt means verification becomes impossible. 12.4.3. Third-Party Escrowed Mode (Value 2) content-hash = H(salt || document-content) salt-commitment = H(salt) ; salt held by escrow service Properties: * Salt is held by a trusted escrow service * Escrow releases salt under predefined conditions * Author cannot unilaterally control verification * Verification requires escrow cooperation Use cases: * Legal submissions where court order triggers verification * Dispute resolution with neutral third-party control * Time-delayed disclosure (escrow releases at future date) * Contractual conditions for verification access Privacy implications: Verification access is determined by escrow policy, not author discretion. Authors should understand escrow release conditions before selecting this mode. Condrey Expires 10 August 2026 [Page 131] Internet-Draft Proof of Process February 2026 12.4.4. Salt Security Considerations For salted modes: * Salts MUST be cryptographically random (minimum 256 bits) * Salts MUST NOT be derived from predictable values * Salt-commitment prevents brute-force guessing for short documents * Salt loss makes verification impossible; backup appropriately * Salt transmission should use secure channels 12.5. Identity and Pseudonymity The specification supports multiple identity postures, from fully anonymous to strongly identified, with user control over disclosure. 12.5.1. Anonymous Evidence Generation Evidence packets CAN be generated without any identity disclosure: * The declaration field (key 17 in evidence-packet) is OPTIONAL * Within declaration, author-name (key 3) and author-id (key 4) are both OPTIONAL * Device keys can be ephemeral, not linked to identity * Evidence proves process characteristics without revealing who Anonymous evidence is suitable for contexts where process documentation matters but author identity is irrelevant or should remain confidential. 12.5.2. Pseudonymous Evidence Pseudonymous use links evidence to a consistent identifier without revealing real-world identity: * author-id can be a pseudonymous identifier * Device key provides cryptographic continuity without identity * Multiple works can be linked to same pseudonym if desired * Real identity can remain undisclosed Condrey Expires 10 August 2026 [Page 132] Internet-Draft Proof of Process February 2026 Pseudonymous evidence enables reputation building without identity exposure. 12.5.3. Identified Evidence For contexts requiring identity binding: * author-name and author-id can be populated with real identity * Declaration signature (key 6) binds identity claim to evidence * Hardware attestation can strengthen device-to-person binding * External identity verification is outside specification scope Identity strength depends on the verification context, not the specification. The specification provides the mechanism for identity claims; verification of those claims is a deployment concern. 12.5.4. Device Binding Without User Identification Hardware attestation (hardware-section) binds evidence to a specific device without necessarily identifying the user: * Device keys are bound to hardware (TPM, Secure Enclave) * Evidence proves generation on a specific device * Device ownership is a separate question from evidence generation * Multiple users of same device produce device-linked evidence Device binding strengthens evidence integrity without requiring user identification. It proves "this device" without proving "this person." 12.6. Data Retention and Deletion Following [RFC6973] Section 6.2, this section addresses data lifecycle considerations. 12.6.1. Evidence Packet Lifecycle Evidence packets are designed as archival artifacts: Creation: Evidence accumulates during authoring session(s). Packet is finalized when authoring is complete. Condrey Expires 10 August 2026 [Page 133] Internet-Draft Proof of Process February 2026 Distribution: Packet may be transmitted to Verifiers, stored alongside documents, or archived for future verification needs. Retention: Retention period depends on use case. Legal documents may require indefinite retention; other contexts may allow shorter periods. Deletion: Once distributed, deletion from all recipients may be impractical. Authors should consider disclosure scope before distribution. 12.6.2. User Rights to Deletion Users have the following deletion capabilities: * Local Data: Evidence stored locally can be deleted at any time by the author. Implementations SHOULD provide clear deletion mechanisms. * Distributed Evidence: Once Evidence is transmitted to Verifiers or Relying Parties, deletion depends on those parties' policies. The specification cannot enforce deletion of distributed data. * Attestation Results: .war files produced by Verifiers are controlled by Verifiers. Authors may request deletion under applicable privacy laws. Authors should understand that distributing Evidence creates copies outside their control. Privacy-sensitive authors should limit distribution scope. 12.6.3. External Anchor Permanence External anchors have special retention characteristics: RFC 3161 Timestamps: TSA records may be retained by the timestamp authority per their policies. Typically includes the hash committed, not any document or behavioral data. Blockchain Anchors: Blockchain records are permanent and immutable by design. The anchored hash cannot be deleted from the blockchain. This is a feature for evidence permanence but has privacy implications. Condrey Expires 10 August 2026 [Page 134] Internet-Draft Proof of Process February 2026 OpenTimestamps: OTS proofs reference Bitcoin transactions, which are permanent. The proof structure can be deleted locally, but the Bitcoin transaction remains. Users concerned about data permanence should carefully consider whether to use blockchain-based external anchors. RFC 3161 timestamps offer similar evidentiary value with more conventional retention policies. IMPORTANT: Only cryptographic hashes are anchored, never document content or behavioral data. The permanent record is a hash, not the underlying information. 12.7. Third-Party Disclosure This section addresses what information is disclosed to various parties in the verification workflow, following [RFC6973] Section 5.2 on disclosure. 12.7.1. Information Disclosed to Verifiers When an Evidence packet (.pop) is submitted for verification, the Verifier learns: * Document hash (content-hash) - NOT the content itself * Document size (byte-length, char-count) * Authoring timeline (checkpoint timestamps, VDF durations) * Behavioral statistics (timing histograms, entropy estimates) * Edit patterns (aggregate counts, not content) * Optional: Raw timing intervals if disclosed * Optional: Author identity if declared * Optional: Device attestation if included Verifiers SHOULD NOT: * Retain Evidence packets beyond verification needs * Use behavioral data for purposes beyond verification * Attempt to re-identify anonymous authors from behavioral patterns Condrey Expires 10 August 2026 [Page 135] Internet-Draft Proof of Process February 2026 * Share Evidence data with unauthorized parties Implementations MAY define Verifier privacy policies that authors can review before submitting Evidence. 12.7.2. Information Disclosed to Relying Parties Relying Parties consuming Attestation Results (.war) learn: * Verification verdict (forensic-assessment) * Confidence score * Verified claims (specific thresholds met) * Caveats and limitations * Verifier identity * Reference to the original Evidence packet (packet-id) The .war file is designed to provide necessary trust information without full Evidence disclosure. Relying Parties needing more detail can request the original .pop file. 12.7.3. Minimizing Disclosure Authors concerned about disclosure can: 1. Use minimal disclosure tier (histogram-only, no raw intervals) 2. Omit optional sections (keystroke-section, absence-section) 3. Use author-salted mode to control verification access 4. Omit declaration or use pseudonymous identity 5. Select Verifiers with strong privacy policies 6. Limit distribution to necessary Relying Parties 12.8. Cross-Session Correlation This section addresses risks of behavioral fingerprinting across sessions and mitigation measures. Condrey Expires 10 August 2026 [Page 136] Internet-Draft Proof of Process February 2026 12.8.1. Correlation Risks Multiple Evidence packets from the same author may enable linkage: Behavioral Fingerprinting: Keystroke timing patterns exhibit individual characteristics that persist across sessions. An adversary with multiple Evidence packets could potentially link them to the same author even without explicit identity. Device Fingerprinting: If device keys are reused across sessions, Evidence packets are cryptographically linkable. Hardware attestation makes this linkage explicit. Stylometric Correlation: Edit pattern statistics (though not content) may correlate with writing style. Combined with timing data, this could strengthen cross-session linkage. 12.8.2. Device Key Rotation To limit cross-session correlation via device keys: * Session Keys: Use per-session derived keys rather than a single device key. HKDF with session-specific info prevents direct linkage. * Periodic Rotation: Rotate device keys periodically (RECOMMENDED: annually). Evidence packets signed with different keys are not cryptographically linked. * Context-Specific Keys: Use different keys for different contexts (e.g., work vs. personal) to prevent cross-context linkage. 12.8.3. Session Isolation Properties The specification provides inherent session isolation: * Each Evidence packet has a unique packet-id (UUID) * VDF chains are session-specific (session entropy in genesis) * No protocol mechanism links sessions together * Jitter data is bound to specific checkpoint chains Condrey Expires 10 August 2026 [Page 137] Internet-Draft Proof of Process February 2026 Cross-session linkage requires external analysis, not protocol features. The specification does not provide linkage mechanisms. 12.8.4. Additional Mitigations Authors concerned about cross-session correlation can: 1. Use coarser histogram buckets to reduce timing precision 2. Omit raw-intervals field 3. Vary devices for different document contexts 4. Use different pseudonyms for different contexts 5. Limit Evidence distribution to minimize adversary access to multiple packets 12.9. Privacy Threat Analysis Following [RFC6973] Section 5, this section analyzes specific privacy threats. 12.9.1. Surveillance The specification is designed to resist surveillance: * No content transmission prevents content-based surveillance * Local-only processing prevents network monitoring * Optional external anchors transmit only hashes * No telemetry or analytics collection The primary surveillance risk is through Evidence packet distribution. Authors control this distribution. 12.9.2. Stored Data Compromise If Evidence packets are compromised: * Document content is NOT exposed (hash-only) * Behavioral patterns MAY be exposed (timing data) * Authoring timeline is exposed (timestamps) Condrey Expires 10 August 2026 [Page 138] Internet-Draft Proof of Process February 2026 * If identity declared, author identity is exposed Mitigation: Encrypt Evidence packets at rest. Use access controls for stored Evidence. Limit retention period where appropriate. 12.9.3. Correlation Correlation threats are addressed in Section 12.8. Key mitigations include key rotation, histogram aggregation, and distribution limiting. 12.9.4. Identification Re-identification threats: * Anonymous Evidence MAY be re-identifiable through behavioral patterns * Histogram aggregation significantly reduces this risk * Raw interval disclosure increases re-identification risk * Device attestation explicitly identifies devices Authors requiring strong anonymity should use minimal disclosure tier without raw intervals and without device attestation. 12.9.5. Secondary Use Evidence data could theoretically be used for purposes beyond verification: * Behavioral analysis for profiling * Productivity monitoring * Training data for machine learning Mitigation: The specification does not prevent secondary use by data recipients. Authors should consider Verifier and Relying Party policies before disclosure. Implementations MAY include usage restrictions in Evidence packet metadata. 12.9.6. Disclosure Unauthorized disclosure of Evidence packets: * Authors control initial distribution Condrey Expires 10 August 2026 [Page 139] Internet-Draft Proof of Process February 2026 * Recipients may further distribute; specification cannot prevent * Salted modes limit utility of leaked Evidence * Anonymous Evidence limits identity exposure on leak Authors should treat Evidence packets as potentially sensitive and limit distribution to trusted parties. 12.9.7. Exclusion The risk that authors cannot participate in systems if they decline Evidence generation: * Evidence generation is voluntary * Disclosure levels are user-controlled * Relying Parties may require Evidence for certain contexts * The specification does not mandate deployment contexts Deployments should consider whether Evidence requirements create exclusionary effects and provide alternatives where appropriate. 12.10. Privacy Properties Summary This section summarizes the privacy properties provided and not provided by the specification. 12.10.1. Privacy Properties Provided Content Confidentiality: Document content is never stored in Evidence. Verification can occur without content access (using salted modes). Keystroke Privacy: Individual keystrokes are never recorded. Only timing intervals between events are captured, without character association. Local Control: All data processing occurs locally. No external services required for Evidence generation. Disclosure Control: Authors control Evidence distribution, disclosure level, and identity exposure. Pseudonymity Support: Evidence can be generated and verified without real-world identity disclosure. Condrey Expires 10 August 2026 [Page 140] Internet-Draft Proof of Process February 2026 Selective Verification: Salted modes enable author-controlled verification access. 12.10.2. Privacy Limitations Behavioral Data Exposure: Timing data reveals behavioral patterns. While aggregated, this data has biometric-adjacent properties. Distribution Not Controlled: Once Evidence is distributed, the specification cannot control further dissemination or use. Cross-Session Linkage Risk: Multiple Evidence packets may be linkable through behavioral analysis, even with different identities. External Anchor Permanence: Blockchain anchors create permanent records that cannot be deleted. Metadata Disclosure: Evidence packets reveal document size, authoring timeline, and edit statistics even without content. 12.10.3. Recommendations for Privacy-Sensitive Deployments 1. Use minimal disclosure tier (histogram-only, no raw intervals) 2. Consider coarser histogram buckets for enhanced privacy 3. Use author-salted mode for confidential documents 4. Avoid blockchain anchors if deletion rights are important 5. Rotate device keys periodically 6. Limit Evidence distribution to necessary parties 7. Review Verifier privacy policies before submission 8. Consider pseudonymous identities where appropriate 9. Provide clear user disclosures about data collection 10. Implement data retention policies aligned with use case Condrey Expires 10 August 2026 [Page 141] Internet-Draft Proof of Process February 2026 13. IANA Considerations This document requests several IANA registrations to support interoperable implementations of the witnessd Proof of Process specification. The author has submitted an application for a Private Enterprise Number (PEN) assignment under the WritersLogic organization to support vendor-specific registrations. 13.1. CBOR Tags Registry This document requests the allocation of three dedicated 4-byte CBOR tags in the "CBOR Tags" registry [IANA.cbor-tags]. These tags form a coordinated suite of identifiers for the Proof of Process protocol. +============+============+========+======+======================+ | Tag | Hex | ASCII | Data | Semantics | | | | | Item | | +============+============+========+======+======================+ | 1347571280 | 0x50505020 | "PPP " | map | Proof of Process | | | | | | Evidence Packet | +------------+------------+--------+------+----------------------+ | 1463894560 | 0x57415220 | "WAR " | map | Writers Authenticity | | | | | | Report (Attestation | | | | | | Result) | +------------+------------+--------+------+----------------------+ | 1347571281 | 0x50505021 | "PPP!" | map | Compact Evidence | | | | | | Reference | +------------+------------+--------+------+----------------------+ Table 18: CBOR Tags Summary 13.1.1. Tag for Proof of Process Packet (0x50505020) The tag value 1347571280 (hexadecimal 0x50505020) corresponds to the ASCII encoding of "PPP " and serves as a self-describing "Proof of Process Packet" identifier. This tag encapsulates a cryptographically anchored data structure used for digital authorship attestation. Unlike identity-only signatures, the Proof of Process format captures the authorship process through entangled Verifiable Delay Functions (VDFs) and human behavioral biometrics. A dedicated tag is required to enable zero-configuration identification and interoperability between authorship verification tools, academic repositories, and literary publishing platforms, providing a verifiable "forgery cost" to distinguish human-authored work from synthetic content. Condrey Expires 10 August 2026 [Page 142] Internet-Draft Proof of Process February 2026 The tagged data item is a CBOR map conforming to the evidence-packet structure defined in Section 2.3 . 13.1.2. Tag for Writers Authenticity Report (0x57415220) The tag value 1463894560 (hexadecimal 0x57415220) corresponds to the ASCII encoding of "WAR " and identifies Writers Authenticity Report structures. This tag encapsulates an Attestation Result produced by Verifiers after appraising Proof of Process Evidence Packets. The WAR format conveys verification verdicts, confidence scores, and forensic assessments following the IETF RATS (Remote ATtestation procedureS) architecture. A dedicated tag enables zero-configuration identification of attestation results, allowing Relying Parties to distinguish verification outcomes from raw evidence without content- type negotiation. The tagged data item is a CBOR map conforming to the attestation- result structure defined in Section 2.7 . 13.1.3. Tag for Compact Evidence Reference (0x50505021) The tag value 1347571281 (hexadecimal 0x50505021) corresponds to the ASCII encoding of "PPP!" and identifies Compact Evidence Reference structures. This tag encapsulates a cryptographic pointer to a full Proof of Process Evidence Packet. Compact Evidence References are designed for embedding in space- constrained contexts such as document metadata (PDF XMP, EXIF), QR codes, NFC tags, git commit messages, and protocol headers. The compact reference contains the packet-id, chain-hash, document-hash, and a summary with a cryptographic signature binding all fields. A dedicated tag enables zero-configuration detection and verification of authorship claims without transmitting full evidence packets. The tagged data item is a CBOR map conforming to the compact- evidence-ref structure defined in Section 10 . 13.1.4. Justification for Dedicated Tags The four-byte tag values were chosen for the following reasons: * *Self-describing format:* The ASCII-based mnemonics ("PPP ", "WAR ", "PPP!") enable immediate visual identification in hex dumps and debugging contexts. * *Zero-configuration detection:* Applications can identify Proof of Process data without prior context or content-type negotiation. Condrey Expires 10 August 2026 [Page 143] Internet-Draft Proof of Process February 2026 * *Interoperability:* Standardized tags enable diverse implementations (academic systems, publishing platforms, verification services) to recognize and process data without coordination. * *Compact encoding:* Despite being 4-byte tags, CBOR's efficient encoding minimizes overhead for these application-specific semantic markers. 13.2. Entity Attestation Token Profiles Registry This document requests registration of an EAT profile in the "Entity Attestation Token Profiles" registry established by [RFC9711]. +=======================================+=============+===========+ | Profile URI | Description | Reference | +=======================================+=============+===========+ | https://example.com/rats/eat/profile/ | witnessd | [this | | pop/1.0 | Proof of | document] | | | Process | | | | Evidence | | | | Profile | | +---------------------------------------+-------------+-----------+ Table 19: EAT Profile Registration Note: The URI https://example.com/rats/eat/profile/pop/1.0 is provisional during individual submission. Upon working group adoption, registration of an IANA-hosted profile URI will be requested (e.g., urn:ietf:params:rats:eat:profile:pop:1.0). The profile defines the following characteristics: Profile Version: 1.0 Applicable Claims: All standard EAT claims per [RFC9711], plus the custom claims defined in Section 13.3. Evidence Format: CBOR-encoded evidence-packet structure with semantic tag 1347571280. Attestation Result Format: CBOR-encoded attestation-result structure with semantic tag 1463894560. Domain: Document authorship process attestation, behavioral evidence for content provenance. Condrey Expires 10 August 2026 [Page 144] Internet-Draft Proof of Process February 2026 13.3. CBOR Web Token Claims Registry This document requests registration of custom claims in the "CBOR Web Token (CWT) Claims" registry [IANA.cwt]. These claims are used within EAT Attestation Results to convey witnessd-specific assessment data. Initial registration is requested in the private-use range (-70000 to -70010) to enable early implementation. Upon standards track advancement, permanent positive claim keys will be requested. +=======================+======+========+=================+=========+ |Claim Name |Claim |Claim |Claim Description|Reference| | |Key |Value | | | | | |Type | | | +=======================+======+========+=================+=========+ |pop-forensic-assessment|-70000|unsigned|Forensic |[this | | | |integer |assessment |document]| | | | |enumeration value| | | | | |(0-5) indicating | | | | | |the Verifier's | | | | | |assessment of | | | | | |behavioral | | | | | |evidence | | | | | |consistency with | | | | | |human authorship | | | | | |patterns. | | +-----------------------+------+--------+-----------------+---------+ |pop-presence-score |-70001|float32 |Presence |[this | | | | |challenge |document]| | | | |response score in| | | | | |range [0.0, 1.0] | | | | | |representing the | | | | | |ratio of | | | | | |successfully | | | | | |completed human | | | | | |presence | | | | | |challenges. | | +-----------------------+------+--------+-----------------+---------+ |pop-evidence-tier |-70002|unsigned|Evidence tier |[this | | | |integer |classification |document]| | | | |(1-4) indicating | | | | | |the | | | | | |comprehensiveness| | | | | |of evidence | | | | | |collected: | | | | | |1=Basic, | | | | | |2=Standard, | | Condrey Expires 10 August 2026 [Page 145] Internet-Draft Proof of Process February 2026 | | | |3=Enhanced, | | | | | |4=Maximum. | | +-----------------------+------+--------+-----------------+---------+ |pop-ai-composite-score |-70003|float32 |AI indicator |[this | | | | |composite score |document]| | | | |in range [0.0, | | | | | |1.0] derived from| | | | | |behavioral | | | | | |forensic | | | | | |analysis. Lower | | | | | |values indicate | | | | | |patterns more | | | | | |consistent with | | | | | |human authorship.| | +-----------------------+------+--------+-----------------+---------+ Table 20: Custom CWT Claims Registration The forensic-assessment enumeration values for pop-forensic- assessment are defined as: +=======+=======================+=============================+ | Value | Name | Description | +=======+=======================+=============================+ | 0 | not-assessed | Verification incomplete or | | | | not attempted | +-------+-----------------------+-----------------------------+ | 1 | strongly-human | Evidence strongly indicates | | | | human authorship patterns | +-------+-----------------------+-----------------------------+ | 2 | likely-human | Evidence consistent with | | | | human authorship patterns | +-------+-----------------------+-----------------------------+ | 3 | inconclusive | Evidence neither confirms | | | | nor refutes claims | +-------+-----------------------+-----------------------------+ | 4 | likely-ai-assisted | Evidence suggests AI | | | | assistance in authorship | +-------+-----------------------+-----------------------------+ | 5 | strongly-ai-generated | Evidence strongly indicates | | | | AI generation | +-------+-----------------------+-----------------------------+ Table 21: Forensic Assessment Enumeration Values Condrey Expires 10 August 2026 [Page 146] Internet-Draft Proof of Process February 2026 13.4. New Registries This document requests IANA to create three new registries under a new "witnessd Proof of Process" registry group. 13.4.1. Proof of Process Claim Types Registry This document requests creation of the "Proof of Process Claim Types" registry. This registry contains the identifiers for absence claims that can be asserted and verified in Evidence packets. 13.4.1.1. Registration Procedures The registration procedures for this registry depend on the claim type range: +=========+=============================+=========================+ | Range | Category | Registration Procedure | +=========+=============================+=========================+ | 1-15 | Chain-verifiable claims | Specification Required | +---------+-----------------------------+-------------------------+ | 16-63 | Monitoring-dependent claims | Specification Required | +---------+-----------------------------+-------------------------+ | 64-127 | Environmental claims | Expert Review | +---------+-----------------------------+-------------------------+ | 128-255 | Private use | First Come First Served | +---------+-----------------------------+-------------------------+ Table 22: Claim Types Registration Procedures Chain-verifiable claims (1-15) are claims that can be proven solely from the Evidence packet without trusting the Attesting Environment beyond data integrity. These claims require a published specification demonstrating verifiability. Monitoring-dependent claims (16-63) require trust in the Attesting Environment's accurate reporting of monitored events. Specifications MUST document the trust assumptions. Environmental claims (64-127) relate to the execution environment or external conditions. Expert review ensures claims are well-defined and implementable. Private use claims (128-255) are available for implementation- specific extensions without coordination. Condrey Expires 10 August 2026 [Page 147] Internet-Draft Proof of Process February 2026 13.4.1.2. Registration Template Registrations MUST include the following fields: Claim Type Value: Integer identifier in the appropriate range Claim Name: Human-readable name (lowercase with hyphens) Category: One of: chain-verifiable, monitoring-dependent, environmental, or private-use Description: Brief description of what the claim asserts Verification Method: How the claim is verified (for non-private-use claims) Reference: Document defining the claim 13.4.1.3. Initial Registry Contents The initial contents of the "Proof of Process Claim Types" registry are as follows: 13.4.1.3.1. Chain-Verifiable Claims (1-15) +=====+================================+==================+=========+ |Value| Name | Description |Reference| +=====+================================+==================+=========+ |1 | max-single-delta-chars | Maximum |[this | | | | characters added |document]| | | | in any single | | | | | checkpoint delta | | +-----+--------------------------------+------------------+---------+ |2 | max-single-delta-bytes | Maximum bytes |[this | | | | added in any |document]| | | | single | | | | | checkpoint delta | | +-----+--------------------------------+------------------+---------+ |3 | max-net-delta-chars | Maximum net |[this | | | | character change |document]| | | | across the | | | | | entire chain | | +-----+--------------------------------+------------------+---------+ |4 | min-vdf-duration-seconds | Minimum total |[this | | | | VDF-proven |document]| | | | elapsed time in | | | | | seconds | | +-----+--------------------------------+------------------+---------+ Condrey Expires 10 August 2026 [Page 148] Internet-Draft Proof of Process February 2026 |5 | min-vdf-duration-per-kchar | Minimum VDF- |[this | | | | proven time per |document]| | | | thousand | | | | | characters | | +-----+--------------------------------+------------------+---------+ |6 | checkpoint-chain-complete | Checkpoint chain |[this | | | | has no gaps (all |document]| | | | sequence numbers | | | | | present) | | +-----+--------------------------------+------------------+---------+ |7 | checkpoint-chain-consistent | All checkpoint |[this | | | | hashes and VDF |document]| | | | linkages verify | | | | | correctly | | +-----+--------------------------------+------------------+---------+ |8 | jitter-entropy-above-threshold | Captured jitter |[this | | | | entropy exceeds |document]| | | | specified bits | | | | | threshold | | +-----+--------------------------------+------------------+---------+ |9 | jitter-samples-above-count | Number of jitter |[this | | | | samples exceeds |document]| | | | specified count | | +-----+--------------------------------+------------------+---------+ |10 | revision-points-above-count | Number of |[this | | | | revision points |document]| | | | (non-monotonic | | | | | edits) exceeds | | | | | threshold | | +-----+--------------------------------+------------------+---------+ |11 | session-count-above-threshold | Number of |[this | | | | distinct editing |document]| | | | sessions exceeds | | | | | threshold | | +-----+--------------------------------+------------------+---------+ |12-15| Unassigned | Reserved for |[this | | | | future chain- |document]| | | | verifiable | | | | | claims | | +-----+--------------------------------+------------------+---------+ Table 23: Chain-Verifiable Claim Types Condrey Expires 10 August 2026 [Page 149] Internet-Draft Proof of Process February 2026 13.4.1.3.2. Monitoring-Dependent Claims (16-63) +=======+=============================+=================+===========+ | Value | Name | Description | Reference | +=======+=============================+=================+===========+ | 16 | max-paste-event-chars | Maximum | [this | | | | characters in | document] | | | | any single | | | | | paste event | | +-------+-----------------------------+-----------------+-----------+ | 17 | max-clipboard-access-chars | Maximum total | [this | | | | characters | document] | | | | accessed from | | | | | clipboard | | +-------+-----------------------------+-----------------+-----------+ | 18 | no-paste-from-ai-tool | No paste | [this | | | | operations | document] | | | | from known AI | | | | | tool | | | | | applications | | +-------+-----------------------------+-----------------+-----------+ | 19 | Unassigned | Reserved | [this | | | | | document] | +-------+-----------------------------+-----------------+-----------+ | 20 | max-insertion-rate-wpm | Maximum | [this | | | | sustained | document] | | | | insertion rate | | | | | in words per | | | | | minute | | +-------+-----------------------------+-----------------+-----------+ | 21 | no-automated-input-pattern | No detected | [this | | | | automated or | document] | | | | scripted input | | | | | patterns | | +-------+-----------------------------+-----------------+-----------+ | 22 | no-macro-replay-detected | No keyboard | [this | | | | macro replay | document] | | | | patterns | | | | | detected | | +-------+-----------------------------+-----------------+-----------+ | 23-31 | Unassigned | Reserved for | [this | | | | input-related | document] | | | | claims | | +-------+-----------------------------+-----------------+-----------+ | 32 | no-file-import-above-bytes | No file | [this | | | | imports | document] | | | | exceeding | | | | | specified byte | | Condrey Expires 10 August 2026 [Page 150] Internet-Draft Proof of Process February 2026 | | | threshold | | +-------+-----------------------------+-----------------+-----------+ | 33 | no-external-file-open | No external | [this | | | | files opened | document] | | | | during editing | | | | | session | | +-------+-----------------------------+-----------------+-----------+ | 34-39 | Unassigned | Reserved for | [this | | | | file-related | document] | | | | claims | | +-------+-----------------------------+-----------------+-----------+ | 40 | no-concurrent-ai-tool | No known AI | [this | | | | tool | document] | | | | application | | | | | running | | | | | concurrently | | +-------+-----------------------------+-----------------+-----------+ | 41 | no-llm-api-traffic | No detected | [this | | | | network | document] | | | | traffic to | | | | | known LLM API | | | | | endpoints | | +-------+-----------------------------+-----------------+-----------+ | 42-47 | Unassigned | Reserved for | [this | | | | AI-detection | document] | | | | claims | | +-------+-----------------------------+-----------------+-----------+ | 48 | max-idle-gap-seconds | Maximum idle | [this | | | | gap within | document] | | | | session does | | | | | not exceed | | | | | threshold | | +-------+-----------------------------+-----------------+-----------+ | 49 | active-time-above-threshold | Total active | [this | | | | editing time | document] | | | | exceeds | | | | | specified | | | | | threshold | | +-------+-----------------------------+-----------------+-----------+ | 50-63 | Unassigned | Reserved for | [this | | | | timing-related | document] | | | | claims | | +-------+-----------------------------+-----------------+-----------+ Table 24: Monitoring-Dependent Claim Types Condrey Expires 10 August 2026 [Page 151] Internet-Draft Proof of Process February 2026 13.4.2. Proof of Process VDF Algorithms Registry This document requests creation of the "Proof of Process VDF Algorithms" registry. This registry contains identifiers for Verifiable Delay Function algorithms used in Evidence packets. 13.4.2.1. Registration Procedures +=======+====================+========================+ | Range | Category | Registration Procedure | +=======+====================+========================+ | 1-15 | Iterated hash VDFs | Standards Action | +-------+--------------------+------------------------+ | 16-31 | Succinct VDFs | Standards Action | +-------+--------------------+------------------------+ | 32-63 | Experimental | Expert Review | +-------+--------------------+------------------------+ Table 25: VDF Algorithms Registration Procedures Iterated hash VDFs (1-15) are algorithms where verification requires recomputation. Standards Action ensures thorough security analysis. Succinct VDFs (16-31) are algorithms with efficient verification (e.g., [Pietrzak2019], [Wesolowski2019]). Standards Action ensures cryptographic soundness. Experimental algorithms (32-63) may be registered with Expert Review for research and interoperability testing. Production use requires promotion to Standards Action ranges. 13.4.2.2. Registration Template Registrations MUST include the following fields: Algorithm Value: Integer identifier in the appropriate range Algorithm Name: Human-readable name Category: One of: iterated-hash, succinct, or experimental Parameters: Required CDDL structure for algorithm parameters Verification Complexity: Asymptotic verification complexity Security Assumptions: Cryptographic assumptions for security Reference: Document specifying the algorithm Condrey Expires 10 August 2026 [Page 152] Internet-Draft Proof of Process February 2026 13.4.2.3. Initial Registry Contents +=====+======================+=============+============+=========+ |Value|Name |Category |Verification|Reference| +=====+======================+=============+============+=========+ |1 |iterated-sha256 |iterated-hash|O(n) |[this | | | | | |document]| +-----+----------------------+-------------+------------+---------+ |2 |iterated-sha3-256 |iterated-hash|O(n) |[this | | | | | |document]| +-----+----------------------+-------------+------------+---------+ |3-15 |Unassigned |iterated-hash|- |[this | | | | | |document]| +-----+----------------------+-------------+------------+---------+ |16 |pietrzak-rsa2048 |succinct |O(log n) |[this | | | | | |document]| +-----+----------------------+-------------+------------+---------+ |17 |wesolowski-rsa2048 |succinct |O(1) |[this | | | | | |document]| +-----+----------------------+-------------+------------+---------+ |18 |pietrzak-class-group |succinct |O(log n) |[this | | | | | |document]| +-----+----------------------+-------------+------------+---------+ |19 |wesolowski-class-group|succinct |O(1) |[this | | | | | |document]| +-----+----------------------+-------------+------------+---------+ |20-31|Unassigned |succinct |- |[this | | | | | |document]| +-----+----------------------+-------------+------------+---------+ |32-63|Unassigned |experimental |- |[this | | | | | |document]| +-----+----------------------+-------------+------------+---------+ Table 26: VDF Algorithms Initial Values The iterated hash algorithms use the iterated-hash-params CDDL structure (keys 1-2). The succinct algorithms use the succinct-vdf- params CDDL structure (keys 10-11). See Section 4 for detailed specifications. 13.4.3. Proof of Process Entropy Sources Registry This document requests creation of the "Proof of Process Entropy Sources" registry. This registry contains identifiers for behavioral entropy sources used in Jitter Seal bindings. Condrey Expires 10 August 2026 [Page 153] Internet-Draft Proof of Process February 2026 13.4.3.1. Registration Procedures The registration procedure for this registry is Specification Required. Registrations MUST include a specification describing: * The input modality or behavioral signal being captured * The method for converting the signal to timing intervals * Privacy implications of capturing this entropy source * Expected entropy density (bits per sample) under typical conditions 13.4.3.2. Registration Template Registrations MUST include the following fields: Source Value: Integer identifier Source Name: Human-readable name (lowercase with hyphens) Description: Brief description of the entropy source Privacy Impact: One of: minimal, low, moderate, high Reference: Document specifying the entropy source 13.4.3.3. Initial Registry Contents +=======+==================+================+==========+===========+ | Value | Name | Description | Privacy | Reference | | | | | Impact | | +=======+==================+================+==========+===========+ | 1 | keystroke-timing | Inter-key | moderate | [this | | | | intervals from | | document] | | | | keyboard input | | | +-------+------------------+----------------+----------+-----------+ | 2 | pause-patterns | Gaps between | low | [this | | | | editing bursts | | document] | | | | (>2 seconds) | | | +-------+------------------+----------------+----------+-----------+ | 3 | edit-cadence | Rhythm of | low | [this | | | | insertions/ | | document] | | | | deletions over | | | | | | time | | | Condrey Expires 10 August 2026 [Page 154] Internet-Draft Proof of Process February 2026 +-------+------------------+----------------+----------+-----------+ | 4 | cursor-movement | Navigation | low | [this | | | | timing within | | document] | | | | document | | | +-------+------------------+----------------+----------+-----------+ | 5 | scroll-behavior | Document | minimal | [this | | | | scrolling | | document] | | | | patterns | | | +-------+------------------+----------------+----------+-----------+ | 6 | focus-changes | Application | low | [this | | | | focus gain/ | | document] | | | | loss events | | | +-------+------------------+----------------+----------+-----------+ Table 27: Entropy Sources Initial Values 13.5. Media Types Registry This document requests registration of two media types in the "Media Types" registry [IANA.media-types]. 13.5.1. application/vnd.example-pop+cbor Media Type Type name: application Subtype name: vnd.example-pop+cbor Required parameters: N/A Optional parameters: N/A Encoding considerations: binary. As a CBOR format, it contains NUL octets and non-line-oriented data. Security considerations: This media type contains cryptographically anchored evidence of authorship process. It does not contain active or executable content. Integrity is ensured via a HMAC- SHA256 checkpoint chain and Verifiable Delay Functions (VDFs). Privacy is maintained through author-controlled salting of content hashes as defined in Section 2.5.2. Security considerations of CBOR [RFC8949] apply. See also Section 11 of this document. Interoperability considerations: While the +cbor suffix allows generic parsing, full semantic validation and behavioral forensic analysis require a witnessd-compatible processor as defined in this specification. The content is a CBOR-encoded evidence-packet structure with semantic tag 1347571280. Condrey Expires 10 August 2026 [Page 155] Internet-Draft Proof of Process February 2026 Published specification: [this document] Applications that use this media type: Generation of digital authorship evidence by the witnessd suite and WritersLogic integrated editors. Verification services, document provenance systems, academic integrity platforms. Fragment identifier considerations: N/A Additional information: Deprecated alias names for this type: N/A Magic number(s): 0xD950505020 (CBOR tag encoding at offset 0) File extension(s): .pop Macintosh file type code(s): N/A Person and email address to contact for further information: David Condrey Intended usage: COMMON Restrictions on usage: N/A Author: David Condrey Change controller: WritersLogic Inc. Provisional registration: No 13.5.2. application/vnd.example-war+cbor Media Type Type name: application Subtype name: vnd.example-war+cbor Required parameters: N/A Optional parameters: N/A Encoding considerations: binary. As a CBOR-encoded format, it contains NUL octets and non-line-oriented data. Security considerations: This media type conveys the final appraisal result (verdict) of an authorship attestation. (1) It does not contain active or executable content. (2) Integrity and authenticity are provided via a COSE signature [RFC9052] that MUST be verified against the Verifier's public key. (3) The information identifies a specific document by its content hash; privacy is managed through the hash-salting protocols defined in Condrey Expires 10 August 2026 [Page 156] Internet-Draft Proof of Process February 2026 Section 2.5.2. (4) The security considerations for CBOR [RFC8949] and COSE [RFC9052] apply. Users are cautioned not to rely on unsigned or unverified .war files for high-stakes authenticity claims. See also Section 11 of this document. Interoperability considerations: The +cbor suffix allows generic CBOR tools to identify the underlying encoding. This format is a specific profile of the RATS Attestation Result and references a Proof of Process (.pop) evidence packet by UUID as defined in this specification. The content is a CBOR-encoded attestation-result structure with semantic tag 1463894560. Published specification: [this document] Applications that use this media type: Verification and display of authorship scores by publishers, academic repositories, literary journals, and the WritersLogic verification suite. Fragment identifier considerations: N/A Additional information: Deprecated alias names for this type: N/A Magic number(s): 0xD957415220 (CBOR tag encoding at offset 0) File extension(s): .war Macintosh file type code(s): N/A Person and email address to contact for further information: David Condrey Intended usage: COMMON Restrictions on usage: N/A Author: David Condrey Change controller: WritersLogic Inc. Provisional registration: No 13.6. Designated Expert Instructions The designated experts for the registries created by this document should apply the following criteria when evaluating registration requests: Condrey Expires 10 August 2026 [Page 157] Internet-Draft Proof of Process February 2026 13.6.1. Proof of Process Claim Types Registry For claim types requiring Specification Required: * The specification MUST clearly define what the claim asserts * For chain-verifiable claims, the specification MUST demonstrate that the claim can be verified solely from the Evidence packet * For monitoring-dependent claims, the specification MUST document the Attesting Environment trust assumptions * The claim name SHOULD be descriptive and follow existing naming conventions For environmental claims requiring Expert Review: * The specification SHOULD describe implementation considerations * The claim SHOULD NOT duplicate existing claims * Privacy implications SHOULD be documented 13.6.2. Proof of Process VDF Algorithms Registry For experimental algorithms requiring Expert Review: * The algorithm MUST be documented with sufficient detail for independent implementation * Security analysis SHOULD be provided, even if preliminary * The algorithm SHOULD NOT be a minor variant of an existing registered algorithm * Implementation availability is encouraged but not required 13.6.3. Proof of Process Entropy Sources Registry For entropy sources requiring Specification Required: * The specification MUST describe how timing intervals are derived from the entropy source * Expected entropy density under typical conditions SHOULD be documented * Privacy implications MUST be clearly stated Condrey Expires 10 August 2026 [Page 158] Internet-Draft Proof of Process February 2026 * The entropy source SHOULD provide meaningful behavioral signal that cannot be trivially simulated 14. References 14.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [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, . [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, . [RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, August 2022, . [RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2024, . [RFC9711] Lundblade, L., Mandyam, G., O'Donoghue, J., and C. Wallace, "The Entity Attestation Token (EAT)", RFC 9711, DOI 10.17487/RFC9711, December 2024, . [IANA.cbor-tags] IANA, "CBOR Tags", . Condrey Expires 10 August 2026 [Page 159] Internet-Draft Proof of Process February 2026 [IANA.media-types] IANA, "Media Types", . [IANA.cose] IANA, "CBOR Object Signing and Encryption (COSE)", . [IANA.cwt] IANA, "CBOR Web Token (CWT) Claims", . 14.2. Informative References [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, . [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, . [RFC9562] Davis, K., Peabody, B., and P. Leach, "Universally Unique IDentifiers (UUIDs)", RFC 9562, DOI 10.17487/RFC9562, May 2024, . [I-D.ietf-rats-ar4si] Birkholz, H., Fossati, T., Pan, W., and E. Voit, "Attestation Results for Secure Interactions", Work in Progress, Internet-Draft, draft-ietf-rats-ar4si, . [I-D.ietf-rats-epoch-markers] Birkholz, H., Fossati, T., Pan, W., and C. Bormann, "RATS Epoch Markers", Work in Progress, Internet-Draft, draft- ietf-rats-epoch-markers, . [I-D.ietf-rats-ear] Fossati, T. and S. Frost, "EAT Attestation Results", Work in Progress, Internet-Draft, draft-ietf-rats-ear, . Condrey Expires 10 August 2026 [Page 160] Internet-Draft Proof of Process February 2026 [Pietrzak2019] Pietrzak, K., "Simple Verifiable Delay Functions", ITCS 2019, 2019, . [Wesolowski2019] Wesolowski, B., "Efficient Verifiable Delay Functions", EUROCRYPT 2019, 2019, . [MMR] Todd, P., "Merkle Mountain Ranges", 2016, . [TPM2.0] Trusted Computing Group, "TPM 2.0 Library Specification", 2019, . Acknowledgments The authors would like to thank the members of the IETF RATS working group for their foundational work on remote attestation architectures that this specification builds upon. Special thanks to the reviewers and contributors who provided feedback on early drafts of this specification. Document History This section is to be removed before publishing as an RFC. draft-condrey-rats-pop-00 Initial submission. * Defined Evidence Packet (.pop) and Attestation Result (.war) formats * Specified Jitter Seal mechanism for behavioral entropy capture * Specified VDF mechanisms for temporal ordering proofs * Defined absence proof taxonomy with trust requirements * Established forgery cost bounds methodology * Added cross-document provenance linking mechanism * Added continuation tokens for multi-packet Evidence series Condrey Expires 10 August 2026 [Page 161] Internet-Draft Proof of Process February 2026 * Added quantified trust policies for customizable appraisal * Added compact evidence references for metadata embedding * Documented security and privacy considerations * Requested IANA registrations for CBOR tags, media types, and EAT claims Author's Address David Condrey Writerslogic Inc United States Email: david@writerslogic.com URI: https://writerslogic.com Condrey Expires 10 August 2026 [Page 162]